<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 03/12/2015 01:56 PM, Antoine
Sabot-Durand wrote:<br>
</div>
<blockquote
cite="mid:C24390F8-63BB-478A-A188-69CDEDE14026@sabot-durand.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hi all,
<div class=""><br class="">
</div>
<div class="">I compiled all the feedback and decision we took
regarding async events and updated the Google Doc : <a
moz-do-not-send="true"
href="https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing"
class="">https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing</a></div>
<div class=""><br class="">
</div>
<div class="">The following point stays open. I’d like to close
them (if possible) during the next meeting on Tuesday</div>
<div class=""><br class="">
</div>
<div class="">1) Async delivery mechanism (comment by Jozef)</div>
<div class="">Should we write in the spec about how threads for
events delivery should be used? Personally I’d rather not: I
think this should be let to implementation, the specification
should only describe the expected behavior (concurrency or not).
now I may have missed something.</div>
</blockquote>
We should not specify technical details assuming we clearly define
what guarantees are/are not available regarding ordering,
visibility, concurrency, effects of exceptions,
CDI/security/transactional context propagation and perhaps others I
missed.<br>
<blockquote
cite="mid:C24390F8-63BB-478A-A188-69CDEDE14026@sabot-durand.net"
type="cite">
<div class=""><br class="">
</div>
<div class="">2) Exception Handling (comment by Jozef)</div>
<div class="">I didn’t write anything about exception and we
should decide what happens if an exception occurs in an observer
during async event dispatch. I think that it shouldn’t impact
other observers and that we should stick to the way
CompletionStage API works today.</div>
</blockquote>
<br>
What does it mean? CompletionStage API allows you to handle (a
single) Exception. Would those exceptions be swallowed or provided
to the caller somehow?<br>
<blockquote
cite="mid:C24390F8-63BB-478A-A188-69CDEDE14026@sabot-durand.net"
type="cite">
<div class=""><br class="">
</div>
<div class="">3) Async event activation on both ends</div>
<div class="">We all agree that we need to explicitly fire event
asynchronously on the producer side (fireAsync()). The
discussion in 8.1 is about adding a way to accept async call on
the consumer (observer) side.</div>
<div class="">a) As events are often triggered in other parts of
the application than the parts that consume them (most CDI
framework lib fire events foe end user code) preventing user to
decide if an observer can be called asynchronously could lead to
issues and will prevent library developper to use fireAsync()
(in a defensive coding approach).</div>
<div class="">b) On the other hand, when placed in the same
application, it’ll be very confusing for user to have to
fireAsync() and enable async observer to activate this new
feature.</div>
<div class=""><br class="">
</div>
<div class="">I propose an opt-out approach. We add
‘asyncSupported' member to ‘@Observes' annotation with ‘true’ as
default value. So in case of b) the end user won’t have to
explicitly activate async on observer and i case of a) user
detecting issue coming from async treatment of an event can
explicitly declares one or more observer not compatible with
async resolution with @Observes(asyncSupported=False)</div>
<div class=""><br class="">
</div>
<div class="">4) Support observer ordering with async events</div>
<div class="">I think we should keep event ordering for
synchronous event and ignore this feature in async event. I
don’t see obvious use case to be async and ordered.</div>
</blockquote>
if an observer O1 defines priority P1 and a different observer O2
defines P2 where P2 > P1 then it probably does that for a reason.
Most likely because O2 depends on the state changes possibly
performed by O1. I think this holds true no matter if the event is
fired synchronously or asynchronously. Therefore, I think we should
respect priority in both cases.<br>
<br>
In addition, the observer ordering concept will be simpler if we
treat observers the same way in both sync and async.<br>
<blockquote
cite="mid:C24390F8-63BB-478A-A188-69CDEDE14026@sabot-durand.net"
type="cite">
<div class=""><br class="">
</div>
<div class="">5) Context propagation</div>
<div class=""> I understand that propagating contexts in async
event would impact easily context API. My only concern here is
to be define async event to keep this feature possible.</div>
<div class=""><br class="">
</div>
<div class="">If I forgot points please comment this mail and the
doc so we can take final decision during next meeting.</div>
<div class=""><br class="">
</div>
<div class="">Thank you</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Antoine</div>
<div class=""><br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cdi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a class="moz-txt-link-freetext" href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</pre>
</blockquote>
<br>
</body>
</html>