BTW for those following along, we solved this in IRC: only one of the two
endpoints is being closed in the above code.
Also it was noted that this test could run just as well in a single endpoint.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177162#4177162
Tried but did not work (deadlocked?!).
public final class ClientToServerToClientExample {
|
| public static void main(String[] args) throws Exception {
| Security.addProvider(new Provider());
| RequestListener listenerServer = new
AbstractRequestListener() {
"barbacena" wrote : Ok. But how can I obtain a Client from a RequestContext?
Ah. You don't! If you want to get a callback, you would send a Client as part
of your request. Or send a bunch of Clients if you want. The framework will
automatically set up a channel for the Client and forward you
Ok. But how can I obtain a Client from a RequestContext? My use case is:
Client | Server
| -
| msg1|
| -
| | rpy1
| ---
"barbacena" wrote :
| What is the API to reply asynchronously?
|
Just use that requestContext instance whenever you're ready to reply, from any
thread at any time. Just be sure that you can guarantee that you either send a
reply or send an exception eventually.
anonymous wrote :
| Wha
anonymous wrote : I was also thinking about adding an API element to the
RequestContext class: a "resume()" method that basically allows the next
waiting request to be processed immediately in another thread (as opposed to
executing a background thread for every request). What do you think?
IM
"barbacena" wrote : How many threads execute handleRequest method per (session)
client? To accomplish this execution order guarantee (A B and C) only one
thread can execute per session client.
Just one. This is the only way to keep ordering I think. However like I said,
the request handler ma
Hi,
anonymous wrote : No, it means that the server will receive messages in order
relative to the client, which means that if you send requests A B and C, the
server will receive them in order A B and C. Except that it's not working yet.
:)
anonymous wrote : Execution order is guaranteed withi
"barbacena" wrote :
| That is nice. I would suggest a javadoc on send,invoke and sendOneWay
saying this.
|
It's on my todo list. :)
"barbacena" wrote : That means ordered execution need to be handled by the
client. It is fine for me however I would like to serialize execution per
(session
Hi,
anonymous wrote : The current default policy that we've agreed on for ordered
execution is: Each request on a single Client instance that happens-after a
previous request, will also happen-after the previous request on the server
side (maybe not in the same thread though).
That is nice.
10 matches
Mail list logo
