[cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
Antoine Sabot-Durand (JIRA)
issues at jboss.org
Mon Nov 30 05:24:00 EST 2015
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antoine Sabot-Durand updated CDI-563:
-------------------------------------
Fix Version/s: 2.0-EDR2
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
> Fix For: 2.0-EDR2
>
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the cdi-dev
mailing list