[cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage

[Martin Kouba (JIRA)]

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

Martin Kouba edited comment on CDI-563 at 10/19/15 11:09 AM:
-------------------------------------------------------------

bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method
It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.
bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor...
I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE.

I'm for:
* having {{CompletionStage}} in the CDI API
* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific
* declaring explicitly that *the context propagation is not guaranteed for ANY execution* (default execution, default async execution and custom async via a supplied Executor)

What do you think?


was (Author: mkouba):
bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method
It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.
bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor...
I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE.

I'm for:
* having {{CompletionStage}} in the CDI API
* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific
* declaring explicitly that *the context propagation is not guaranteed for asynchronous execution* (both the default and custom executor)

What do you think?

> 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
>
> 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)