Yes [1]. The longest chaining of operations I had in [2], basically during ST I have to load a value locally*, perform a unicast/broadcast to read different value and then execute the original one.
* I shouldn't load it just from DC, as it could be in cache store, too; though without persistence (which I don't deal with properly in scattered cache yet) it would be more efficient to do the DC lookup directly. Radim [1] https://github.com/rvansa/infinispan/tree/ISPN-6645 [2] https://github.com/rvansa/infinispan/blob/ISPN-6645/core/src/main/java/org/infinispan/interceptors/impl/PrefetchInvalidationInterceptor.java On 06/17/2016 10:52 AM, Galder Zamarreño wrote: > Radim, do you have a branch where you have been trying these things out? I'd > like to play with what you're trying to do. > > Cheers, > -- > Galder Zamarreño > Infinispan, Red Hat > >> On 8 Jun 2016, at 14:23, Radim Vansa <rva...@redhat.com> wrote: >> >> Hi, >> >> I would like to encourage you to play with the (relatively) new API for >> sequential interceptors, and voice your comments - especially you corish >> devs, and Galder who has much experience with async invocations and that >> kind of stuff from JS-world. >> >> I am now trying to use the asynchronous methods only (the >> forkInvocationSync() is only temporary helper!); Dan has made it this >> way as he wanted to avoid unnecessary allocations, and I welcome this >> GC-awareness, but regrettably I find it rather hard to use, due to its >> handler-style nature. For the simplest style interceptors (do this, >> invoke next interceptor, and process result) it's fine, but when you >> want to do something like: >> >> visitFoo(cmd) { >> Object x = null; >> if (/* ... */) { >> x = invoke(new OtherCommand()); >> } >> invoke(new DifferentCommand(x)); >> Object retval = invoke(cmd); >> return wrap(retval); >> } >> >> I find myself passing handlers deep down. There is allocation cost for >> closures, so API that does not allocate CompletableFutures does not pay off. >> >> I don't say that I could improve it (I have directed my comments to Dan >> on IRC when I had something in particular), I just say that this is very >> important API for further Infinispan development and everyone should pay >> attention before it gets final. >> >> So please, play with it, and show your opinion. >> >> Radim >> >> -- >> Radim Vansa <rva...@redhat.com> >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
