Quantcast

What, if any, guarantees are made about invoking asynchronous event observer methods?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

What, if any, guarantees are made about invoking asynchronous event observer methods?

Laird Nelson
I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".

If I fire an asynchronous event without any special notification options, my understanding is that the container will arrange for that event to be delivered to asynchronous observers.

Is (appropriate) asynchronous observer method invocation guaranteed to happen at some point?  Section 10.2.2 seems to hint that it is:

"Event fired [sic] with the fireAsync() method is [sic] fired asynchronously. All the resolved asynchronous observers (as defined in Observer resolution) are called in one or more different threads."

To me, this says that if I use fireAsync() to fire an event, then if I have a (resolved) asynchronous observer method for it it will be notified before the container closes no matter what.

(I believe I am observing a race condition somewhere in here that might show that Weld's default asynchronous event delivery machinery does not actually get around to delivering the event I've queued up before the container closes.  Sometimes the event is received, sometimes it is not.  Obviously if there is no such guarantee this could be permitted behavior.)

Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What, if any, guarantees are made about invoking asynchronous event observer methods?

Matej Novotny
Hi Laird,

if I understand you correctly, there is no guarantee for that in Weld. If you fire an async event it will spin another thread (or more), where it will start notifying async observers.
Only after it is done, it will come back to the main thread with result. There is no synchronization around this - that would kind of go against the nature of truly asynchronous calls, wouldn't it?

As for spec interpretation, I don't think the implication you suggest is intended there.
It's a shame we haven't clarified this earlier though.

What exactly is your use case?

Matej


----- Original Message -----

> From: "Laird Nelson" <[hidden email]>
> To: "cdi-dev" <[hidden email]>
> Sent: Thursday, May 11, 2017 9:30:17 PM
> Subject: [cdi-dev] What, if any, guarantees are made about invoking asynchronous event observer methods?
>
> I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
>
> If I fire an asynchronous event without any special notification options, my
> understanding is that the container will arrange for that event to be
> delivered to asynchronous observers.
>
> Is (appropriate) asynchronous observer method invocation guaranteed to happen
> at some point? Section 10.2.2 seems to hint that it is:
>
> "Event fired [sic] with the fireAsync() method is [sic] fired asynchronously.
> All the resolved asynchronous observers (as defined in Observer resolution)
> are called in one or more different threads."
>
> To me, this says that if I use fireAsync() to fire an event, then if I have a
> (resolved) asynchronous observer method for it it will be notified before
> the container closes no matter what.
>
> (I believe I am observing a race condition somewhere in here that might show
> that Weld's default asynchronous event delivery machinery does not actually
> get around to delivering the event I've queued up before the container
> closes. Sometimes the event is received, sometimes it is not. Obviously if
> there is no such guarantee this could be permitted behavior.)
>
> Best,
> Laird
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What, if any, guarantees are made about invoking asynchronous event observer methods?

Martin Kouba
In reply to this post by Laird Nelson
Dne 11.5.2017 v 21:30 Laird Nelson napsal(a):

> I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
>
> If I fire an asynchronous event without any special notification
> options, my understanding is that the container will arrange for that
> event to be delivered to asynchronous observers.
>
> Is (appropriate) asynchronous observer method invocation guaranteed to
> happen at some point?  Section 10.2.2 seems to hint that it is:
>
> "Event fired [sic] with the fireAsync() method is [sic] fired
> asynchronously. *All the resolved asynchronous observers* (as defined in
> Observer resolution) *are called* in one or more different threads."
>
> To me, this says that if I use fireAsync() to fire an event, then if I
> have a (resolved) asynchronous observer method for it it will be
> notified before the container closes no matter what.

I think it's undefined. And I don't believe it would be reasonable to
block the container shutdown because of an async observer method waiting
for notification. The spec is clear that the container must destroy all
contexts when an application is stopped. And if we destroy the contexts
then the bean declaring the observer or its dependencies might be in
inconsistent state.

>
> (I believe I am observing a race condition somewhere in here that might
> show that Weld's default asynchronous event delivery machinery does not
> actually get around to delivering the event I've queued up before the
> container closes.  Sometimes the event is received, sometimes it is
> not.  Obviously if there is no such guarantee this could be permitted
> behavior.)
>
> Best,
> Laird
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What, if any, guarantees are made about invoking asynchronous event observer methods?

Martin Kouba
FYI there is already https://issues.jboss.org/browse/CDI-570 which seems
to be related.

Martin

Dne 12.5.2017 v 08:39 Martin Kouba napsal(a):

> Dne 11.5.2017 v 21:30 Laird Nelson napsal(a):
>> I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
>>
>> If I fire an asynchronous event without any special notification
>> options, my understanding is that the container will arrange for that
>> event to be delivered to asynchronous observers.
>>
>> Is (appropriate) asynchronous observer method invocation guaranteed to
>> happen at some point?  Section 10.2.2 seems to hint that it is:
>>
>> "Event fired [sic] with the fireAsync() method is [sic] fired
>> asynchronously. *All the resolved asynchronous observers* (as defined in
>> Observer resolution) *are called* in one or more different threads."
>>
>> To me, this says that if I use fireAsync() to fire an event, then if I
>> have a (resolved) asynchronous observer method for it it will be
>> notified before the container closes no matter what.
>
> I think it's undefined. And I don't believe it would be reasonable to
> block the container shutdown because of an async observer method waiting
> for notification. The spec is clear that the container must destroy all
> contexts when an application is stopped. And if we destroy the contexts
> then the bean declaring the observer or its dependencies might be in
> inconsistent state.
>
>>
>> (I believe I am observing a race condition somewhere in here that might
>> show that Weld's default asynchronous event delivery machinery does not
>> actually get around to delivering the event I've queued up before the
>> container closes.  Sometimes the event is received, sometimes it is
>> not.  Obviously if there is no such guarantee this could be permitted
>> behavior.)
>>
>> Best,
>> Laird
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What, if any, guarantees are made about invoking asynchronous event observer methods?

