On Thu, May 11, 2017 at 11:19 PM Matej Novotny <manovotn@redhat.com> 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