[infinispan-dev] Sequential interceptors API

[Radim Vansa]

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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team