<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, May 11, 2017 at 11:19 PM Matej Novotny <<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">if I understand you correctly, there is no guarantee for that in Weld. </blockquote><div><br></div><div>OK thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you fire an async event it will spin another thread (or more), where it will start notifying async observers.<br></blockquote><div><br></div><div>Sure. My question is: is there any guarantee that the asynchronous observer method will be <i>called</i> 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).</div><div><br></div><div>So I've learned that in an SE setting anyway it is important to know that—depending on when the <font face="monospace">SeContainer</font> is closed, obviously—some of your asynchronous observers may never be notified. Additionally it is important to know that calling <font face="monospace"><a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#thenRun-java.lang.Runnable-">thenRun()</a></font> (or other variants not ending in "<font face="monospace">Async</font>") on the returned <font face="monospace"><a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html">CompletionStage</a></font> may very well not work, and its <font face="monospace"><a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#exceptionally-java.util.function.Function-">exceptionally()</a></font> stuff may also never be called.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>I understand that the container won't block waiting for the asynchronous method to <i>come back</i>. 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).</div><div><br></div><div>But I <i>am</i> interested in: is there any guarantee that the asynchronous observer method will be <i>called</i>? The answer appears to be no. (Another way to look at it is my questions are around the behavior of the returned <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html"><font face="monospace">CompletionStage</font></a>.)</div><div><br></div><div>Martin referred me to <a href="https://issues.jboss.org/browse/CDI-570">https://issues.jboss.org/browse/CDI-570</a> which is another variant of my questions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What exactly is your use case?<br></blockquote><div><br></div><div>Well, now it's just curiosity. :-) It looks like when <font face="monospace">SeContainer.close()</font> 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).</div><div><br></div><div>Best,</div><div>Laird</div></div></div>