What about making the RPC method synchronous? Then you can return the "further actions needed/not needed" status code simply with a return statement in the RPC method. This will save you the trouble of managing a thread pool on the server side, which is a bit of a no-no in Java EE anyway.
In either case, the call site on the client is always asynchronous. It doesn't matter how long it takes to respond to a message on the server--the client always receives the result in a callback.
Hope that helps!
Thanks for your answer Jonathan
Of course we are not managing a thread pool on our own, I was refering to
@Asynchronous(javax.ejb), sorry I wasn't clear.
The use case is the following: the initial RPC is for composing and sending a mail, thus the service returns whether the mail was successfully sent or not. As a new requirement the sent mail must now be processed to check if further actions are needed. I decided to not change the mailing components (I think it's not their responsibility to do the processing and the service should alwas return whether the mail was sent or not) and instead introduced a
MailSentEventthat is fired after the mail is gone and dispatched in a
@Asynchronousmethod (in which the processing is done, i.e., creating several documents). I'm wondering now if it is possible to notify the client that initiated the mail sending about 'The document xy has been created'.
Hope that clarifies my question.