[infinispan-dev] Cache Java 8 API proposal - First draft

[Radim Vansa]

On 03/18/2015 05:27 PM, Galder Zamarreño wrote:
> Thanks Radim for the great feedback, comments inline:
>
>> On 13 Mar 2015, at 10:20, Radim Vansa <rvansa at redhat.com> wrote:
>>
>> Q1: What about versions? I really like the approach taken for
>> conditional operations in RemoteCache, because versions (as opposed to
>> replace(key, old, new)) get rid of ABA problems, wouldn't have problems
>> in return values after operation retry during topology change, reduce
>> overhead of sending big old values etc... The functional API luckily
>> allows 'any' operation, but this seems to me as such an useful
>> functionality that we should not force users implementing versions in
>> their values (unless they want to); versions should be part of Metadata
>> (at least I hope so - see CacheEntry vs. Metadata thread). Since this
>> API should be the most comprehensive one on which we'll build even more
>> complicated data structures than atomic counters, I somehow lack the
>> access to Metadata there (though I understand that you didn't want to
>> bloat it).
> ^ `Value` class will expose metadata and versioning information somehow, but as said in the proposal, there are still some things that need to be added.
>
> Exposing version of the existing entry to the functions is crucial because one of the problems I'm trying to find a good solution for is [1] (see also slides in [2] that I prepared for Berlin). The problem there is that existing replace() is only atomic when comparing objects by equality, and the `eval` method design will allow you to customize that comparison the way you want, and in fact for Hot Rod, we'd compare using version information. E.g. here's how it could work (TBD!):
>
> CompletableFuture<Boolean> replaced = functionalCache.eval("e", v -> {
>     if (v.version().equals(userProvidedVersion)) return true;
>     else return false;
> });
>
> [1] https://issues.jboss.org/browse/ISPN-4972
> [2] https://dl.dropboxusercontent.com/u/6148072/berlin-2015-galder-versionedreplace.pdf

I didn't expect that you forgot about versions, I just think that if 
this is not in the suggested API now, it's too early to review it. So 
you expect that version/metadata getters and setters will be part of the 
Value interface (as opposed to second argument to the lambda)? I am 
looking forward to updated wiki.

>
>> Q2: For performance, I would expect that a (replicated?) cache for
>> well-known/registered lambdas could be useful. Then, you'd need the
>> functional API with direct lambda IDs - you don't want to do the map
>> lookup every time. Or any other ideas? I think you said that you
>> benchmarked the serialization overhead, can you present the numbers?
> I've pinged David, JBoss Marshalling creator, to get some tips about this and I also plan to check with other Java 8 gurus such as Mario, but from what I can understand, there's three parts to a lambda:
>
> - the lambda function class instance itself
> - the parameters you pass in to the lambda
> - any objects captured/referenced by the lambda
>
> I think the lambda functions can be cached but of course, the parameters nor captured objects can't. When we create Map/ConcurrentMap/JCache decorators, we'll control the decorator contents and we'd have the chance to do whatever caching we need. I don't think we even need to replicate them at all since the classes themselves will cache the functions.

I don't really understand the last sentence. Let's consider only the 
function class instance; how that would be cached in the decorators? 
Because even if you send the same instance twice, IMO, it will be sent 
over the wire twice, Marshalling won't do any caching magic on its own. 
Or am I mistaken? And will the FunctionalCache API directly support this 
caching anyhow (such as version of methods with ID instead of the lambda)?

>
> So, that would leave parameters and captured/referenced objects to be serialized since that's the variable part. Not sure if these two can be serialized independently. Parameters maybe but captured objects might be tough.
>
> I've not done benchmarking yet.
>
>> Q3: Do you expect that in non-tx mode the primary will replicate to
>> backup the lambda, or full value? With non-trivial lambdas, after node
>> crash when the backups have different values, this can lead to forever
>> diverging values. But yes, this could be chosen with a flag.
> You'd replicate the lambda (or if you can cache it, then somehow avoid sending all its info), along with parameters, and any capture values. So, for `Map.put` implementation function you are replicating, it includes the full value.
>
> If you're trying to store a data structure and and non-tx, there's indeed a chance of having partially applied updates. We'd need some merging here possibly...

Let's have the increment() lambda; during topology change, this could 
arrive to the backup two times. Merging does not help much if you want 
to implement atomic counters in cache.

Radim

>
> Cheers,
>
>> Radim
>>
>> On 03/13/2015 09:10 AM, Galder Zamarreño wrote:
>>> Hi all,
>>>
>>> We're starting to work on some prototypes for the Java 8 API coming up in Infinispan 8.
>>>
>>> I've written a design wiki for a replacement of our main embedded Cache interface that takes advantage of Java 8 improvements:
>>> https://github.com/infinispan/infinispan/wiki/Java-8-API-proposal
>>>
>>> It'd be great to hear your thoughts.
>>>
>>> Proposals for Java 8 versions for cache manager, remote cache and other external APIs are yet TBD.
>>>
>>> Regards,
>>> --
>>> Galder Zamarreño
>>> galder at redhat.com
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> galder at redhat.com
>
>
>
>
>
> _______________________________________________
> 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