-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do commands eventually time out? #109
Comments
It's helpful to separate the components when assessing problems like this. For example, what happens in Cytoscape when GeneMANIA is down. If you just use the GUI, does it hang or time out. If it hangs there, then the problem can't be solved with RCy3. Same question goes for CyREST: if it hangs there, then it can't be solved with RCy3. If indeed, ONLY RCy3 is hanging, then we can probably fix it here. My assumption at this point, is that Cytoscape hangs. It's a common problem in Cytoscape to not being able to cancel or time out tasks. This is a known and reported bug in Cytoscape, but it's going to take a while to fix them all. In this particular case, the GeneMANIA app might be able to resolve this? Not sure.... |
It was cytoscape that was hanging. I wonder if commands could time out if there is no response through cyrest. We can probably add a command to the genemania suite that checks if the webservice is up but there are so many different services in cytoscape and this is probably a general problem. |
Right. The scary part about having RCy3 continue when Cytoscape hangs is... what should happen next in the script? If the next line in the script involves Cytoscape, then it will fail (or hang). And then the subsequent lines in the script that don't involve Cytoscape might not have data in the expected state, leading to either NULL fails or (even worse) stale data values that are no longer accurate. In the end, the solutions are case-sensitive. So, in your script you could wrap GeneMANIA RCy3 calls in a Try-Catch and then code how you want fails to be handeled. I can't think of a general solution at the RCy3 level... |
But that is what I did initially. I wrapped the entire genemania set of commands in a try and catch and it just sat there. Cytoscape won't return anything so the try catch doesn't work. Cytoscape would have to throw an error for the try catch to work and it isn't. |
Ahh, I see. I still think the right answer is for the GeneMANIA app to not cause Cytoscape to hang, but I'll continue pondering this... If Cytoscape returned an error, then you Try-Catch would be invoked and it'd be okay. I'm still uneasy with the idea and RCy3 just "gives up" on a methods after a period of time. Would be hard to distinguish compute time from down server, etc. |
RCy3 can’t just give up … if it sends another command to Cytoscape, there’s no guarantee that Cytoscape is in a state to process it.
Generally, good state must exist from the lowest levels of Cytoscape all the way through CyREST and ultimately RCy3 and py4cytoscape.
RCy3 and py4cytoscape aren’t in control of very much.
From: Alexander Pico <[email protected]>
Sent: Tuesday, February 2, 2021 2:30 PM
To: cytoscape/RCy3 <[email protected]>
Cc: Subscribed <[email protected]>
Subject: Re: [cytoscape/RCy3] Do commands eventually time out? (#109)
Ahh, I see. I still think the right answer is for the GeneMANIA app to not cause Cytoscape to hang, but I'll continue pondering this... If Cytoscape returned an error, then you Try-Catch would be invoked and it'd be okay. I'm still uneasy with the idea and RCy3 just "gives up" on a methods after a period of time. Would be hard to distinguish compute time from down server, etc.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https:/github.com/cytoscape/RCy3/issues/109*issuecomment-772054406__;Iw!!Mih3wA!UdtBMUvIvnpwer76_y-OFScTSoY7YOHQB391TuQvfNj6MSxYDjOmv3MzM7snhfhm$> , or unsubscribe <https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AA4GLXXTVM75A4KZFS2F5XLS5B4IDANCNFSM4W7DOJAQ__;!!Mih3wA!UdtBMUvIvnpwer76_y-OFScTSoY7YOHQB391TuQvfNj6MSxYDjOmv3MzM5Zegi_C$> . <https://github.com/notifications/beacon/AA4GLXXS26AY7MLIMZDKBQ3S5B4IDA5CNFSM4W7DOJA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFYCJ3BQ.gif>
|
I added this ticket to genemania (GeneMANIA/genemania#160) but I feel like it applies to many other services that have commands within Cyrest. |
Agreed. |
The only hack that might work in your case is something I think you mentioned already... You could have your script independently check the GeneMANIA server before attempting the RCy3 call. It's clunky, but could serve as a workaround. |
Code I have been running for the past few days just stopped working this morning. It would just sit on the same command forever. Tried to debug the issue but turns out it is because the service I am trying to access is down. Trying to run the following command:
genemania_command <- "genemania search geneLimit=0 organism=9606 networks=path,pi genes='P42684|Q7Z7M0|Q9C0I1|Q8N2Y8|Q15772|O75325|Q8N1F8|Q86TC9|Q86SU0|Q96K21|Q92802|Q9H7N4|Q9NQS7|Q8TCG2|Q08345|Q12774|Q9UP79|O75051|P14652|Q14554|O43896|Q01804|Q6MZM9|Q9UPQ9|Q6ZUB1|Q6T4R5|O15534|Q9NZ56|Q9Y3S1|Q86VM9|Q6P2E9|Q01892|Q13873|Q9ULQ1|P07996|Q6MZW2|Q96RP3|Q9NQ87|Q14678|Q14934|Q5VZ46|A6NM11|Q8N5Q1|Q92625|Q92859|O43157|Q9UBN7|P78563|Q8TF66|Q27J81|Q9UJ55|Q3SXY8|O95180|O14776|Q8IWE5|Q8N693|Q13094|Q86YV5|Q9BRR9|Q9H0F5|O43151|Q8IZD0|Q15424|P36888|Q9ULE3|P0CG20|Q8WZ42|Q96QS6|P30530|Q9H211|Q9H8Y8|O15117|O60381|Q8NF99|A6NMS7|O60309|C9JSJ3|Q7Z410|Q6SJ96|Q04864|O60504|A2VEC9|Q14003|Q8NDA2|Q9H3P2'"
gm_network <- commandsRun(genemania_command);
I know that genemania is currently down (but I didn't put two and two together until I tried unsuccessfully to debug the issue from R). The only way the loop will continue is if I terminate the running code. Will RCy3 calls ever time out? Is there a better way to do this? Should I be checking if a service is up before running a command?
Thanks,
Ruth
The text was updated successfully, but these errors were encountered: