tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ymaraner <>
Subject Re: Remote Asynchronous EJB Method call followed quickly by client exit
Date Fri, 16 May 2014 19:29:34 GMT
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:
Sent from the OpenEJB User mailing list archive at

View raw message