[cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously

José Paumard (JIRA) issues at jboss.org
Wed Jan 21 06:37:49 EST 2015

    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034053#comment-13034053 ] 

José Paumard commented on CDI-499:

2 things : 
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement. 

- the signature of the fireAsync is <U extends T> CompletionStage<U> fireAsync(U event);
I think we need to add a 2nd method that takes an Executor as a parameter, for 2 reasons : 
- it would stick to the CompletionStage patterns
- in a Java EE world, it would allow one to state that the processing of the event should take place in a ManagedExecutorService, obtained by injection, that the BeanManager might not be aware of. 

> Firing events asynchronously 
> -----------------------------
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  

This message was sent by Atlassian JIRA

More information about the cdi-dev mailing list