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]
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 <rvansa(a)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 <rvansa(a)redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev