Laird:
My refresh routine gets called two ways.
1. From a @Singleton with/via a @Schedule method that runs in the middle of
the night.
2. From a method in an @ApplicationScoped bean that my user can call on
demand from a JSF page. But the flow is basically this:
[From @Schedule method (ejb.jar) or method in @ApplicationScoped (war.war)]
--> UiEJB.refreshDynamicsData() --> DynamicsPull.refresh() -->
DynamicsPull.fetchRelatedProjectData()
My @Stateless Beans that do the actual work and contain the @Asynchronous
methods are injected into DynamicsPull. The methods that return the
AsyncResult / Future<Integer> are called in
DynamicsPull.fetchRelatedProjectData()
The Future.get()s in DynamicsPull.fetchRelatedProjectData() should hold
things up until their work is done -- and they seem to -- when the routine
is initiated from the @Schedule method in my ejb.jar.
The Future.get()s in DynamicsPull.fetchRelatedProjectData() should hold
things up until their work is done -- *but they don't* -- when the routine
is initiated from the method in my @ApplicationScoped bean in my war.
It really has me scratching my head. I'm not sure what to look at next.
Dennis
On Mon, Aug 11, 2014 at 5:00 PM, Laird Nelson <ljnelson_at_gmail.com> wrote:
> 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
>
--
*Dennis Gesker*
<http://goog_777861789>[image: www.linkedin.com/in/gesker]
<http://www.linkedin.com/in/gesker>[image: http://www.facebook.com/gesker]
<https://www.facebook.com/gesker>[image: https://twitter.com/gesker]
<https://twitter.com/gesker>[image: http://gesker.wordpress.com]
<http://gesker.wordpress.com>[image:
https://pgp.mit.edu/pks/lookup?search=dennis%40gesker.com&op=index]
<https://pgp.mit.edu/pks/lookup?search=dennis%40gesker.com&op=index>[image:
http://www.gesker.com] <http://www.gesker.com>[image: dennis@gesker.com]
<dennis_at_gesker.com>