[jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: Fully asynchronous invocation

Expanding on this idea: there are two basic thread arrangements that affect asynchronous invocations. The first is the stereotypical server methodology: basically a Selector and a thread pool. A message coming across the wire is (typically) handled immediately. The second is the stereotypical client methodology: the client owns the connection, but there is no dedicated thread to handle asynchronous messages. The FutureReply model can work with both of these models with varying degrees of success. With the server model, it's easy - messages are always handled immediately. If there's a request completion notifier registered on the FutureReply, the callback can be called instantly. The client model is a little trickier, but still doable. Basically, any time a client thread makes a call into Remoting, the thread can be "borrowed" to do a bit of work, especially if it was just going to block anyway. This isn't a perfect solution, since if the user never calls into Remoting, they will never get their "asynchronous" notifications. Perhaps these potential limitations are outweighed by the benefit of not having to deal with a dedicated thread pool on the client. Alternatively, asynchronous calls could simply be disallowed if there's no thread available to monitor for replies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061525#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...