Laird Nelson
In reply to this post by Matej Novotny
On Thu, May 11, 2017 at 11:19 PM Matej Novotny <[hidden email]> wrote:
if I understand you correctly, there is no guarantee for that in Weld.

OK thanks.
 
If you fire an async event it will spin another thread (or more), where it will start notifying async observers.

Sure.  My question is: is there any guarantee that the asynchronous observer method will be called at all, regardless of whether it finishes?  I believe the answer is no.  That is, there are absolutely no semantics guaranteed about delivery (neither at-least-once nor at-most-once nor exactly-once).

So I've learned that in an SE setting anyway it is important to know that—depending on when the SeContainer is closed, obviously—some of your asynchronous observers may never be notified.  Additionally it is important to know that calling thenRun() (or other variants not ending in "Async") on the returned CompletionStage may very well not work, and its exceptionally() stuff may also never be called.
 
Only after it is done, it will come back to the main thread with result. There is no synchronization around this - that would kind of go against the nature of truly asynchronous calls, wouldn't it?

I understand that the container won't block waiting for the asynchronous method to come back.  As you say, that wouldn't be asynchronous (although you could make an argument that everything should be gathered up before the container closes, but I understand that's contentious and has a lot of overhead).

But I am interested in: is there any guarantee that the asynchronous observer method will be called?  The answer appears to be no.  (Another way to look at it is my questions are around the behavior of the returned CompletionStage.)

Martin referred me to https://issues.jboss.org/browse/CDI-570 which is another variant of my questions.
 
What exactly is your use case?

Well, now it's just curiosity. :-)  It looks like when SeContainer.close() is called, everything stops more or less immediately, regardless of what state anything is in (even if, say, your asynchronous observer has a bean injected into it that observes the closing of the scope).

Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What, if any, guarantees are made about invoking asynchronous event observer methods?

Laird Nelson
On Fri, May 12, 2017 at 10:08 AM Laird Nelson <[hidden email]> wrote:
Martin referred me to https://issues.jboss.org/browse/CDI-570 which is another variant of my questions.

I've put a Github repo up with some explorations that might be fun or interesting to people: https://github.com/ljnelson/weld-570

Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What, if any, guarantees are made about invoking asynchronous event observer methods?

Matej Novotny
Hi Laird,

Thanks for creating a reproducer straight away.
I took a glance at the repo and here is what I think:

TestScenario1/2 are pretty much what we are discussing here - the container terminates and observers don't get notified any more.
Obviously, if you hang any additional 'thenRun' etc. on top of that, it won't work either.


TestScenario3 is with Weld parallel mode and is IMO out of scope of previous discussion but important nonetheless.
This is indeed weird and I think you are observing a peculiar behaviour of default executor in SE, which is ForkJoinPool.
We have a test[1] for parallel execution in SE, where we defined your own executor (see 'createWeld' method) and it works like a charm.
I think we need to look into FJP to see what's truly going on there.

Matej

____________________________________________________________________________________________
[1]https://github.com/weld/core/blob/master/environments/se/tests/src/test/java/org/jboss/weld/environment/se/test/event/options/mode/NotificationModeTest.java#L63

----- Original Message -----

> From: "Laird Nelson" <[hidden email]>
> To: "cdi-dev" <[hidden email]>, "Matej Novotny" <[hidden email]>
> Sent: Friday, May 12, 2017 7:31:44 PM
> Subject: Re: [cdi-dev] What, if any, guarantees are made about invoking asynchronous event observer methods?
>
> On Fri, May 12, 2017 at 10:08 AM Laird Nelson <[hidden email]> wrote:
>
> > Martin referred me to https://issues.jboss.org/browse/CDI-570 which is
> > another variant of my questions.
> >
>
> I've put a Github repo up with some explorations that might be fun or
> interesting to people: https://github.com/ljnelson/weld-570
>
> Best,
> Laird
>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What, if any, guarantees are made about invoking asynchronous event observer methods?

Laird Nelson
On Mon, May 15, 2017 at 12:13 AM Matej Novotny <[hidden email]> wrote:
TestScenario1/2 are pretty much what we are discussing here - the container terminates and observers don't get notified any more.
Obviously, if you hang any additional 'thenRun' etc. on top of that, it won't work either.

Right.
 
TestScenario3 is with Weld parallel mode and is IMO out of scope of previous discussion but important nonetheless.

Yeah—this git repo was less a reproducer and more just me playing around. :-)
 
This is indeed weird and I think you are observing a peculiar behaviour of default executor in SE, which is ForkJoinPool.
We have a test[1] for parallel execution in SE, where we defined your own executor (see 'createWeld' method) and it works like a charm.
I think we need to look into FJP to see what's truly going on there.

Oh, that is interesting.  OK; thanks.

Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Loading...