after browsing these forums, but not finding my answer, I have a question:
How can I handle the server side Async? The server side calls one of the other clients, and needs to wait for the answer to return.
Like this: the SOAP client (#1) asks for some data of client #2. Client #2 (Binmessage/superchannel) is behind a firewall so I use an event to get #2 to provide the asked data. #2 uses a normal clientcall to serve the data to the server, and the server then redirects this to the #1.
I now use the solution that each SOAP-client call is devided into two separate calls: requestdata(forClientID) and retrievedata. The latter is executed until it returns the requested data.
This makes the (already async) client quite complex. An alternative is to stall the server thread until some flag is set, but using ‘Thread.sleep’ is not a good solution, or I implemented it wrong… From a code point of view, splitting the server side to async methods would be the best solution imho, but how to do that?
right now, if yo want to return info form the same call on the server, you have no choice but to block on the server. this should not really be an issue?
i suppose support for explicitly asynchronous services could be added to RO (with some significant restructuring), but that would fundamentally change how a Service implementation, server side, looks; all server methods would need to return right way, and there’d be callbacks on success that trigger the response to the client. it’s doable — but tbh i’m not sure if it would be worth the effort in infrastructure.
The problem with blocking the server thread was that it seemed to block other calls to the server, if using Thread.sleep. But that might be caused by some other problems, too. I had great difficulties in finding a superchannel on the server and client that actually worked well together (mysterious 500 Server Errors, errors getting the RODL, crashes, Http-timeouts that locked up the channel).
So, if from your point of view it should be no problem to sleep the server thread, that probably is the way to go. If you can confirm this, I’ll retry that solution, as it keeps both client and server much more simple.