Asynchronous events question

[ljnelson]

The CDI 2.0 specification seems a little light in the area of asynchronous events.

Specifically, if I call fireAsync():

• I assume the notification task used behind the scenes is guaranteed to be submitted to the Executor responsible for running it (either one I supply via NotificationOptions or one used by the implementation)
• In SE, will the container wait to shut down until all pending fireAsync() calls have been dispatched, or is it legal for the container to drop event submissions on the floor?  I seem to recall that the container will shut down.
• Is there any guarantee made about notification order?  I suppose not, since "[a]ll the resolved asynchronous observers (as defined in Observer resolution) are called in one or more different threads."

So if you fireAsync():

• Delivery is not guaranteed since the container can close "early"
• Order is not guaranteed since there might be many threads performing notification

Is that correct?

[mkouba]

I think none of that is specified, therefore it's left to the implementations. So delivery in Weld - it depends on the executor used, i.e. if using daemon threads (all executors in Weld by default) an observer notification does not prevent the JVM from exiting. Note that even if an executor uses user threads the container itself may be already shut down before the notification finishes, i.e. contexts will be destroyed etc. Ordering of async observers in Weld - if serial notification mode is used (default, see also Chapter 11. Events ) Weld should honor the javax.annotation.Priority annotations used.

[ljnelson]

mkouba  wrote:

I think none of that is specified, therefore it's left to the implementations. So delivery in Weld - it depends on the executor used, i.e. if using daemon threads (all executors in Weld by default) an observer notification does not prevent the JVM from exiting. Note that even if an executor uses user threads the container itself may be already shut down before the notification finishes, i.e. contexts will be destroyed etc. Ordering of async observers in Weld - if serial notification mode is used (default, see also Chapter 11. Events ) Weld should honor the javax.annotation.Priority annotations used.

Thanks.  One last question.  To belabor the obvious, in serial mode, this is required to mean that all observers of a given event are notified on the same thread, right?  So observer 1's observer method will be called synchronously and will complete, and then observer 2's observer method will be called synchronously and will complete, and then observer 3's observer method will be called synchronously and will complete?  And all of this activity will take place on a single dedicated thread that is not the main container thread?

I understand your point about priority ordering.

In English, "your first priority" is equal to "your highest priority", and "your second priority" is a lower priority than "your first priority".  I suspect that is not how javax.annotation.Priority works.  I assume that something annotated with @Priority(2) is to be preferred over something with @Priority(1)?

[mkouba]

Thanks.  One last question.  To belabor the obvious, in serial mode, this is required to mean that all observers of a given event are notified on the same thread, right?  So observer 1's observer method will be called synchronously and will complete, and then observer 2's observer method will be called synchronously and will complete, and then observer 3's observer method will be called synchronously and will complete?  And all of this activity will take place on a single dedicated thread that is not the main container thread?

Exactly. The idea behind this concept is that it's a caller of Event.fireAsync() that benefits from asynchronicity and observers should not care about each other.

In English, "your first priority" is equal to "your highest priority", and "your second priority" is a lower priority than "your first priority".  I suspect that is not how javax.annotation.Priority works.  I assume that something annotated with @Priority(2) is to be preferred over something with @Priority(1)?

There was a discussion in CDI EG (see also [cdi-dev] [Vote] @Priority value order on ordered events ) and (unfortunately) my proposal did not pass. And so: "Observers with smaller priority values are called first." (see also JSR 365: Contexts and Dependency Injection for Java 2.0: ).