3:10 a.m.
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(a)redhat.com
4:20 a.m.
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).
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?
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.
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(a)redhat.com
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
11:27 a.m.
Thanks Radim for the great feedback, comments inline:
On 13 Mar 2015, at 10:20, Radim Vansa <rvansa(a)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-versionedr...
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.
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...
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(a)redhat.com
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
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
--
Galder Zamarreño
galder(a)redhat.com
12:23 p.m.
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(a)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-versionedr...
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(a)redhat.com
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> 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
--
Galder Zamarreño
galder(a)redhat.com
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
3:39 a.m.
Hi Galder,
apologies for the long reply !
imo the value of Java 8 is:
#1 Reduction of implementation code (streams and internal iteration)
#2 Making some of the APIs simpler, e.g. distributed executors, map-reduce
#3 Reactive programming, e.g. interceptor chain (discussed in Berlin),
non-blocking behavior; the goal being to reduce the number of threads
required.
However, changing the entire Cache API is going too far atm. Now that
we've finally provided a Cache/JSR107 API, people are familiar with it
and I would not change it, at least not right now.
If we're able to use reactive programming (e.g. your eval() function)
*under the cover*, then all the better.
If your proposal is about providing FunctionalCache and implementing
Cache and JSR 107 Cache with it, then you have my +1. But IMO
FunctionalCache should not be the main API.
Compare FunctionalCache.eval() to ioctl() for a moment: of course, every
access to a file system can be implemented via ioctl(), but people like
the simplicity of write(), read(), stat() etc.
So providing eval() *only* shifts the burden of implementation to the
user. But I agree that perhaps it's a good thing to expose
FunctionalCache so power users (e.g. Sanne :-)) can use it directly to
implement functionality not provided by Cache.
Being able to switch to Java 8 doesn't imply we have to use all of its
new features.
Let me address your proposal step by step.
"What's wrong with the Infinispan Cache API?"
--------------------------------------
- Nothing !
- I can't follow your argument as to why Cache is bad. This is the
premise to your proposal and it needs to be very clear !
- JSR 107 came up with a similar API. So if we have to change Cache,
then I'd +1 a change to JSR 107 as main API
- I don't see why it's difficult to add new operations: distributed
queues should be a separate API anyway, and not extend Cache ! We should
use CacheManager to get a new DistributedQueue, as we do to get a new
Cache...
"How does Java 8 improve on this?"
------------------------------
- Passing serialized lambdas around sounds awfully familiar: it's the
old 'agent-based programming' paradigm fashionable before the turn of
the millenium. Instead of invoking RPCs which carry data on P, code
(also carrying data) is shipped to P and executed there and the result
sent back to the invoker. (Disclaimer: I wrote such a system myself with
GOMScript... :-().
I'm not saying this is bad, but we have to make sure that
(a) Infinispan benefits from this either in code reduction /
maintainability / code simplification
(b) performance doesn't decrease
"Proposal"
---------
- Returning a CompletableFuture is a good idea: +1
- I think this is where the main value of your proposal lies: being able
to chain functions (lambdas) together, that are invoked turn-by-turn,
possibly by different threads, without a caller having to block
- The F.invoke(G).andThenInvoke(H).andThenInvoke(I) pattern (where F is
a future and G,H,I are lambdas) is very valuable to implement
non-blocking behavior: whenever a function (lambda) has to block, it
registers a function with the blocking resource that's called upon
unblocking and the thread terminates and is added back to the thread pool
- Blocking can be waiting to read from the file system or network, or
trying to acquire a lock etc
- As was discussed in Berlin, the interceptor chain could be rewritten
using CompletableFutures (or sth similar).
Summary
--------
I'd not make FunctionalCache the main API and I'd definitely not
deprecate Cache.
+1 on providing FunctionalCache as a (parent) interface to Cache, so
power users can use FunctionalCache if needed.
+1 on implementing Cache and JSR 107 Cache with FunctionalCache.
This should only be done if:
- Performance remains at least as good as it is now [mandatory]
- Maintainability increases [nice]
- Code reduction [nice]
My 5 cents
On 13/03/15 09:10, 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(a)redhat.com
--
Bela Ban, JGroups lead (http://www.jgroups.org)
4:18 a.m.
On 14 Mar 2015, at 09:39, Bela Ban <bban(a)redhat.com> wrote:
Hi Galder,
apologies for the long reply !
Haha, it's still sorter than my proposal, so not too bad :)
imo the value of Java 8 is:
#1 Reduction of implementation code (streams and internal iteration)
#2 Making some of the APIs simpler, e.g. distributed executors, map-reduce
#3 Reactive programming, e.g. interceptor chain (discussed in Berlin),
non-blocking behavior; the goal being to reduce the number of threads
required.
I've heard a lot about ^, looking forward to seeing design doc.
I was discussing Java 8 API with others while you were having this discussion.
However, changing the entire Cache API is going too far atm. Now that
we've finally provided a Cache/JSR107 API, people are familiar with it
and I would not change it, at least not right now.
You are missing essence of the proposal:
There's no unique way in which people want to access a Cache. Some people want to use
ConcurrentMap, others want to use JSR-107 Cache API, others might want to use Infinispan
7 Cache API, others just want to store data and run map/reduce jobs...
I'm not suggesting that we change the entire Cache API. What I'm suggesting is
this: Java 8 allows us the vast majority of caching use cases to be distilled into a
reduced, flexible API, which can be the foundation for the facade's that we offer.
IOW, we're not forcing anyone to use the new Cache API. If you want, you can, but the
vast majority of users will use APIs they know (JSR-107, java.util.concurrent).
It's about choice, not about having a new main API. IOW, use whatever API you want,
but if youw want flexibility, we have something for you that will allow you to build more
interesting data structures on top of this functional cache API.
If we're able to use reactive programming (e.g. your eval()
function)
*under the cover*, then all the better.
If your proposal is about providing FunctionalCache and implementing
Cache and JSR 107 Cache with it, then you have my +1. But IMO
FunctionalCache should not be the main API.
^ You're getting main point but you are wrongly believing that I want Functional Cache
to be the main API.
Functional Cache will offer the basis to provide whatever API you want, but it should
never be the first choice for users to use.
IMO, the users of Functional Cache would be advanced users that say, want to build a
distributed queue on top of Infinispan.
There should not be a main API going forward, but choice: JSR-107 API,
java.util.concurrent...,etc
Compare FunctionalCache.eval() to ioctl() for a moment: of course,
every
access to a file system can be implemented via ioctl(), but people like
the simplicity of write(), read(), stat() etc.
So providing eval() *only* shifts the burden of implementation to the
user. But I agree that perhaps it's a good thing to expose
FunctionalCache so power users (e.g. Sanne :-)) can use it directly to
implement functionality not provided by Cache.
+1000, that's precisely the vision I have, but again Functional Cache is not forced on
them.
Being able to switch to Java 8 doesn't imply we have to use all
of its
new features.
Totally.
Let me address your proposal step by step.
"What's wrong with the Infinispan Cache API?"
--------------------------------------
- Nothing !
- I can't follow your argument as to why Cache is bad. This is the
premise to your proposal and it needs to be very clear !
- JSR 107 came up with a similar API. So if we have to change Cache,
then I'd +1 a change to JSR 107 as main API
- I don't see why it's difficult to add new operations: distributed
queues should be a separate API anyway, and not extend Cache ! We should
use CacheManager to get a new DistributedQueue, as we do to get a new
Cache...
^ Right, I think all this section needs to be rewritten to avoid confusion.
"How does Java 8 improve on this?"
------------------------------
- Passing serialized lambdas around sounds awfully familiar: it's the
old 'agent-based programming' paradigm fashionable before the turn of
the millenium. Instead of invoking RPCs which carry data on P, code
(also carrying data) is shipped to P and executed there and the result
sent back to the invoker. (Disclaimer: I wrote such a system myself with
GOMScript... :-().
I'm not saying this is bad, but we have to make sure that
(a) Infinispan benefits from this either in code reduction /
maintainability / code simplification
(b) performance doesn't decrease
^ +1, performance at least for the most critical operations, e.g. put/get, needs to be at
least on par.
"Proposal"
---------
- Returning a CompletableFuture is a good idea: +1
- I think this is where the main value of your proposal lies: being able
to chain functions (lambdas) together, that are invoked turn-by-turn,
possibly by different threads, without a caller having to block
- The F.invoke(G).andThenInvoke(H).andThenInvoke(I) pattern (where F is
a future and G,H,I are lambdas) is very valuable to implement
non-blocking behavior: whenever a function (lambda) has to block, it
registers a function with the blocking resource that's called upon
unblocking and the thread terminates and is added back to the thread pool
- Blocking can be waiting to read from the file system or network, or
trying to acquire a lock etc
- As was discussed in Berlin, the interceptor chain could be rewritten
using CompletableFutures (or sth similar).
^ Yeah, there's a lot of value to be added in this area.
I was very pleased to hear about the CompletableFuture based interceptor chain discussion
because I thought it'd fit perfectly with the direction of the functional cache API.
Summary
--------
I'd not make FunctionalCache the main API and I'd definitely not
deprecate Cache.
Ok, maybe we won't deprecate Infinispan Cache but we'll definitely won't add
anything extra there. It's way too ovebloated IMO.
+1 on providing FunctionalCache as a (parent) interface to Cache, so
power users can use FunctionalCache if needed.
+1 on implementing Cache and JSR 107 Cache with FunctionalCache.
This should only be done if:
- Performance remains at least as good as it is now [mandatory]
- Maintainability increases [nice]
- Code reduction [nice]
My 5 cents
+1 to all those.
Thanks Bela for the feedback!
On 13/03/15 09:10, 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(a)redhat.com
--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
3:29 a.m.
OK, then we're on the same page, just wanted to verify. Re the design
doc wrt interceptors, contact Radim
Cheers
On 20/03/15 10:18, Galder Zamarreño wrote:
> On 14 Mar 2015, at 09:39, Bela Ban <bban(a)redhat.com> wrote:
>
> Hi Galder,
>
> apologies for the long reply !
Haha, it's still sorter than my proposal, so not too bad :)
> imo the value of Java 8 is:
>
> #1 Reduction of implementation code (streams and internal iteration)
>
> #2 Making some of the APIs simpler, e.g. distributed executors, map-reduce
>
> #3 Reactive programming, e.g. interceptor chain (discussed in Berlin),
> non-blocking behavior; the goal being to reduce the number of threads
> required.
I've heard a lot about ^, looking forward to seeing design doc.
I was discussing Java 8 API with others while you were having this discussion.
> However, changing the entire Cache API is going too far atm. Now that
> we've finally provided a Cache/JSR107 API, people are familiar with it
> and I would not change it, at least not right now.
You are missing essence of the proposal:
There's no unique way in which people want to access a Cache. Some people want to use
ConcurrentMap, others want to use JSR-107 Cache API, others might want to use Infinispan
7 Cache API, others just want to store data and run map/reduce jobs...
I'm not suggesting that we change the entire Cache API. What I'm suggesting is
this: Java 8 allows us the vast majority of caching use cases to be distilled into a
reduced, flexible API, which can be the foundation for the facade's that we offer.
IOW, we're not forcing anyone to use the new Cache API. If you want, you can, but the
vast majority of users will use APIs they know (JSR-107, java.util.concurrent).
It's about choice, not about having a new main API. IOW, use whatever API you want,
but if youw want flexibility, we have something for you that will allow you to build more
interesting data structures on top of this functional cache API.
> If we're able to use reactive programming (e.g. your eval() function)
> *under the cover*, then all the better.
>
> If your proposal is about providing FunctionalCache and implementing
> Cache and JSR 107 Cache with it, then you have my +1. But IMO
> FunctionalCache should not be the main API.
^ You're getting main point but you are wrongly believing that I want Functional
Cache to be the main API.
Functional Cache will offer the basis to provide whatever API you want, but it should
never be the first choice for users to use.
IMO, the users of Functional Cache would be advanced users that say, want to build a
distributed queue on top of Infinispan.
There should not be a main API going forward, but choice: JSR-107 API,
java.util.concurrent...,etc
> Compare FunctionalCache.eval() to ioctl() for a moment: of course, every
> access to a file system can be implemented via ioctl(), but people like
> the simplicity of write(), read(), stat() etc.
>
> So providing eval() *only* shifts the burden of implementation to the
> user. But I agree that perhaps it's a good thing to expose
> FunctionalCache so power users (e.g. Sanne :-)) can use it directly to
> implement functionality not provided by Cache.
+1000, that's precisely the vision I have, but again Functional Cache is not forced
on them.
> Being able to switch to Java 8 doesn't imply we have to use all of its
> new features.
Totally.
>
> Let me address your proposal step by step.
>
>
>
> "What's wrong with the Infinispan Cache API?"
> --------------------------------------
> - Nothing !
> - I can't follow your argument as to why Cache is bad. This is the
> premise to your proposal and it needs to be very clear !
> - JSR 107 came up with a similar API. So if we have to change Cache,
> then I'd +1 a change to JSR 107 as main API
> - I don't see why it's difficult to add new operations: distributed
> queues should be a separate API anyway, and not extend Cache ! We should
> use CacheManager to get a new DistributedQueue, as we do to get a new
> Cache...
^ Right, I think all this section needs to be rewritten to avoid confusion.
>
>
> "How does Java 8 improve on this?"
> ------------------------------
> - Passing serialized lambdas around sounds awfully familiar: it's the
> old 'agent-based programming' paradigm fashionable before the turn of
> the millenium. Instead of invoking RPCs which carry data on P, code
> (also carrying data) is shipped to P and executed there and the result
> sent back to the invoker. (Disclaimer: I wrote such a system myself with
> GOMScript... :-().
> I'm not saying this is bad, but we have to make sure that
> (a) Infinispan benefits from this either in code reduction /
> maintainability / code simplification
> (b) performance doesn't decrease
^ +1, performance at least for the most critical operations, e.g. put/get, needs to be at
least on par.
>
>
>
> "Proposal"
> ---------
> - Returning a CompletableFuture is a good idea: +1
> - I think this is where the main value of your proposal lies: being able
> to chain functions (lambdas) together, that are invoked turn-by-turn,
> possibly by different threads, without a caller having to block
> - The F.invoke(G).andThenInvoke(H).andThenInvoke(I) pattern (where F is
> a future and G,H,I are lambdas) is very valuable to implement
> non-blocking behavior: whenever a function (lambda) has to block, it
> registers a function with the blocking resource that's called upon
> unblocking and the thread terminates and is added back to the thread pool
> - Blocking can be waiting to read from the file system or network, or
> trying to acquire a lock etc
> - As was discussed in Berlin, the interceptor chain could be rewritten
> using CompletableFutures (or sth similar).
^ Yeah, there's a lot of value to be added in this area.
I was very pleased to hear about the CompletableFuture based interceptor chain discussion
because I thought it'd fit perfectly with the direction of the functional cache API.
>
>
> Summary
> --------
>
> I'd not make FunctionalCache the main API and I'd definitely not
> deprecate Cache.
Ok, maybe we won't deprecate Infinispan Cache but we'll definitely won't add
anything extra there. It's way too ovebloated IMO.
>
> +1 on providing FunctionalCache as a (parent) interface to Cache, so
> power users can use FunctionalCache if needed.
>
> +1 on implementing Cache and JSR 107 Cache with FunctionalCache.
>
> This should only be done if:
> - Performance remains at least as good as it is now [mandatory]
> - Maintainability increases [nice]
> - Code reduction [nice]
>
> My 5 cents
+1 to all those.
Thanks Bela for the feedback!
>
>
> On 13/03/15 09:10, 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(a)redhat.com
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
3331
days inactive
3341
days old
infinispan-dev@lists.jboss.org
6 comments
3 participants
participants (3)
-
Bela Ban -
Galder Zamarreño -
Radim Vansa