Revit_Toolkit: Adapter having trouble attaching to Revit

JosefTaylor commented 5 years ago

Pull from Revit returns error "Failed to connect to Revit" after one of several conditions:

two instances of Revit are open > error
- after one is closed, 'active' toggled to try to re-set adapter > error
- remaining instance of Revit closed, re-opened > success!
Grasshopper and Rhino closed to install a package (lunchbox) and re-openned > error

Firstly, it seems that the error should be returned by the adapter and not the pull. Is that possible? Secondly, can anyone reproduce these errors and can we improve the robustness of the adapter?

dlamianski commented 5 years ago

I've discovered the same issue. The adapter worked eventually, after opening/closing Revit several time.

pawelbaran commented 4 years ago

In general, the toolkit should be stabilized after @IsakNaslundBh's work on Socket_Toolkit. However, a few ideas to be considered in 3.2:

ping on Revit+Listener startup or UpdatePorts to look for existing instance of listener working on given ports
ping on RevitAdapter active == true to identify Revit listener instance that is currently running on given ports

pawelbaran commented 3 years ago

TL;DR; Please read bolds 😉

Hi all,

I made an investigation on the topic raised in this subject. From what I have tested by closing and opening various instances of Revit/Rhino, currently there are two cases, in which the adapter breaks:

1. One instance of Revit, one instance of adapter - on of them restarted

The connection has been successfully set up, data exchanged, then one end of the connection (Rhino/Revit) has been restarted - in such cases, sometimes the adapter stops working, throwing an error about lost connection. It is an easy fix, one simply needs to restart the adapter and/or refresh ports in Revit. In my opinion, that does not require fixing.

2. Multiple instances of Revit, one instance of adapter

In such case the adapter starts communicating by calling CheckConnection, which sends a ping to the Revit listener. What usually happens then is:

One of the listeners pings back
The other listener pings back
The adapter records the ping generated in point 1., assumes that the connection is OK and sends the actual request
The adapter starts listening for the response to request
Instead of the response to the request, the adapter records the initial ping generated in point 2. and returns it as the output of the request. The requests sent out in point 3. can be processed by either one or both Revit instances, but never get caught by the adapter, which thinks that the job is done.

*A really unpleasant variation of the above is the scenario, in which the request sent in point 3. either never reaches the listeners or the data package gets lost on the way back, resulting in the adapter getting stuck on waiting for the response to the request, that will never arrive (it will finally timeout after 10 mins as a default).

I tried to fix the above by adding more strict connection check, where after pinging the listener, the adapter checks whether it received exactly one package containing confirmation that the connection is OK. However, such approach has 2 drawbacks:

the adapter needs to wait for a certain amount of time to check if no more than one response is recorded, which generates time delays
it still happens that this check is passed (one instance of Revit falls asleep?) and the code proceeds as if there was only 1 instance of Revit running

To make it more fun, I've tried to double check the above by if (!CheckConnection() ||!CheckConnection()), resulting in same behaviour - still 1 in 10 pulls comes through randomly querying one instance of Revit. What is more, the unpleasant variation marked with * still occurs!

Which makes me think that fixing this issue will require either a deeper intervention in Socket_Toolkit or implementation of a more complex system including signing packages in Revit_Toolkit. Both likely to be time-consuming and risky by nature.

However, I thought of a cheap solution that would make the system robust by default while making the users more aware. This solution is starting Revit with inactive listener, i.e. forcing the user to click Update Ports button to set up the connection. That should eliminate the majority of issues, the only way to break the mechanism would be to start 2 listeners on the same ports in parallel (which I believe is simply wrong).

How does the proposed solution to 2. sound to you? @kayleighhoude @al-fisher @rwemay @enarhi?

kayleighhoude commented 3 years ago

@pawelbaran the solution regarding the force run of Revit listener sounds like a good solution IMO, since I usually do that anyway and it would allow you to continue having multiple instances of Revit open. Could we add a message with explicit instructions on how to do so upon triggering the pull?

enarhi commented 3 years ago

@pawelbaran agree with @kayleighhoude , I'm fine with the requirement to enable in revit as long as a clear warning comes up when pulling with instructions on how to do so if no revit connection is found. I also think this would require the revit addin button to have one more button to initialize, or the current one should be renamed accordingly as update ports is not intuitive. A simple button saying "Enable BHoM" or similar would do the trick.

kayleighhoude commented 3 years ago

@pawelbaran @enarhi @al-fisher 100% agree on the renaming of the RevitListener/Update Ports!

al-fisher commented 3 years ago

Yes! Regardless of the full solution to this issue actually - a rename of RevitListener to something more obvious is great. Will be clearer on Addin load message, and on Ribbon etc.

pawelbaran commented 3 years ago

Oke, so my idea would be:

Rename RevitListen to BHoM Revit Adapter
Refresh the UI on the Revit side by renaming UpdatePorts to Activate (when status == inactive) or Refresh (when status == active)
Add Deactivate button on the Revit side to drop the connection
Start Revit with inactive Revit listener
Make the warning more informative on the adapter action failing due to the lack of connection - what should be clicked and where

How does that sound?

ssiimmoonnee commented 3 years ago

Hi Pawel, this all sounds good to me! Just a couple of questions.

Will the BHoM Revit Adapter be still under Add-ins ribbon tab? Or will it migrate to BHoM tab? Wondering if centralizing all the BHoM tools under one tab would help the user out.
Would the new "Refresh" button be greyed out when the connection is not "Activated" yet, or deliberately "Deactivated"?

pawelbaran commented 3 years ago

Thanks for having a look @ssiimmoonnee. Following your questions:

Will the BHoM Revit Adapter be still under Add-ins ribbon tab? Or will it migrate to BHoM tab? Wondering if centralizing all the BHoM tools under one tab would help the user out.

That is a good question. I was thinking of keeping it in the Add-Ins tab as the users may have gotten used to, but centralizing everything in the BHoM tab would be nicer structure wise. Do you have a strong opinion on that, @al-fisher?

Would the new "Refresh" button be greyed out when the connection is not "Activated" yet, or deliberately "Deactivated"?

I was thinking of swapping the button dynamically depending on the state of the adapter, i.e. the same button would be named either Activate or Refresh (it is possible to hack such behaviour). We could call it a bit of a... Schrödinger's button 😸

al-fisher commented 3 years ago

Will the BHoM Revit Adapter be still under Add-ins ribbon tab? Or will it migrate to BHoM tab?

Good idea @ssiimmoonnee - yes I actually would move it to a new BHoM tab! If you are OK with that @pawelbaran?

I think we do take this moment and take advantage of centralising

BHoM / Revit_Toolkit