[cdi-dev] Behavior of CDI fireAsync when using CompletionStage.whenCompleteAsync

[Martin Kouba]

Hi John,

I don't think it's a problem. I believe users should not care about 
these implementation details at all. The only thing which is guaranteed 
is that async observers and eventual async callbacks are executed 
asynchronously and do not block the thread from where the event was fired.

For completeness - Weld SE is using fork-join pool by default (and this 
could be changed by means of org.jboss.weld.executor.threadPoolType). 
See also 
http://docs.jboss.org/weld/reference/latest-master/en-US/html/configure.html#_thread_pool_configuration.

Martin

Dne 7.3.2017 v 04:16 John Ament napsal(a):
> Run into an interesting issue.  Not sure if its an RI problem, or
> something else.  Actually not even sure if its a problem just surprised me.
>
>
> I have two very simple main methods here:
>
>
> try(SeContainer container = SeContainerInitializer.newInstance()
> .addPackages(Pojo.class)
> .disableDiscovery()
> .initialize()) {
> Event<Object> event = container.getBeanManager().getEvent();
> FixedThreadPoolExecutorServices executorServices = new
> FixedThreadPoolExecutorServices(2);
> CompletionStage<Pojo> completionStage = event.fireAsync(new Pojo("this
> is asynchronous"),
> NotificationOptions.ofExecutor(executorServices.getTaskExecutor()));
> completionStage.whenCompleteAsync((pojo, throwable) -> event.fire(new
> Pojo(pojo.showName() + ", and now this is synchronous")));
> Thread.sleep(500L);
> }
>
> public static void main(String...args) throws Exception{
> try(SeContainer container = SeContainerInitializer.newInstance()
> .addPackages(Pojo.class)
> .disableDiscovery()
> .initialize()) {
> Event<Object> event = container.getBeanManager().getEvent();
> CompletionStage<Pojo> completionStage = event.fireAsync(new Pojo("this
> is asynchronous"));
> completionStage.whenCompleteAsync((pojo, throwable) -> event.fire(new
> Pojo(pojo.showName() + ", and now this is synchronous")));
> Thread.sleep(500L);
> }
> }
>
>
> In the first, I'm using a custom executor (a 2 thread pool executor) and
> the latter just using the default unspecified version, which weld seems
> to use a fork-join pool.  In both of these examples, I use the
> whenCompleteAsync method.  in the first method, I always see the fired
> event being handled in a different thread than what handled the first
> event.  In the second method, I always see the fired events both being
> handled in the same thread.  Is that just the behavior of fork-join? Or
> something special happening?
>
>
> John
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic