[cdi-dev] async activation on observers, why not CompletableFuture
José Paumard
jose.paumard at gmail.com
Wed Apr 1 16:22:40 EDT 2015
2015-04-01 22:04 GMT+02:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>
>
> 2015-04-01 21:46 GMT+02:00 José Paumard <jose.paumard at gmail.com>:
>
>> > 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.
>> EJB has me to write this kind of code :
>>
>> return es.submit(myTask) ;
>>
>>
> this looks wrong, return new AsyncFuture<String>("i did it"); is what you
> should have written otherwise you just didnt use EJB async feature.
>
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/1a2e0cea/attachment-0001.html
More information about the cdi-dev
mailing list