On Mon, Aug 11, 2014 at 3:05 PM, Dennis Gesker <dennis_at_gesker.com> wrote:
> My @Asynchronous method is definitely in a different SessionBean which is
> injected into the bean doing the calling.
>
> Is there some kind of implied timeout? I am calling get() on a quite a few
> AsynResult()s. Maybe this isn't allowed?
>
No, there's no implied timeout. (There is a version of the get() method
that allows you to specify a timeout if you wish.)
You wrote, earlier: "My get() calls a Future<Integer> method decorated with
@Asynchronous which actually returns AsyncResult() from a SessionBean."
Something smells funny in there, and that seems to contradict what you
wrote above.
To be clear, please ensure that you have at a maximum two classes of
interest involved in all this:
1. The calling class. Most likely it's going to be an EJB or a servlet,
or injected into an EJB or a servlet somewhere and called from there. I
believe you said it was an @ApplicationScoped bean.
2. The called class. It must be an EJB with one of its methods marked
@Asynchronous returning a Future<Integer> (in your case). This method must
return an AsyncResult and must not itself jump through any hoops to perform
asynchronous work; you have to trust that this method will be invoked in
the right way by the container when it is called by a container-built proxy.
If you satisfy both of these conditions, then I don't know what's going on,
but the good news is it should be very simple to put together a test case.
Best,
Laird
--
http://about.me/lairdnelson