[cdi-dev] What, if any, guarantees are made about invoking asynchronous event observer methods?

[Laird Nelson]

On Thu, May 11, 2017 at 11:19 PM Matej Novotny <manovotn at 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()
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#thenRun-java.lang.Runnable->
(or other variants not ending in "Async") on the returned CompletionStage
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html>
may very well not work, and its exceptionally()
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#exceptionally-java.util.function.Function->
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
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html>
.)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170512/667df85e/attachment.html