Sometimes the flowservice I run gets stuck and it’s not possible to do anything again with it. Even just restarting webmethods.io in a different browser freezes once I simply try to enter Flowservices tab. If the service was launched through Run command, it can be seen in the Monitor page as running and be terminated, but if it was being debugged, Monitor won’t show it.
Well, that’s the problem - the point of debugging is to determine why it gets stuck and how the reason can be eliminated.
For some of events, I suspect, a query that returns too much data may be responsible, but my question is more about how can I restore my access to the server itself to be able to do necessary changes rather than about what changes are necessary.
Unfortunately, I have no access to server.log. It would be much easier if I did.
Yes, it takes data from external data source (not ours, can’t affect). Normally, the query asks for about 8K records, which is acceptable, but when debugging, messed conditions can happen. As I said, the question is not about how to make this particular service behave, it’s about how to normalize the very access to webmethods.io itself in a situation when shit hits the fan. That’s not the last service I’ll have to deal with, after all.
Does monitor show the debug session/service? In IS Administrator (on-prem) one can see the debugger task, not the service being debugged. Perhaps .io has that too?
Once again: if a flowservice gets stuck in debug mode for whatever reason, there’s no way to terminate it (the Monitor page only provides way to terminate running services, not debugged ones), and once it happens, it becomes impossible to simply enter the Flowservices page in webmethods.io for many hours.