[cdi-dev] async activation on observers, why not CompletableFuture
arjan tijms
arjan.tijms at gmail.com
Wed Apr 1 16:36:56 EDT 2015
Hi,
On Wed, Apr 1, 2015 at 10:25 PM, Romain Manni-Bucau <rmannibucau 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.
>>
>
> if the method has @Asynchronous it is, that is how the spec is defined.
> All other usages are not linked to asynchronism at all and es.submit(task)
> is not supposed to work before EJB 3.2.
>
Indeed. If you have:
@Asynchronous
public Future<String> doAsync() {
return new AsyncResult("Done in thread " +
Thread.currentThread().getName()) ;
}
And then from another location do:
String callerName = Thread.currentThread().getName();
String calleeName = bean.doAsync().get();
Then callerName is unequal to calleeName.
I've written an article a while back that uses AsyncResult as well in CDI
code that tries to emulate how EJB works. I hope it somewhat more clearly
demonstrates that AsyncResult is fully intended as a wrapper. See
http://jdevelopment.nl/cdi-based-asynchronous-alternative
Kind regards,
Arjan Tijms
>
>
>> 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.
>>
>>
> Sure cause the container provides the async mecanism and this class is
> just here to make the impl trivial to do for user.
>
>
>>
>>
>>>
>>>
>>>> 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/31a4d6e3/attachment-0001.html
More information about the cdi-dev
mailing list