Connection to Cytoscape sometimes fails

[bdemchak]

Kozo has noticed that sometimes a connection to port 1234 fails after a long operation.

Judging from the Python HTTP documentation and StackOverflow discussions, it seems that Cytoscape isn't opening the HTTP connection before the connection is attempted. This seems to be an unexplained delay within Cytoscape. Alternately, py4cytoscape could be routinely pressing its luck in assuming that Cytoscape's connection will always be ready quickly.

Either way, there are standard strategies for the client (py4cytoscape) retrying the connection, and we should use them.

It's unclear whether this is happening with RCy3, by the way. Some claim it is not, but I think I have seen a report from Ruth Isserlin that sounds like this situation.

[yihangx]

So this mean the standard strategies for the client retrying the connection is not working?

[bdemchak]

No. This means that the standard Python libraries don't retry the connection at all. So, if a connection fails (i.e., a TCP connection can't be created), it fails, and there is no library-level retry. See here.

To get a retry, there are a number of things that can be done, ranging from retrying at the py4cytoscape level (e.g., in commands.py:_do_request_local()) down to Session-level hacks, to libraries.

I'm inclined to first try the backoff library, as it's actively maintained and looks like it may do a better job than my roll-your-own solution in commands.py:_do_request_local(). The down side is that it's one more library that py4cytoscape would depend on.

I could be talked into the session-level hack if it's actually as easy as the requests documentation makes it look.

[bdemchak]

Solved with a1fd5f24c361be0fd4a0598be3a032c1c5e110b2 ... used call to backoff library instead of setting up Session retries because backoff library performs exponential backoff. This would be a better strategy when the Cytoscape delays are unpredictable (assuming that's the source of the problem).