Laird, Reza:
I just wanted to say thank you so much to both of you for trying to help me
on this item. I am very grateful.
In the end I just couldn't zero in on why get() wasn't blocking. I just
reimplemented my work in regular Callable classes and put them to use using
the ManagedExecutorService. I just call back once in a while to see if the
work is finished yet. It turns out its not a bad way to go.
My only regret on the item (besides bruises on my far head) is that if I
was really running into a regression and didn't find enough info to report
it someone else might have trouble with it later.
The folks that work on Glassfish do such a nice job I really feel that
good/useful bug reports are a way to be helpful to them. I'm so grateful
that its the reference implementation. I generally have so few issues
getting apps to run on other servers when my project starts on GF.
And, good folks like you guys that are willing to help on occasional rough
spots very much make we want to pay the favor forward and help those who
are a little earlier in the learning curve than myself in using GF.
Truly. Thank you.
Dennis
On Tue, Aug 12, 2014 at 9:57 AM, Dennis Gesker <dennis_at_gesker.com> wrote:
> 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>
>
--
*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>