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

2015-04-01 22:04 GMT+02:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > > > 2015-04-01 21:46 GMT+02:00 José Paumard <jose.paumard(a)gmail.com&gt;: > >> > 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(a)gmail.com&gt;: >> >>> >>> >>> 2015-04-01 19:43 GMT+02:00 José Paumard <jose.paumard(a)gmail.com&gt;: >>> >>>> 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(a)gmail.com&gt;: >>>> >>>>> 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(a)sabot-durand.net&gt;: >>>>> >>>>>> 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-de... >>>>>> >>>>>> (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(a)gmail.com&gt; >>>>>> 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(a)redhat.com&gt; 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(a)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(a)gmail.com&gt;: >>>>>>>> >>>>>>>>> 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(a)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@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(a)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(a)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