[cdi-dev] 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" <ljnelson at gmail.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> 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
> cdi-dev at lists.jboss.org
> 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.