[cdi-dev] async activation on observers, why not CompletableFuture

Wed Apr 1 16:27:46 EDT 2015

Hi,

On Wed, Apr 1, 2015 at 10:22 PM, José Paumard <jose.paumard at gmail.com>
wrote:

> Hmm I dont think so. If I write
> return new AsyncResult("Done in thread " +
> Thread.currentThread().getName()) ; // returns a Future<String>
>
> Then my code is not async at all, the get() call will just return my
> parameter, and no other thread will be used in that process.
>

The method that returns that result has already been called in another
thread. The AsyncResult type is just a wrapper to satisfy the return type.

It's only there because in Java a method signature can't both return a
Future<T> to the caller while simultaneously being implemented as returning
a T.

>
> If I write :
> return new executorService.submit(() -> "Done in thread " +
> Thread.currentThread().getName()}) ;
> Then I get an async call.
>
> BTW if you check the source code of the AsyncResult class (with a nice
> typo in it), its clearly written in it that it is not a real Future.
>
>
>
>>
>>
>>> Because this is a synchronous call, that has to return a Future. But on
>>> the other hand this is purely tehcnical code, that cant be put in the
>>> framework, since one can call directly an EJB method. So the return type
>>> has to be the one of the EJB method.
>>>
>>> With events the situation is different. On the calling side, I write
>>>
>>> completableFuture = event.fireAsync(payload) ; // type is
>>> CompletionStage<probably void since there are many observers and an allOf
>>> call>
>>>
>>> On the observing side I can write :
>>>
>>> public T observes(@Observes payload) { return t ; }
>>>
>>> And the framework will take care of wrapping this t in a
>>> CompletableFuture.allOf(...) with all the other observers to return it. So
>>> I dont have to deal myself with the technical aspects of calling ES myself.
>>> IMHO it leads to easier to write patterns.
>>>
>>
>> Why T then? And actually your explanation is my proposal but a on purpose
>> typing.
>>
>>
>>>
>>> José
>>>
>>>
>>>
>>> 2015-04-01 19:54 GMT+02:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>>>
>>>>
>>>>
>>>> 2015-04-01 19:43 GMT+02:00 José Paumard <jose.paumard at gmail.com>:
>>>>
>>>>> CompletionStage has a toCompletableFuture() method, that returns a
>>>>> CompletableFuture. So there is no limitation in returning CompletionStage.
>>>>> It could allow different implementation in the future than the only one we
>>>>> have so far : CompletableFuture, since one can build a CompletableFuture
>>>>> that wraps another implementation.
>>>>>
>>>>>
>>>> +1, missed it
>>>>
>>>>
>>>>> Problem with CF.allOf() and anyOf() is that they return resp. CF<Void>
>>>>> and CF<Object>, which is not very API friendly.
>>>>>
>>>>>
>>>> it is enough in enough cases IMO
>>>>
>>>>
>>>>> Having the observers writers to provide his own implementation of
>>>>> CompletableFuture is not that great imho. For the async EJB, all you can do
>>>>> is return executorService.submit(myTask). I understand why the API
>>>>> designers have chosen that, but I dont think it's that great. Correct me if
>>>>> I'm wrong, but I think that we have the opportunity to move that burden
>>>>> from the observers writers to the framework. And I think it would make the
>>>>> API easier to use.
>>>>>
>>>>>
>>>> What's your proposal? EJB API is quite nice to use and it integrates
>>>> smoothly with Future<>, not sure I get what's your issue is here.
>>>>
>>>>
>>>>> José
>>>>>
>>>>>
>>>>> 2015-04-01 10:08 GMT+02:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>>>>>
>>>>>> Hello Antoine,
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>> <http://www.tomitribe.com>
>>>>>>
>>>>>> 2015-04-01 9:55 GMT+02:00 Antoine Sabot-Durand <
>>>>>> antoine at sabot-durand.net>:
>>>>>>
>>>>>>> Hi Romain,
>>>>>>>
>>>>>>> Intersting proposal. As I felt reading you that we misse the
>>>>>>> CompletableFuture stuff in Java 8, I just repeat here that the agreed on
>>>>>>> fireAsync signatures
>>>>>>>
>>>>>>> <U extends T> CompletionStage<U> fireAsync(U event);
>>>>>>> and
>>>>>>> <U extends T> CompletionStage<U> fireAsync(U event, Executor
>>>>>>> executor);
>>>>>>>
>>>>>>> Yeah it’s CompletionStage because Jozef preferred using interfaces
>>>>>>> in our API, but I guess implementation will use CompletableFuture under the
>>>>>>> hood to avoid reinventing the wheel.
>>>>>>>
>>>>>>>
>>>>>> This sounds "normal" but JVM doesn't follow it with its utility
>>>>>> methods so basically today CompletionStage is super poor compared to
>>>>>> CompletionFuture so I'm tempted to say the impl is preferred here. I didn't
>>>>>> check what is the adoption of both in other framework, can validate or not
>>>>>> my thought maybe.
>>>>>>
>>>>>>
>>>>>>> With this approach your example:
>>>>>>>
>>>>>>> event.fireAsync(new LetTheWorldKnow()).thenRun(() ->
>>>>>>>> System.out.println("We did it!"));
>>>>>>>>
>>>>>>>
>>>>>>> will work without adding constraint on observer signature.
>>>>>>>
>>>>>>> Regarding the observer part, we already discuss similar approach. In
>>>>>>> a former version of my async event doc I proposed using return type on
>>>>>>> observer to do discrimination between async and sync and Mark made a
>>>>>>> suggestion near yours during this meeting:
>>>>>>>
>>>>>>>
>>>>>>> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-02-25-17.06.log.html
>>>>>>>
>>>>>>> (search for the first “signature” in text)
>>>>>>>
>>>>>>> The main drawback of this approach is to let end user generate the
>>>>>>> returned CompletableFuture. So each async observer should provide a way to
>>>>>>> construct this completableFuture. The second question is the type param of
>>>>>>> the returned CompletableFuture. Should we use raw type? Now we could
>>>>>>> imagine helped to do that but...
>>>>>>>
>>>>>>>
>>>>>> Exactly why I think this is a better solution. Cause it opens the
>>>>>> door to asynchronism in a more elegant manner handling completion properly.
>>>>>> I guess first impl will use allOf() combination but I see anyOf() - i fire
>>>>>> to "notifiers" and I care only of 1 at least being called as a caller - and
>>>>>> potentially other combinations other potentials needs we could cover in
>>>>>> another spec (hopefully).
>>>>>>
>>>>>> If async is just fire and forget we don't need fireAsync() but only
>>>>>> fire() (void) and then observers are async or not which ensures compat at
>>>>>> all levels since observers decide to be in the same context or not but I
>>>>>> guess we don't want only fire and forget.
>>>>>>
>>>>>> About creating a CompletableFuture we can do as in EJB spec and
>>>>>> provide version to use by observer impl (javax.ejb.AsyncResult).
>>>>>>
>>>>>>
>>>>>>> Don’t get me wrong, I’d love to find a solution based on this kind
>>>>>>> of idea, but I fear it will add more complexity than double activation.
>>>>>>>
>>>>>>> Antoine
>>>>>>>
>>>>>>>
>>>>>>> Le 1 avr. 2015 à 09:15, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>> a écrit :
>>>>>>>
>>>>>>> No, fireAsync is still needed for all the reason we mzntionned -
>>>>>>> strongest one being the fact we need a return type and cant change fire -
>>>>>>> but using the return type we have the double activation without introducing
>>>>>>> a new API. Said otherwise API stays natural on both sides which was my main
>>>>>>> fear with a fireAsync and an @ObservesAsync (or any other new api we talked
>>>>>>> about). And we have the bonus to be aligned on SE async which sounds quite
>>>>>>> interesting for the future.
>>>>>>> Le 1 avr. 2015 08:48, "Jozef Hartinger" <jharting at redhat.com> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>>  So instead of calling observers asynchronously you suggest turning
>>>>>>>> observers into producers of CompletableFuture that will then be completed
>>>>>>>> asynchronously?
>>>>>>>>
>>>>>>>> On 03/31/2015 06:21 PM, Romain Manni-Bucau wrote:
>>>>>>>>
>>>>>>>> // fire side
>>>>>>>> event.fireAsync(new LetTheWorldKnow()).thenRun(() ->
>>>>>>>> System.out.println("We did it!"));
>>>>>>>>
>>>>>>>>  // observer side
>>>>>>>> CompletableFuture iWantToKnow(@Observes LetTheWorldKnow event) {}
>>>>>>>>
>>>>>>>>  // impl behavior would be like
>>>>>>>> CompletableFuture.allOf(allObserverReturnedInstances) to be aligned on
>>>>>>>> CompletableFuture behavior I think
>>>>>>>>
>>>>>>>>  Am I clearer?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>> <http://rmannibucau.wordpress.com/> | Github
>>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>>>> <http://www.tomitribe.com/>
>>>>>>>>
>>>>>>>> 2015-03-31 18:15 GMT+02:00 Sven Linstaedt <sven.linstaedt at gmail.com
>>>>>>>> >:
>>>>>>>>
>>>>>>>>>  Hi Romain,
>>>>>>>>>
>>>>>>>>>  I am not sure, I have fully understand how an observer with CompletableFuture could
>>>>>>>>> look like. Could you give us an example?
>>>>>>>>>
>>>>>>>>>  Afair CompletableFuture was considered to be used in the
>>>>>>>>> "trigger" side in order to track async event invocation completion.
>>>>>>>>>
>>>>>>>>>  br, Sven
>>>>>>>>>
>>>>>>>>>  2015-03-31 18:00 GMT+02:00 Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com>:
>>>>>>>>>
>>>>>>>>>>  Hi guys,
>>>>>>>>>>
>>>>>>>>>>  on async topic if I followed we are at the point where we are
>>>>>>>>>> looking for an activation on the observer side.
>>>>>>>>>>
>>>>>>>>>>  Since Java 8 has now CompletableFuture it would be great to use
>>>>>>>>>> it. Today the spec doesnt use observer returned values so it is mainly a
>>>>>>>>>> bad practise to have one even if not strictly forbidden - BTW never saw it
>>>>>>>>>> in real applications - plus spec is not compatible - not specified at all -
>>>>>>>>>> with CompletableFuture since it is a new API so we can use it as a marker.
>>>>>>>>>>
>>>>>>>>>>  This is quite interesting for few reasons:
>>>>>>>>>> 1- we have our double activation
>>>>>>>>>> 2- API is user friendly (observer is async and has an async
>>>>>>>>>> signature)
>>>>>>>>>> 3- open door for future async enhancements (hopefully not in CDI)
>>>>>>>>>> with composition of these observers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Only point I'm not sure is should these observers support sync
>>>>>>>>>> events. I don't see anything blocking to do it but can have missed
>>>>>>>>>> something.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  wdyt?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>> <http://rmannibucau.wordpress.com/> | Github
>>>>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>>>>>> <http://www.tomitribe.com/>
>>>>>>>>>>
>>>>>>>>>>  _______________________________________________
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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.
>>>>>>>>
>>>>>>>>
>>>>>>>>  _______________________________________________
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Java le soir <http://blog.paumard.org> Cours Java en ligne
>>>>> <http://blog.paumard.org/cours-tutoriaux/>
>>>>> Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
>>>>> <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
>>>>> M : +33 6 76 82 91 47
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Java le soir <http://blog.paumard.org> Cours Java en ligne
>>> <http://blog.paumard.org/cours-tutoriaux/>
>>> Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
>>> <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
>>> M : +33 6 76 82 91 47
>>>
>>
>>
>
>
> --
> Java le soir <http://blog.paumard.org> Cours Java en ligne
> <http://blog.paumard.org/cours-tutoriaux/>
> Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
> <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
> M : +33 6 76 82 91 47
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/836b277b/attachment-0001.html 