So you are saying that for a remote asynchronous EJB method call, there are /two/ additional threads; one on the client to make the remoteCall, and one on the server to wrap the method invocation. As a result, the problem we are seeing is that the thread created on the client side has not yet invoked the remoteCall when the client shuts down.
Isn't that overkill? Why use the executorService for the client side of the invocation? Does it significantly reduce the time it takes for the client to make the call? >From JSR 318 final release: "When a client invokes an asynchronous method, the container returns control to the client immediately and continues processing the invocation on a separate thread of execution." That doesn't seem to indicate client asynchronous behavior; only container (server-side) asynchronous behavior. Assuming the client-side thread is desirable, perhaps the ThreadPool should use daemon threads so that they can complete their task even if the client shuts down. Romain Manni-Bucau wrote > Client side and server side have the same architecture more or less. Both > have a thread pool. So bean.asyncCall() will do a > executorService.submit(remoteCall). > > What can potentially be considered as a bug is the fact we don't shutdown > this executor but even doing it we would shutdown the client before it > sent the task to the server so you could get the same > behavior as well. ----- - Tim -- View this message in context: http://openejb.979440.n4.nabble.com/Remote-Asynchronous-EJB-Method-call-followed-quickly-by-client-exit-tp4669337p4669375.html Sent from the OpenEJB User mailing list archive at Nabble.com.
