Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
2014-05-27 21:13 GMT+02:00 Thomas Vandahl t...@apache.org: On 26.05.14 22:05, Romain Manni-Bucau wrote: the point is putIfAbsent is costly but globally once (can be done concurrently but this is ignorable at runtime). Only important thing is to ensure then the system uses a single instance. Right, but what if the instance creates a file, socket or similar? If we want to do this we need to postpone all costly initialization into an initialize() method. In any case, I think this could simplified a lot by removing all separate managers. well in this case locking should be where it is needed (around socket init for instance). Idea I got was to say avoid to force something you don't want. Said otherwise don't put constraints before really needing it. Then JCS is extensible so the question is where should be constraints? Can't really be in the API IMHO since then impl can maybe be too constrainted. The other point shocking me a bit is you need everything needs to be processed sequentially. For a cache you globally want the last value. So then you slow down the process cause you were not preempted. I'm open to suggestions on how to solve this. Feel free to experiment with JCSConcurrentCacheAccessUnitTest to see the effects. A put *must* be finished before the cached object can be accessed. Hmm, I'm not 100% convinced of it actually. Sequentially that's true but with multiple threads if that's not true that's not a big deal. Thanks for the pointer on JCSConcurrentCacheAccessUnitTest, I'll check it. I globally get the idea and we could use a LockFactory + ReentrantLock to replace synchronized (would already be faster), this way we could even get a NoLockFactory ;). I like the idea. It's certainly worth a try. My tests with locks did not show much improvement, though. Ok I take this task. What I saw from my experiments was that with 10 threads locks were better than synchronized but maybe JCS has something making it wrong. I'll check it! Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
Found an IBM article showing globally what I experimented: http://www.ibm.com/developerworks/java/library/j-jtp10264/ So I'll first add ReentrantLock where synchronized was used, then bench it again and see depending performances if we need the LockFactory abstraction or not. Does it work for you? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-28 13:52 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: 2014-05-27 21:13 GMT+02:00 Thomas Vandahl t...@apache.org: On 26.05.14 22:05, Romain Manni-Bucau wrote: the point is putIfAbsent is costly but globally once (can be done concurrently but this is ignorable at runtime). Only important thing is to ensure then the system uses a single instance. Right, but what if the instance creates a file, socket or similar? If we want to do this we need to postpone all costly initialization into an initialize() method. In any case, I think this could simplified a lot by removing all separate managers. well in this case locking should be where it is needed (around socket init for instance). Idea I got was to say avoid to force something you don't want. Said otherwise don't put constraints before really needing it. Then JCS is extensible so the question is where should be constraints? Can't really be in the API IMHO since then impl can maybe be too constrainted. The other point shocking me a bit is you need everything needs to be processed sequentially. For a cache you globally want the last value. So then you slow down the process cause you were not preempted. I'm open to suggestions on how to solve this. Feel free to experiment with JCSConcurrentCacheAccessUnitTest to see the effects. A put *must* be finished before the cached object can be accessed. Hmm, I'm not 100% convinced of it actually. Sequentially that's true but with multiple threads if that's not true that's not a big deal. Thanks for the pointer on JCSConcurrentCacheAccessUnitTest, I'll check it. I globally get the idea and we could use a LockFactory + ReentrantLock to replace synchronized (would already be faster), this way we could even get a NoLockFactory ;). I like the idea. It's certainly worth a try. My tests with locks did not show much improvement, though. Ok I take this task. What I saw from my experiments was that with 10 threads locks were better than synchronized but maybe JCS has something making it wrong. I'll check it! Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
On 26.05.14 22:05, Romain Manni-Bucau wrote: the point is putIfAbsent is costly but globally once (can be done concurrently but this is ignorable at runtime). Only important thing is to ensure then the system uses a single instance. Right, but what if the instance creates a file, socket or similar? If we want to do this we need to postpone all costly initialization into an initialize() method. In any case, I think this could simplified a lot by removing all separate managers. The other point shocking me a bit is you need everything needs to be processed sequentially. For a cache you globally want the last value. So then you slow down the process cause you were not preempted. I'm open to suggestions on how to solve this. Feel free to experiment with JCSConcurrentCacheAccessUnitTest to see the effects. A put *must* be finished before the cached object can be accessed. I globally get the idea and we could use a LockFactory + ReentrantLock to replace synchronized (would already be faster), this way we could even get a NoLockFactory ;). I like the idea. It's certainly worth a try. My tests with locks did not show much improvement, though. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
On 25.05.14 17:18, Romain Manni-Bucau wrote: Extras is a set of useful basic classes for JCache usage. OpenJPA is JCache support for L2 cache in openjpa. The goal is to make what we propose with jcache module as usable as possible and avoid glue code as much as possible in application code. From what I see, caching is something very generic and there is a plethora of strategies that you can use to cache you data. JCS for example is the caching layer for DB-Torque where auxiliaries like JDBCDiskCache would not make sense. Nevertheless they may be used in a different environment, e. g. when the calculation of the data to be cached takes a lot of time. Caching on the level of a request filter only works for simple web applications. Mostly, the lifetimes of page fragments are very different so that caching the complete request is not an option. I'm not sure that such application examples or templates should be in the scope of a project like this. I'm not aware of modules with this focus in other projects of Commons, but I may be wrong. What do others think? I was not that happy to do so but it made default usage really easier and opened several possibilities (L2 cache wouldn't have been seriousy possible otherwise since often entities are not serializable for instance). Well, now, then how to handle the case in the current code when a disk cache needs the value to be serializable and it isn't? Throw an exception? Log something? What if fields of objects are not serializable? With the declared interface, FindBugs helps me to track down those problems. Without the declaration, you may find the problem only when you are in production. I hope I can get my concerns across. I like code that helps the developer avoiding errors, that's the whole point of this discussion. We can create a branch from trunk (to keep code) and go back to a revision which is ok for you if you want to discuss commits. Isn't this what Community over Code is supposed to mean? Peer review, learn from each other, discuss the better concept? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
On 25.05.14 17:45, Phil Steitz wrote:
On 5/25/14, 8:18 AM, Romain Manni-Bucau wrote:
And please consider reacting to Phils comment on the removal of
synchronized keywords. It took years to pinpoint the race issues in the
JCS code. I don't claim the current situation to be perfect but at least
it does not cause data corruption. I want to go forward, not backward.
On this topic, one thing that would probably be helpful would be if
someone familiar with the code could comment a little or post
references to past bugs that show what race conditions / data
invariants we have to worry about. If there is a locking strategy
implicit in the pre-CHM code, it would be great to make that
explicit so Romain can know what he has to worry about beyond just
maintaining integrity of the backing store (which CHM can do).
JCS implements a composite cache, that is, a cache with a memory cache
with different eviction algorithms (you may call it level one) and zero
or more auxiliaries that handle the second level of caching: disks,
databases, distributed caches etc.
We have two issues with synchronization here. One is more or less some
kind of a transaction issue that means that data operations on the *same
cache key* should be performed in sequence and completed through the
chain of auxiliaries. That's why CompositeCache is synchronized. See
JCS-73. I tried several approaches to get rid of this synchronization
but everything I came up with was slower than the synced code.
The other issue is the handling of common data structures within the
cache implementations. For example putting a value into the LRU memory
cache requires not only putting it into the map but updating the linked
list that keeps track on the LRU element. So having a CHM doesn't help
much here.
The same is true for most of the auxiliaries where several data
structures have to be kept consistent. The only exception are the two
disk caches where I managed to get the synchronization out of the code
with the help of NIO. See JCS-69, JCS-76, JCS-82, JCS-92 to name just a few.
In addition, JCS employs several background threads to queue operations
and to do eviction. If you want to see the effect of unsynchronized
access, have a look at the cache statistics. In continuous operation,
the numbers are plain nonsense.
That said: Quite a few of Romains replacements with CHM are maps that
keep track of certain auxiliary caches of the same type within their
managers. They employ the simple pattern
cache = map.get(cacheName);
if (cache == null)
{
// create cache instance, open databases, start servers, create files
etc etc.
}
So if you want to avoid to run these expensive operations, you don't
want to create a cache instance on spec just for putIfAbsent() and you
need synchronization again. That is at least my level of knowledge.
(I don't like this construct of multiple managers and factories, I
consider it over-engineered but it is not high on my list)
Hope I could shed some light on this.
Bye, Thomas.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
the point is putIfAbsent is costly but globally once (can be done
concurrently but this is ignorable at runtime). Only important thing is to
ensure then the system uses a single instance.
Issue with sychronized is that it doesn't scale. If you go upper to 10
threads you are slow.
The other point shocking me a bit is you need everything needs to be
processed sequentially. For a cache you globally want the last value. So
then you slow down the process cause you were not preempted.
I globally get the idea and we could use a LockFactory + ReentrantLock to
replace synchronized (would already be faster), this way we could even get
a NoLockFactory ;).
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-26 21:33 GMT+02:00 Thomas Vandahl t...@apache.org:
On 25.05.14 17:45, Phil Steitz wrote:
On 5/25/14, 8:18 AM, Romain Manni-Bucau wrote:
And please consider reacting to Phils comment on the removal of
synchronized keywords. It took years to pinpoint the race issues in the
JCS code. I don't claim the current situation to be perfect but at
least
it does not cause data corruption. I want to go forward, not backward.
On this topic, one thing that would probably be helpful would be if
someone familiar with the code could comment a little or post
references to past bugs that show what race conditions / data
invariants we have to worry about. If there is a locking strategy
implicit in the pre-CHM code, it would be great to make that
explicit so Romain can know what he has to worry about beyond just
maintaining integrity of the backing store (which CHM can do).
JCS implements a composite cache, that is, a cache with a memory cache
with different eviction algorithms (you may call it level one) and zero
or more auxiliaries that handle the second level of caching: disks,
databases, distributed caches etc.
We have two issues with synchronization here. One is more or less some
kind of a transaction issue that means that data operations on the *same
cache key* should be performed in sequence and completed through the
chain of auxiliaries. That's why CompositeCache is synchronized. See
JCS-73. I tried several approaches to get rid of this synchronization
but everything I came up with was slower than the synced code.
The other issue is the handling of common data structures within the
cache implementations. For example putting a value into the LRU memory
cache requires not only putting it into the map but updating the linked
list that keeps track on the LRU element. So having a CHM doesn't help
much here.
The same is true for most of the auxiliaries where several data
structures have to be kept consistent. The only exception are the two
disk caches where I managed to get the synchronization out of the code
with the help of NIO. See JCS-69, JCS-76, JCS-82, JCS-92 to name just a
few.
In addition, JCS employs several background threads to queue operations
and to do eviction. If you want to see the effect of unsynchronized
access, have a look at the cache statistics. In continuous operation,
the numbers are plain nonsense.
That said: Quite a few of Romains replacements with CHM are maps that
keep track of certain auxiliary caches of the same type within their
managers. They employ the simple pattern
cache = map.get(cacheName);
if (cache == null)
{
// create cache instance, open databases, start servers, create files
etc etc.
}
So if you want to avoid to run these expensive operations, you don't
want to create a cache instance on spec just for putIfAbsent() and you
need synchronization again. That is at least my level of knowledge.
(I don't like this construct of multiple managers and factories, I
consider it over-engineered but it is not high on my list)
Hope I could shed some light on this.
Bye, Thomas.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
Am 24.05.2014 um 19:42 schrieb Phil Steitz phil.ste...@gmail.com: I don't know anything really about [jcs], but what I think those who are interested in working on this thing need to do is come to consensus on what a new modular structure will look like, what changes make sense, what already exists vs needs to be implemented and how the changes already made are safe and effective (I got no response to a question that I asked about one of a slew of commits ripping out a lot of sync because it was not needed due to using CHM). Bottom line is you need to stop thinking about being blocked and start thinking about showing that you really understand the code and have clear ideas about where to go with it. Then you will find that you are not just unblocked but you have others willing to help move things along. Thanks, Phil, for your comments. I have been thinking at times, I was completely unreasonable. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
Hi Romain, On 24.05.14 20:16, Romain Manni-Bucau wrote: basically I respected all remarks, only pendings ones are: 1) modules Ok, right now, I see the following modules - commons-jcs-core - commons-jcs-jcache - commons-jcs-jcache-extras - commons-jcs-jcache-openjpa - commons-jcs-tck-tests I don't know anything about extras and openjpa. What is the purpose of these modules? Do you plan to introduce others? 2) I removed Serializable from *API* of auxilary caches since it prevent a lot of things like using it only in memory on not serializable objects for instance. The constraint is still on the impl which need it but not more in the API I understand your comment about different types of serializers (json, xml and such). On the other hand, I prefer type checks at compile time. The mixture that exists now creates more problems than it solves. My suggestion would be to remove the Serializable constraint altogether, but then what? The explicit declaration makes sure that no non-serializable objects can be put into the cache, so all levels below the surface can rely on this behavior. If I don't have this restriction, error handling must be done on the serializer level and exceptions bubbled up to the API. Would that make sense? In any case the modifications of the API must be documented, both in src/changes/changes.xml and the files below xdocs. 3) I removed Seconds suffix in configuration since for JCache we need it to be millisecond. Default is still in second (without the suffix) but we need this update otherwise we can't pass JCache tests I know that the usage of seconds vs. milliseconds is not intuitive within JCS. Please make sure that your changes improve this situation and not make it worse. This change has a big impact on existing users so please update the documentation! @Thomas: anything I forgotten, thinks that's all now? Please document all the changes you've done in src/changes/changes.xml I tried to catch up with some important features but lost track. And please consider reacting to Phils comment on the removal of synchronized keywords. It took years to pinpoint the race issues in the JCS code. I don't claim the current situation to be perfect but at least it does not cause data corruption. I want to go forward, not backward. I want to get some momentum to the project as I am currently very time constrained. That's why I wanted to invite you to the Commons community. I hope we can get to some consensus by discussing important changes *before* committing them - even if it takes a few days. I will do my best to comment, review and contribute and I would expect from you to do the same. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
Responses inline. 2014-05-25 15:03 GMT+02:00 Thomas Vandahl t...@apache.org: Hi Romain, On 24.05.14 20:16, Romain Manni-Bucau wrote: basically I respected all remarks, only pendings ones are: 1) modules Ok, right now, I see the following modules - commons-jcs-core - commons-jcs-jcache - commons-jcs-jcache-extras - commons-jcs-jcache-openjpa - commons-jcs-tck-tests I don't know anything about extras and openjpa. What is the purpose of these modules? Do you plan to introduce others? Extras is a set of useful basic classes for JCache usage. OpenJPA is JCache support for L2 cache in openjpa. The goal is to make what we propose with jcache module as usable as possible and avoid glue code as much as possible in application code. 2) I removed Serializable from *API* of auxilary caches since it prevent a lot of things like using it only in memory on not serializable objects for instance. The constraint is still on the impl which need it but not more in the API I understand your comment about different types of serializers (json, xml and such). On the other hand, I prefer type checks at compile time. The mixture that exists now creates more problems than it solves. My suggestion would be to remove the Serializable constraint altogether, but then what? The explicit declaration makes sure that no non-serializable objects can be put into the cache, so all levels below the surface can rely on this behavior. If I don't have this restriction, error handling must be done on the serializer level and exceptions bubbled up to the API. Would that make sense? In any case the modifications of the API must be documented, both in src/changes/changes.xml and the files below xdocs. I was not that happy to do so but it made default usage really easier and opened several possibilities (L2 cache wouldn't have been seriousy possible otherwise since often entities are not serializable for instance). Ok about changes.xml, didnt see it was used, Should be updated. 3) I removed Seconds suffix in configuration since for JCache we need it to be millisecond. Default is still in second (without the suffix) but we need this update otherwise we can't pass JCache tests I know that the usage of seconds vs. milliseconds is not intuitive within JCS. Please make sure that your changes improve this situation and not make it worse. This change has a big impact on existing users so please update the documentation! Should be done. I just removed Seconds prefix since user shouldn't see something else than seconds by default. We can keep TimeFactorForMilliseconds an internal configuration for now IMHO. @Thomas: anything I forgotten, thinks that's all now? Please document all the changes you've done in src/changes/changes.xml I tried to catch up with some important features but lost track. And please consider reacting to Phils comment on the removal of synchronized keywords. It took years to pinpoint the race issues in the JCS code. I don't claim the current situation to be perfect but at least it does not cause data corruption. I want to go forward, not backward. I want to get some momentum to the project as I am currently very time constrained. That's why I wanted to invite you to the Commons community. I hope we can get to some consensus by discussing important changes *before* committing them - even if it takes a few days. I will do my best to comment, review and contribute and I would expect from you to do the same. We can create a branch from trunk (to keep code) and go back to a revision which is ok for you if you want to discuss commits. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
On 5/25/14, 8:18 AM, Romain Manni-Bucau wrote: Responses inline. 2014-05-25 15:03 GMT+02:00 Thomas Vandahl t...@apache.org: Hi Romain, On 24.05.14 20:16, Romain Manni-Bucau wrote: basically I respected all remarks, only pendings ones are: 1) modules Ok, right now, I see the following modules - commons-jcs-core - commons-jcs-jcache - commons-jcs-jcache-extras - commons-jcs-jcache-openjpa - commons-jcs-tck-tests I don't know anything about extras and openjpa. What is the purpose of these modules? Do you plan to introduce others? Extras is a set of useful basic classes for JCache usage. OpenJPA is JCache support for L2 cache in openjpa. The goal is to make what we propose with jcache module as usable as possible and avoid glue code as much as possible in application code. 2) I removed Serializable from *API* of auxilary caches since it prevent a lot of things like using it only in memory on not serializable objects for instance. The constraint is still on the impl which need it but not more in the API I understand your comment about different types of serializers (json, xml and such). On the other hand, I prefer type checks at compile time. The mixture that exists now creates more problems than it solves. My suggestion would be to remove the Serializable constraint altogether, but then what? The explicit declaration makes sure that no non-serializable objects can be put into the cache, so all levels below the surface can rely on this behavior. If I don't have this restriction, error handling must be done on the serializer level and exceptions bubbled up to the API. Would that make sense? In any case the modifications of the API must be documented, both in src/changes/changes.xml and the files below xdocs. I was not that happy to do so but it made default usage really easier and opened several possibilities (L2 cache wouldn't have been seriousy possible otherwise since often entities are not serializable for instance). Ok about changes.xml, didnt see it was used, Should be updated. 3) I removed Seconds suffix in configuration since for JCache we need it to be millisecond. Default is still in second (without the suffix) but we need this update otherwise we can't pass JCache tests I know that the usage of seconds vs. milliseconds is not intuitive within JCS. Please make sure that your changes improve this situation and not make it worse. This change has a big impact on existing users so please update the documentation! Should be done. I just removed Seconds prefix since user shouldn't see something else than seconds by default. We can keep TimeFactorForMilliseconds an internal configuration for now IMHO. @Thomas: anything I forgotten, thinks that's all now? Please document all the changes you've done in src/changes/changes.xml I tried to catch up with some important features but lost track. And please consider reacting to Phils comment on the removal of synchronized keywords. It took years to pinpoint the race issues in the JCS code. I don't claim the current situation to be perfect but at least it does not cause data corruption. I want to go forward, not backward. On this topic, one thing that would probably be helpful would be if someone familiar with the code could comment a little or post references to past bugs that show what race conditions / data invariants we have to worry about. If there is a locking strategy implicit in the pre-CHM code, it would be great to make that explicit so Romain can know what he has to worry about beyond just maintaining integrity of the backing store (which CHM can do). I want to get some momentum to the project as I am currently very time constrained. That's why I wanted to invite you to the Commons community. I hope we can get to some consensus by discussing important changes *before* committing them - even if it takes a few days. I will do my best to comment, review and contribute and I would expect from you to do the same. We can create a branch from trunk (to keep code) and go back to a revision which is ok for you if you want to discuss commits. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
On 5/22/14, 11:40 PM, Romain Manni-Bucau wrote: Well was commons-jcs more than commons since [proxy] for instance is already very modular. ? - sorry I can't make any sense out of that comment. Maybe you are saying we can modularize? Sounds like a good idea. Ok so we should decide something. I think there is nothing blocking. I mean we can discuss the points you see as important and try to fix them. Taking the (simple) example of the formatting we can add checksyle/pmd/... to ensure all commits respect the correct style. If you think we can't I can propose an incubator project dedicated to JCache (would be sad honestly to not benefit from some JCS features and to get 2 different alternatives @Apache). Please let me know to let us not be blocked like it. I don't know anything really about [jcs], but what I think those who are interested in working on this thing need to do is come to consensus on what a new modular structure will look like, what changes make sense, what already exists vs needs to be implemented and how the changes already made are safe and effective (I got no response to a question that I asked about one of a slew of commits ripping out a lot of sync because it was not needed due to using CHM). Bottom line is you need to stop thinking about being blocked and start thinking about showing that you really understand the code and have clear ideas about where to go with it. Then you will find that you are not just unblocked but you have others willing to help move things along. Phil Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 23:32 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote: well Now JCache is based on JCS so think almost all comments are no more relevant. Well if commons can't support module (jcs wouldn't be the first BTW) I have no issue moving it outside of commons. This is quite common actually. This bothers me - and not for the reason that you may think. To jump from another committer asking questions to commons can't support module is bogus. Phil The point about remote mode is it is not as easy as alternatives and API doesn't completely fit needs of JCache, but this is not a big deal now, we have something enough for now. Yes I got some formatting issues, saw a lot of classes didn't have organized imports but miss my settings regarding java.* was maybe not correct. We can fix it in all cases. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 21:37 GMT+02:00 Thomas Vandahl t...@apache.org: On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. You wrote: ---8--- 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. ---8--- JCS *has* eviction and it *can* work in a distributed environment. Many people use this. JCache uses JCS so once again not sure I follow. See 3) above. Finally extra module is quite useful when you use JCache and that's what we do in all EE projects cause this module doesn't depend on the implementation. Yes, but we are at Commons here. I miss the willingness to discuss project matters before reorganizing a project that you barely know. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail:
Re: [VETO] Re: [jcs] What's next?
Hi 2014-05-24 19:42 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 11:40 PM, Romain Manni-Bucau wrote: Well was commons-jcs more than commons since [proxy] for instance is already very modular. ? - sorry I can't make any sense out of that comment. Maybe you are saying we can modularize? Sounds like a good idea. was to fix my previous sentence where I used 'commons' instead of 'commons-jcs'. But not that important Ok so we should decide something. I think there is nothing blocking. I mean we can discuss the points you see as important and try to fix them. Taking the (simple) example of the formatting we can add checksyle/pmd/... to ensure all commits respect the correct style. If you think we can't I can propose an incubator project dedicated to JCache (would be sad honestly to not benefit from some JCS features and to get 2 different alternatives @Apache). Please let me know to let us not be blocked like it. I don't know anything really about [jcs], but what I think those who are interested in working on this thing need to do is come to consensus on what a new modular structure will look like, what changes make sense, what already exists vs needs to be implemented and how the changes already made are safe and effective (I got no response to a question that I asked about one of a slew of commits ripping out a lot of sync because it was not needed due to using CHM). Bottom line is you need to stop thinking about being blocked and start thinking about showing that you really understand the code and have clear ideas about where to go with it. Then you will find that you are not just unblocked but you have others willing to help move things along. Globally agree. About modular since I was not alone doing it I thought it was ok. Main reason I said we were blocked is the fact each time something needs to be fixed mail are don't do it, instead of we should go this way with specific pointers and with an important delay for dev phase. If Thomas only checks his mails once a week it can explain it BTW. Phil Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 23:32 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote: well Now JCache is based on JCS so think almost all comments are no more relevant. Well if commons can't support module (jcs wouldn't be the first BTW) I have no issue moving it outside of commons. This is quite common actually. This bothers me - and not for the reason that you may think. To jump from another committer asking questions to commons can't support module is bogus. Phil The point about remote mode is it is not as easy as alternatives and API doesn't completely fit needs of JCache, but this is not a big deal now, we have something enough for now. Yes I got some formatting issues, saw a lot of classes didn't have organized imports but miss my settings regarding java.* was maybe not correct. We can fix it in all cases. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 21:37 GMT+02:00 Thomas Vandahl t...@apache.org: On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. You wrote: ---8--- 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. ---8--- JCS *has* eviction and it *can* work in a distributed environment. Many people use this. JCache uses JCS so once again not sure I follow. See 3) above. Finally extra module is
Re: [VETO] Re: [jcs] What's next?
On 5/24/14, 10:46 AM, Romain Manni-Bucau wrote: Hi 2014-05-24 19:42 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 11:40 PM, Romain Manni-Bucau wrote: Well was commons-jcs more than commons since [proxy] for instance is already very modular. ? - sorry I can't make any sense out of that comment. Maybe you are saying we can modularize? Sounds like a good idea. was to fix my previous sentence where I used 'commons' instead of 'commons-jcs'. But not that important Ok so we should decide something. I think there is nothing blocking. I mean we can discuss the points you see as important and try to fix them. Taking the (simple) example of the formatting we can add checksyle/pmd/... to ensure all commits respect the correct style. If you think we can't I can propose an incubator project dedicated to JCache (would be sad honestly to not benefit from some JCS features and to get 2 different alternatives @Apache). Please let me know to let us not be blocked like it. I don't know anything really about [jcs], but what I think those who are interested in working on this thing need to do is come to consensus on what a new modular structure will look like, what changes make sense, what already exists vs needs to be implemented and how the changes already made are safe and effective (I got no response to a question that I asked about one of a slew of commits ripping out a lot of sync because it was not needed due to using CHM). Bottom line is you need to stop thinking about being blocked and start thinking about showing that you really understand the code and have clear ideas about where to go with it. Then you will find that you are not just unblocked but you have others willing to help move things along. Globally agree. About modular since I was not alone doing it I thought it was ok. Main reason I said we were blocked is the fact each time something needs to be fixed mail are don't do it, instead of we should go this way with specific pointers and with an important delay for dev phase. If Thomas only checks his mails once a week it can explain it BTW. I would suggest that you try once more to summarize what you are trying to do, responding to Thomas' objections, maybe suggest some compromises, move forward with stuff all can agree on and keep working on consensus for the other stuff. Phil Phil Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 23:32 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote: well Now JCache is based on JCS so think almost all comments are no more relevant. Well if commons can't support module (jcs wouldn't be the first BTW) I have no issue moving it outside of commons. This is quite common actually. This bothers me - and not for the reason that you may think. To jump from another committer asking questions to commons can't support module is bogus. Phil The point about remote mode is it is not as easy as alternatives and API doesn't completely fit needs of JCache, but this is not a big deal now, we have something enough for now. Yes I got some formatting issues, saw a lot of classes didn't have organized imports but miss my settings regarding java.* was maybe not correct. We can fix it in all cases. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 21:37 GMT+02:00 Thomas Vandahl t...@apache.org: On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. You wrote: ---8--- 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another
Re: [VETO] Re: [jcs] What's next?
basically I respected all remarks, only pendings ones are: 1) modules 2) I removed Serializable from *API* of auxilary caches since it prevent a lot of things like using it only in memory on not serializable objects for instance. The constraint is still on the impl which need it but not more in the API 3) I removed Seconds suffix in configuration since for JCache we need it to be millisecond. Default is still in second (without the suffix) but we need this update otherwise we can't pass JCache tests @Thomas: anything I forgotten, thinks that's all now? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-24 20:09 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/24/14, 10:46 AM, Romain Manni-Bucau wrote: Hi 2014-05-24 19:42 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 11:40 PM, Romain Manni-Bucau wrote: Well was commons-jcs more than commons since [proxy] for instance is already very modular. ? - sorry I can't make any sense out of that comment. Maybe you are saying we can modularize? Sounds like a good idea. was to fix my previous sentence where I used 'commons' instead of 'commons-jcs'. But not that important Ok so we should decide something. I think there is nothing blocking. I mean we can discuss the points you see as important and try to fix them. Taking the (simple) example of the formatting we can add checksyle/pmd/... to ensure all commits respect the correct style. If you think we can't I can propose an incubator project dedicated to JCache (would be sad honestly to not benefit from some JCS features and to get 2 different alternatives @Apache). Please let me know to let us not be blocked like it. I don't know anything really about [jcs], but what I think those who are interested in working on this thing need to do is come to consensus on what a new modular structure will look like, what changes make sense, what already exists vs needs to be implemented and how the changes already made are safe and effective (I got no response to a question that I asked about one of a slew of commits ripping out a lot of sync because it was not needed due to using CHM). Bottom line is you need to stop thinking about being blocked and start thinking about showing that you really understand the code and have clear ideas about where to go with it. Then you will find that you are not just unblocked but you have others willing to help move things along. Globally agree. About modular since I was not alone doing it I thought it was ok. Main reason I said we were blocked is the fact each time something needs to be fixed mail are don't do it, instead of we should go this way with specific pointers and with an important delay for dev phase. If Thomas only checks his mails once a week it can explain it BTW. I would suggest that you try once more to summarize what you are trying to do, responding to Thomas' objections, maybe suggest some compromises, move forward with stuff all can agree on and keep working on consensus for the other stuff. Phil Phil Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 23:32 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote: well Now JCache is based on JCS so think almost all comments are no more relevant. Well if commons can't support module (jcs wouldn't be the first BTW) I have no issue moving it outside of commons. This is quite common actually. This bothers me - and not for the reason that you may think. To jump from another committer asking questions to commons can't support module is bogus. Phil The point about remote mode is it is not as easy as alternatives and API doesn't completely fit needs of JCache, but this is not a big deal now, we have something enough for now. Yes I got some formatting issues, saw a lot of classes didn't have organized imports but miss my settings regarding java.* was maybe not correct. We can fix it in all cases. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 21:37 GMT+02:00 Thomas Vandahl t...@apache.org: On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we
Re: [VETO] Re: [jcs] What's next?
Well was commons-jcs more than commons since [proxy] for instance is already very modular. Ok so we should decide something. I think there is nothing blocking. I mean we can discuss the points you see as important and try to fix them. Taking the (simple) example of the formatting we can add checksyle/pmd/... to ensure all commits respect the correct style. If you think we can't I can propose an incubator project dedicated to JCache (would be sad honestly to not benefit from some JCS features and to get 2 different alternatives @Apache). Please let me know to let us not be blocked like it. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 23:32 GMT+02:00 Phil Steitz phil.ste...@gmail.com: On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote: well Now JCache is based on JCS so think almost all comments are no more relevant. Well if commons can't support module (jcs wouldn't be the first BTW) I have no issue moving it outside of commons. This is quite common actually. This bothers me - and not for the reason that you may think. To jump from another committer asking questions to commons can't support module is bogus. Phil The point about remote mode is it is not as easy as alternatives and API doesn't completely fit needs of JCache, but this is not a big deal now, we have something enough for now. Yes I got some formatting issues, saw a lot of classes didn't have organized imports but miss my settings regarding java.* was maybe not correct. We can fix it in all cases. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 21:37 GMT+02:00 Thomas Vandahl t...@apache.org: On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. You wrote: ---8--- 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. ---8--- JCS *has* eviction and it *can* work in a distributed environment. Many people use this. JCache uses JCS so once again not sure I follow. See 3) above. Finally extra module is quite useful when you use JCache and that's what we do in all EE projects cause this module doesn't depend on the implementation. Yes, but we are at Commons here. I miss the willingness to discuss project matters before reorganizing a project that you barely know. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
Hi Romain, sorry, I only find time to look at my mail once a week. On 16.05.14 23:40, Romain Manni-Bucau wrote: Hi Thomas, is it an old mail or not? It is not. If not can you detail the changes you dislike please? - Removing Serializable from the key and value types. This is required for almost all auxiliaries to work. - Implementing eviction methods that already exist. - Planning to remove network functionality from JCS. - Planning to remove RemoteCache. - Adding extras modules that have nothing to do with caching - Removing JCS from the JCache extension completely. Anything I forgot? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
About serializable: that's fine but doesn't have to be forced in the API since auxilaries can not mandate it. Another point is cache elements have a serializer and if you set it you don't want to use java serialization (json typically) so if it is still mandatory we should get rid of it IMHO. About eviction: is it still the case? Thought I removed it when merged with jcs backend Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. JCache uses JCS so once again not sure I follow. Finally extra module is quite useful when you use JCache and that's what we do in all EE projects cause this module doesn't depend on the implementation. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 19:18 GMT+02:00 Thomas Vandahl t...@apache.org: Hi Romain, sorry, I only find time to look at my mail once a week. On 16.05.14 23:40, Romain Manni-Bucau wrote: Hi Thomas, is it an old mail or not? It is not. If not can you detail the changes you dislike please? - Removing Serializable from the key and value types. This is required for almost all auxiliaries to work. - Implementing eviction methods that already exist. - Planning to remove network functionality from JCS. - Planning to remove RemoteCache. - Adding extras modules that have nothing to do with caching - Removing JCS from the JCache extension completely. Anything I forgot? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. You wrote: ---8--- 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. ---8--- JCS *has* eviction and it *can* work in a distributed environment. Many people use this. JCache uses JCS so once again not sure I follow. See 3) above. Finally extra module is quite useful when you use JCache and that's what we do in all EE projects cause this module doesn't depend on the implementation. Yes, but we are at Commons here. I miss the willingness to discuss project matters before reorganizing a project that you barely know. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
well Now JCache is based on JCS so think almost all comments are no more relevant. Well if commons can't support module (jcs wouldn't be the first BTW) I have no issue moving it outside of commons. This is quite common actually. The point about remote mode is it is not as easy as alternatives and API doesn't completely fit needs of JCache, but this is not a big deal now, we have something enough for now. Yes I got some formatting issues, saw a lot of classes didn't have organized imports but miss my settings regarding java.* was maybe not correct. We can fix it in all cases. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 21:37 GMT+02:00 Thomas Vandahl t...@apache.org: On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. You wrote: ---8--- 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. ---8--- JCS *has* eviction and it *can* work in a distributed environment. Many people use this. JCache uses JCS so once again not sure I follow. See 3) above. Finally extra module is quite useful when you use JCache and that's what we do in all EE projects cause this module doesn't depend on the implementation. Yes, but we are at Commons here. I miss the willingness to discuss project matters before reorganizing a project that you barely know. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote: well Now JCache is based on JCS so think almost all comments are no more relevant. Well if commons can't support module (jcs wouldn't be the first BTW) I have no issue moving it outside of commons. This is quite common actually. This bothers me - and not for the reason that you may think. To jump from another committer asking questions to commons can't support module is bogus. Phil The point about remote mode is it is not as easy as alternatives and API doesn't completely fit needs of JCache, but this is not a big deal now, we have something enough for now. Yes I got some formatting issues, saw a lot of classes didn't have organized imports but miss my settings regarding java.* was maybe not correct. We can fix it in all cases. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 21:37 GMT+02:00 Thomas Vandahl t...@apache.org: On 22.05.14 19:24, Romain Manni-Bucau wrote: About eviction: is it still the case? Thought I removed it when merged with jcs backend I have no idea. I lost track when I needed to merge my changes with your reformatted imports (That was one thing I forgot). Why was that necessary? Not sure I get your point about removing network/remote features, never said we should remove it but we shouldn't have it by default for JCache. You wrote: ---8--- 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. ---8--- JCS *has* eviction and it *can* work in a distributed environment. Many people use this. JCache uses JCS so once again not sure I follow. See 3) above. Finally extra module is quite useful when you use JCache and that's what we do in all EE projects cause this module doesn't depend on the implementation. Yes, but we are at Commons here. I miss the willingness to discuss project matters before reorganizing a project that you barely know. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Talking about next steps, have you ever considered a second level of (off
heap) cache? My question is of course not so casual, being the PMC of
DirectMemory :) I think there are a lot of potential synergies, here. I
include DM's dev list to gather opinions and solicitate feedback from the
team members.
Ciao,
R
2014-05-06 22:39 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
That's my experience too. So let's go for the concurrenthashmap impl
(patch on jira) and then see how we do the invalidation stuff in a
2.1?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 19:54 GMT+02:00 Mark Struberg strub...@yahoo.de:
Well my personal experience only:
1.) I barely use distributed caches. I use ehcache in most of my
projects as of today, but do not use the distribution feature much. Way too
complicated
2.) What actually IS useful is distributed cache invalidation. The
caching side is fine to just select any values from my DB if they are not
yet cached. But if I change those values, then I really need some ways to
get rid of the values in all the caches on all my cluster nodes.
So from a purely personal point I would favour a mode which is really
fast as a local cache but would have some ways to distribute the
invalidation of a cache to all other nodes.
Not sure how this fits into jcs - don't know the codebase well enough to
judge about it.
LieGrue,
strub
On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Node { // remote and local API
get(k), put(k, v) (CacheK, V primitive methods)
Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}
EntryRepartitor {
Node[] nodeAndBackups(key)
}
get(key) { // symmetrical for put of course
Node[] nodes = entryRepartitor.nodeAndBackups(key);
for (final Node node : nodes) {
try {
return node.get(key);
} catch(final RemoteCacheException rce) { // API exception
throw rce.getJCacheException();
} catch(final Exception e) { // network exception try next node
// continue
}
}
}
Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.
To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
FYI I attached a patch using a ConcurrentHashMap here
https://issues.apache.org/jira/browse/JCS-127
It is pretty fast compared to previous impl.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
Hi guys,
few questions about jcs:
1) I played a bit with remote cache server etc and didn't find a lot
of use cases, do we keep it this way (linked to 4) )?
2) API: do we use JCache as main API or do we keep core?
3) Reviewing JCache module I really wonder if we shouldn't use a
ConcurrentHashMap instead of a the currently backing CompositeCache
and add on top of this locally optimized implementation two things:
a) eviction (a thread regularly iterating over local items to check
expiry would be enough), b) distribution (see 4) )
4) distributed mode: I wonder if we shouldn't rethink it and
potentially add CacheK, V listeners usable in JCache to know if
another node did something (useful to get consistent stats at least -
basically we need a way to aggregate on each note stats) + use a key
for each node to keep data on a single node + potentially add backup
on another node.
wdyt?
I don't know how much JCS is used ATM and if we can break that much
the API but since that would be a 2.0 I think it is the moment
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
[VETO] Re: [jcs] What's next?
Hello Romain, On 07.05.14 23:30, Romain Manni-Bucau wrote: Any objection (mainly on the fact we don't rely on jcs-core)? Yes, I object. I expressed a number of concerns regarding your approach, your modifications of the main API, the re-implementation of existing features etc. You chose not to care. You don't know my use cases and I don't know yours. But I guess yours are not better than mine nor anyone elses. My idea of collaboration in an Apache project is to find consensus. My impression is that you have a different idea. Once more I'd like to ask you to make yourself familiar with the concepts and features of JCS as a comprehensive distributed cache solution. And then think again. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VETO] Re: [jcs] What's next?
Hi Thomas, is it an old mail or not? If not can you detail the changes you dislike please? Le 16 mai 2014 20:07, Thomas Vandahl t...@apache.org a écrit : Hello Romain, On 07.05.14 23:30, Romain Manni-Bucau wrote: Any objection (mainly on the fact we don't rely on jcs-core)? Yes, I object. I expressed a number of concerns regarding your approach, your modifications of the main API, the re-implementation of existing features etc. You chose not to care. You don't know my use cases and I don't know yours. But I guess yours are not better than mine nor anyone elses. My idea of collaboration in an Apache project is to find consensus. My impression is that you have a different idea. Once more I'd like to ask you to make yourself familiar with the concepts and features of JCS as a comprehensive distributed cache solution. And then think again. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Ok, pushed what I had to push.
Open question: how do we structure the project. Keeping it along
jcs-core seems quite inconsistent. Do we consider jcache impl as a
subproject?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-07 23:30 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
trunk should be in phase with this (ConcurrentHashMap). I'll test it
further tomorrow (hope to find time) but any review would be welcomed.
Main things which can be enhance I guess are the eviction rules
(org.apache.commons.jcs.jcache.JCSCache#evict).
Then I plan to add few utilities in jcache-extra module
(CompositeCacheLoader, CompositeCacheWriter, AsyncCacheLoader,
AsyncCacheWriter, SingleItemCacheLoader, SingleItemCacheWriter,...all
implementing Factory too to make it nicer in the MutableConfiguration
API)
Then JCache should be ok for a release.
Any objection (mainly on the fact we don't rely on jcs-core)?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 22:39 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
That's my experience too. So let's go for the concurrenthashmap impl
(patch on jira) and then see how we do the invalidation stuff in a
2.1?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 19:54 GMT+02:00 Mark Struberg strub...@yahoo.de:
Well my personal experience only:
1.) I barely use distributed caches. I use ehcache in most of my projects
as of today, but do not use the distribution feature much. Way too
complicated
2.) What actually IS useful is distributed cache invalidation. The caching
side is fine to just select any values from my DB if they are not yet
cached. But if I change those values, then I really need some ways to get
rid of the values in all the caches on all my cluster nodes.
So from a purely personal point I would favour a mode which is really fast
as a local cache but would have some ways to distribute the invalidation of
a cache to all other nodes.
Not sure how this fits into jcs - don't know the codebase well enough to
judge about it.
LieGrue,
strub
On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Node { // remote and local API
get(k), put(k, v) (CacheK, V primitive methods)
Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}
EntryRepartitor {
Node[] nodeAndBackups(key)
}
get(key) { // symmetrical for put of course
Node[] nodes = entryRepartitor.nodeAndBackups(key);
for (final Node node : nodes) {
try {
return node.get(key);
} catch(final RemoteCacheException rce) { // API exception
throw rce.getJCacheException();
} catch(final Exception e) { // network exception try next node
// continue
}
}
}
Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.
To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
FYI I attached a patch using a ConcurrentHashMap here
https://issues.apache.org/jira/browse/JCS-127
It is pretty fast compared to previous impl.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
Hi guys,
few questions about jcs:
1) I played a bit with remote cache server etc and didn't find a lot
of use cases, do we keep it this way (linked to 4) )?
2) API: do we use JCache as main API or do we keep core?
3) Reviewing JCache module I really wonder if we shouldn't use a
ConcurrentHashMap instead of a the currently backing CompositeCache
and add on top of this locally optimized implementation two things:
a) eviction (a
Re: [jcs] What's next?
Oops, wrong address, sorry :)
2014-05-07 12:03 GMT+02:00 Raffaele P. Guidi raffaele.p.gu...@gmail.com:
Talking about next steps, have you ever considered a second level of (off
heap) cache? My question is of course not so casual, being the PMC of
DirectMemory :) I think there are a lot of potential synergies, here. I
include DM's dev list to gather opinions and solicitate feedback from the
team members.
Ciao,
R
2014-05-06 22:39 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
That's my experience too. So let's go for the concurrenthashmap impl
(patch on jira) and then see how we do the invalidation stuff in a
2.1?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 19:54 GMT+02:00 Mark Struberg strub...@yahoo.de:
Well my personal experience only:
1.) I barely use distributed caches. I use ehcache in most of my
projects as of today, but do not use the distribution feature much. Way too
complicated
2.) What actually IS useful is distributed cache invalidation. The
caching side is fine to just select any values from my DB if they are not
yet cached. But if I change those values, then I really need some ways to
get rid of the values in all the caches on all my cluster nodes.
So from a purely personal point I would favour a mode which is really
fast as a local cache but would have some ways to distribute the
invalidation of a cache to all other nodes.
Not sure how this fits into jcs - don't know the codebase well enough
to judge about it.
LieGrue,
strub
On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau
rmannibu...@gmail.com wrote:
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Node { // remote and local API
get(k), put(k, v) (CacheK, V primitive methods)
Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}
EntryRepartitor {
Node[] nodeAndBackups(key)
}
get(key) { // symmetrical for put of course
Node[] nodes = entryRepartitor.nodeAndBackups(key);
for (final Node node : nodes) {
try {
return node.get(key);
} catch(final RemoteCacheException rce) { // API exception
throw rce.getJCacheException();
} catch(final Exception e) { // network exception try next node
// continue
}
}
}
Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.
To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
FYI I attached a patch using a ConcurrentHashMap here
https://issues.apache.org/jira/browse/JCS-127
It is pretty fast compared to previous impl.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
Hi guys,
few questions about jcs:
1) I played a bit with remote cache server etc and didn't find a lot
of use cases, do we keep it this way (linked to 4) )?
2) API: do we use JCache as main API or do we keep core?
3) Reviewing JCache module I really wonder if we shouldn't use a
ConcurrentHashMap instead of a the currently backing CompositeCache
and add on top of this locally optimized implementation two things:
a) eviction (a thread regularly iterating over local items to check
expiry would be enough), b) distribution (see 4) )
4) distributed mode: I wonder if we shouldn't rethink it and
potentially add CacheK, V listeners usable in JCache to know if
another node did something (useful to get consistent stats at least -
basically we need a way to aggregate on each note stats) + use a key
for each node to keep data on a single node + potentially add backup
on another node.
wdyt?
I don't know how much JCS is used ATM and if we can break that much
the API but since that would be a 2.0 I think it is the moment
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
Re: [jcs] What's next?
trunk should be in phase with this (ConcurrentHashMap). I'll test it
further tomorrow (hope to find time) but any review would be welcomed.
Main things which can be enhance I guess are the eviction rules
(org.apache.commons.jcs.jcache.JCSCache#evict).
Then I plan to add few utilities in jcache-extra module
(CompositeCacheLoader, CompositeCacheWriter, AsyncCacheLoader,
AsyncCacheWriter, SingleItemCacheLoader, SingleItemCacheWriter,...all
implementing Factory too to make it nicer in the MutableConfiguration
API)
Then JCache should be ok for a release.
Any objection (mainly on the fact we don't rely on jcs-core)?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 22:39 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
That's my experience too. So let's go for the concurrenthashmap impl
(patch on jira) and then see how we do the invalidation stuff in a
2.1?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 19:54 GMT+02:00 Mark Struberg strub...@yahoo.de:
Well my personal experience only:
1.) I barely use distributed caches. I use ehcache in most of my projects as
of today, but do not use the distribution feature much. Way too complicated
2.) What actually IS useful is distributed cache invalidation. The caching
side is fine to just select any values from my DB if they are not yet
cached. But if I change those values, then I really need some ways to get
rid of the values in all the caches on all my cluster nodes.
So from a purely personal point I would favour a mode which is really fast
as a local cache but would have some ways to distribute the invalidation of
a cache to all other nodes.
Not sure how this fits into jcs - don't know the codebase well enough to
judge about it.
LieGrue,
strub
On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Node { // remote and local API
get(k), put(k, v) (CacheK, V primitive methods)
Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}
EntryRepartitor {
Node[] nodeAndBackups(key)
}
get(key) { // symmetrical for put of course
Node[] nodes = entryRepartitor.nodeAndBackups(key);
for (final Node node : nodes) {
try {
return node.get(key);
} catch(final RemoteCacheException rce) { // API exception
throw rce.getJCacheException();
} catch(final Exception e) { // network exception try next node
// continue
}
}
}
Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.
To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
FYI I attached a patch using a ConcurrentHashMap here
https://issues.apache.org/jira/browse/JCS-127
It is pretty fast compared to previous impl.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
Hi guys,
few questions about jcs:
1) I played a bit with remote cache server etc and didn't find a lot
of use cases, do we keep it this way (linked to 4) )?
2) API: do we use JCache as main API or do we keep core?
3) Reviewing JCache module I really wonder if we shouldn't use a
ConcurrentHashMap instead of a the currently backing CompositeCache
and add on top of this locally optimized implementation two things:
a) eviction (a thread regularly iterating over local items to check
expiry would be enough), b) distribution (see 4) )
4) distributed mode: I wonder if we shouldn't rethink it and
potentially add CacheK, V listeners usable in JCache to know if
another node did something (useful to get consistent stats at least -
basically we need a way to aggregate on each note stats) + use a key
for each node to keep data on a single node + potentially add
Re: [jcs] What's next?
On 06.05.14 08:31, Romain Manni-Bucau wrote: Hi guys, few questions about jcs: 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? The features of JCS are quite comprehensive. Not everything is useful for everybody. So besides the test failure that I never could reproduce, why not? 2) API: do we use JCache as main API or do we keep core? The API of a cache is quite simple. To me, it is important that the lifecycle of the main cache manager can be integrated in that of an application container, be it JEE or else. 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) Both features exist. Eviction is called memory shrinking and there are several possibilities for distributed auxiliaries. Please make yourself familiar with the concept of the composite cache (memory cache and auxiliaries). There is a lot of documentation on the site. 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. The LateralCache does this. See the configuration docs. It can be configured to distribute cache objects as well as invalidation information in a cache cluster. I don't know how much JCS is used ATM and if we can break that much the API but since that would be a 2.0 I think it is the moment To the application, a cache normally looks like a map. So there is not much to break. However there are a couple of applications that use JCS, namely the Torque O/R mapper and Turbine, the project JCS originated from. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
On 06.05.14 13:27, Romain Manni-Bucau wrote:
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Please see the docs about UDP discovery. JCS already can do this.
Bye, Thomas.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
On 06.05.14 22:39, Romain Manni-Bucau wrote: That's my experience too. So let's go for the concurrenthashmap impl (patch on jira) and then see how we do the invalidation stuff in a 2.1? Again, I'd like to kindly ask to evaluate the already existing features of JCS. It might appear to you as an abandoned project but it isn't. JCS dates back to around 2003 and has been in use for quite some time. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Hi Thomas, actually I evaluated JCS and found several issues (why ATM JCache doesn't rely on it anymore): 1) about network stuff: listeners are not enough and needs an important refactoring for JCache, it is not that test friendly (start aone (or more) instance(s) of server and several clients in the same JVM) and more important reason to not go further in it is that it doesn't seem the default need. So we can skip it for 1st JCache compliant release IMHO. 2) why a ConcurrentHashMap instead of a CompositeCache: I hesitated a lot on it but after some benchmarks (get/put mainly) JCS was really too slow compared to a concurrenthashmap. Now it is slower but not enough to let user think of using a concurrenthashmap in their code cause cache would be too slow. I'll try to rework a bit JCSCache to merge both but if I don't manage to make it comparable I think we should just get 2 implementations. Another really blocking point ATM is the fact JCS mandates key/value pairs to be serializable. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-11 17:33 GMT+02:00 Thomas Vandahl t...@apache.org: On 07.05.14 12:03, Raffaele P. Guidi wrote: Talking about next steps, have you ever considered a second level of (off heap) cache? My question is of course not so casual, being the PMC of DirectMemory :) I think there are a lot of potential synergies, here. I include DM's dev list to gather opinions and solicitate feedback from the team members. This already has been discussed in http://markmail.org/message/k3htktmxcmncl5pt and I'm still very interested to have a JCS DirectMemory auxiliary. What is the status of the implementation that Mir Tanvir Hossain was supposed to contribute? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Yep your memory is much better than mine - I didn't recall starting this thread three years ago. In any case the related ticket ( https://issues.apache.org/jira/browse/DIRECTMEMORY-35 ) has never been picked up or updated by Mir so I guess this job in need of a new volunteer... 2014-05-11 17:33 GMT+02:00 Thomas Vandahl t...@apache.org: On 07.05.14 12:03, Raffaele P. Guidi wrote: Talking about next steps, have you ever considered a second level of (off heap) cache? My question is of course not so casual, being the PMC of DirectMemory :) I think there are a lot of potential synergies, here. I include DM's dev list to gather opinions and solicitate feedback from the team members. This already has been discussed in http://markmail.org/message/k3htktmxcmncl5pt and I'm still very interested to have a JCS DirectMemory auxiliary. What is the status of the implementation that Mir Tanvir Hossain was supposed to contribute? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Hi Romain, On 11.05.14 20:33, Romain Manni-Bucau wrote: actually I evaluated JCS and found several issues (why ATM JCache doesn't rely on it anymore): Well, then what does the project have to do with JCS? The initial idea was to provide JCache compatibility to JCS, IIRC. 1) about network stuff: listeners are not enough and needs an important refactoring for JCache, it is not that test friendly (start aone (or more) instance(s) of server and several clients in the same JVM) and more important reason to not go further in it is that it doesn't seem the default need. So we can skip it for 1st JCache compliant release IMHO. I don't think so. A JCS core release will have to have at least the documented features working properly. Do you want to release commons-jcs-jcache separately? 2) why a ConcurrentHashMap instead of a CompositeCache: I hesitated a lot on it but after some benchmarks (get/put mainly) JCS was really too slow compared to a concurrenthashmap. Now it is slower but not enough to let user think of using a concurrenthashmap in their code cause cache would be too slow. Again, I'd like to ask you seriously to make yourself familiar with the concepts behind JCS. If all you need is a ConcurrentHashMap, you simply should use a ConcurrentHashMap. But if you need fine-grained control over your caching mechanisms, the map is simply not enough and the lower speed can be easily traded in for the additional features. I'll try to rework a bit JCSCache to merge both but if I don't manage to make it comparable I think we should just get 2 implementations. Another really blocking point ATM is the fact JCS mandates key/value pairs to be serializable. -1 That would not be commons-jcs-jcache but commons-jcache. Please reconsider. You will come across a lot of the requirements that JCS can fulfill today, I promise. And once separated, the two projects will probably never merge again. And yes, serializable keys and values are absolutely necessary to support disk caches and distributed caches. I cannot imagine any decent non-trivial cache implementation to work without them. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
On 07.05.14 12:03, Raffaele P. Guidi wrote: Talking about next steps, have you ever considered a second level of (off heap) cache? My question is of course not so casual, being the PMC of DirectMemory :) I think there are a lot of potential synergies, here. I include DM's dev list to gather opinions and solicitate feedback from the team members. This already has been discussed in http://markmail.org/message/k3htktmxcmncl5pt and I'm still very interested to have a JCS DirectMemory auxiliary. What is the status of the implementation that Mir Tanvir Hossain was supposed to contribute? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
I'm trying to use JCS under JCache API (if it was not clear). I'm removing serializable constraint from signatures (next step will be to enforce it in impl as a validation but a cache forcing cached values/keys to be serializable is just not really usable in more of 80% of cases I met). I'll try this week more or less to get something decent. If not maybe you are right and we'll do a jcache incubator project starting from last commit without jcs-core as a dep of jcache module. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-11 21:02 GMT+02:00 Thomas Vandahl t...@apache.org: Hi Romain, On 11.05.14 20:33, Romain Manni-Bucau wrote: actually I evaluated JCS and found several issues (why ATM JCache doesn't rely on it anymore): Well, then what does the project have to do with JCS? The initial idea was to provide JCache compatibility to JCS, IIRC. 1) about network stuff: listeners are not enough and needs an important refactoring for JCache, it is not that test friendly (start aone (or more) instance(s) of server and several clients in the same JVM) and more important reason to not go further in it is that it doesn't seem the default need. So we can skip it for 1st JCache compliant release IMHO. I don't think so. A JCS core release will have to have at least the documented features working properly. Do you want to release commons-jcs-jcache separately? 2) why a ConcurrentHashMap instead of a CompositeCache: I hesitated a lot on it but after some benchmarks (get/put mainly) JCS was really too slow compared to a concurrenthashmap. Now it is slower but not enough to let user think of using a concurrenthashmap in their code cause cache would be too slow. Again, I'd like to ask you seriously to make yourself familiar with the concepts behind JCS. If all you need is a ConcurrentHashMap, you simply should use a ConcurrentHashMap. But if you need fine-grained control over your caching mechanisms, the map is simply not enough and the lower speed can be easily traded in for the additional features. I'll try to rework a bit JCSCache to merge both but if I don't manage to make it comparable I think we should just get 2 implementations. Another really blocking point ATM is the fact JCS mandates key/value pairs to be serializable. -1 That would not be commons-jcs-jcache but commons-jcache. Please reconsider. You will come across a lot of the requirements that JCS can fulfill today, I promise. And once separated, the two projects will probably never merge again. And yes, serializable keys and values are absolutely necessary to support disk caches and distributed caches. I cannot imagine any decent non-trivial cache implementation to work without them. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Pushed, I'll open a new thread on TODOs I have in mind and needing discussion Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-11 21:16 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: I'm trying to use JCS under JCache API (if it was not clear). I'm removing serializable constraint from signatures (next step will be to enforce it in impl as a validation but a cache forcing cached values/keys to be serializable is just not really usable in more of 80% of cases I met). I'll try this week more or less to get something decent. If not maybe you are right and we'll do a jcache incubator project starting from last commit without jcs-core as a dep of jcache module. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-11 21:02 GMT+02:00 Thomas Vandahl t...@apache.org: Hi Romain, On 11.05.14 20:33, Romain Manni-Bucau wrote: actually I evaluated JCS and found several issues (why ATM JCache doesn't rely on it anymore): Well, then what does the project have to do with JCS? The initial idea was to provide JCache compatibility to JCS, IIRC. 1) about network stuff: listeners are not enough and needs an important refactoring for JCache, it is not that test friendly (start aone (or more) instance(s) of server and several clients in the same JVM) and more important reason to not go further in it is that it doesn't seem the default need. So we can skip it for 1st JCache compliant release IMHO. I don't think so. A JCS core release will have to have at least the documented features working properly. Do you want to release commons-jcs-jcache separately? 2) why a ConcurrentHashMap instead of a CompositeCache: I hesitated a lot on it but after some benchmarks (get/put mainly) JCS was really too slow compared to a concurrenthashmap. Now it is slower but not enough to let user think of using a concurrenthashmap in their code cause cache would be too slow. Again, I'd like to ask you seriously to make yourself familiar with the concepts behind JCS. If all you need is a ConcurrentHashMap, you simply should use a ConcurrentHashMap. But if you need fine-grained control over your caching mechanisms, the map is simply not enough and the lower speed can be easily traded in for the additional features. I'll try to rework a bit JCSCache to merge both but if I don't manage to make it comparable I think we should just get 2 implementations. Another really blocking point ATM is the fact JCS mandates key/value pairs to be serializable. -1 That would not be commons-jcs-jcache but commons-jcache. Please reconsider. You will come across a lot of the requirements that JCS can fulfill today, I promise. And once separated, the two projects will probably never merge again. And yes, serializable keys and values are absolutely necessary to support disk caches and distributed caches. I cannot imagine any decent non-trivial cache implementation to work without them. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[jcs] What's next?
Hi guys, few questions about jcs: 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. wdyt? I don't know how much JCS is used ATM and if we can break that much the API but since that would be a 2.0 I think it is the moment Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
FYI I attached a patch using a ConcurrentHashMap here https://issues.apache.org/jira/browse/JCS-127 It is pretty fast compared to previous impl. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi guys, few questions about jcs: 1) I played a bit with remote cache server etc and didn't find a lot of use cases, do we keep it this way (linked to 4) )? 2) API: do we use JCache as main API or do we keep core? 3) Reviewing JCache module I really wonder if we shouldn't use a ConcurrentHashMap instead of a the currently backing CompositeCache and add on top of this locally optimized implementation two things: a) eviction (a thread regularly iterating over local items to check expiry would be enough), b) distribution (see 4) ) 4) distributed mode: I wonder if we shouldn't rethink it and potentially add CacheK, V listeners usable in JCache to know if another node did something (useful to get consistent stats at least - basically we need a way to aggregate on each note stats) + use a key for each node to keep data on a single node + potentially add backup on another node. wdyt? I don't know how much JCS is used ATM and if we can break that much the API but since that would be a 2.0 I think it is the moment Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Node { // remote and local API
get(k), put(k, v) (CacheK, V primitive methods)
Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}
EntryRepartitor {
Node[] nodeAndBackups(key)
}
get(key) { // symmetrical for put of course
Node[] nodes = entryRepartitor.nodeAndBackups(key);
for (final Node node : nodes) {
try {
return node.get(key);
} catch(final RemoteCacheException rce) { // API exception
throw rce.getJCacheException();
} catch(final Exception e) { // network exception try next node
// continue
}
}
}
Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.
To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
FYI I attached a patch using a ConcurrentHashMap here
https://issues.apache.org/jira/browse/JCS-127
It is pretty fast compared to previous impl.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
Hi guys,
few questions about jcs:
1) I played a bit with remote cache server etc and didn't find a lot
of use cases, do we keep it this way (linked to 4) )?
2) API: do we use JCache as main API or do we keep core?
3) Reviewing JCache module I really wonder if we shouldn't use a
ConcurrentHashMap instead of a the currently backing CompositeCache
and add on top of this locally optimized implementation two things:
a) eviction (a thread regularly iterating over local items to check
expiry would be enough), b) distribution (see 4) )
4) distributed mode: I wonder if we shouldn't rethink it and
potentially add CacheK, V listeners usable in JCache to know if
another node did something (useful to get consistent stats at least -
basically we need a way to aggregate on each note stats) + use a key
for each node to keep data on a single node + potentially add backup
on another node.
wdyt?
I don't know how much JCS is used ATM and if we can break that much
the API but since that would be a 2.0 I think it is the moment
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
Well my personal experience only:
1.) I barely use distributed caches. I use ehcache in most of my projects as of
today, but do not use the distribution feature much. Way too complicated
2.) What actually IS useful is distributed cache invalidation. The caching side
is fine to just select any values from my DB if they are not yet cached. But if
I change those values, then I really need some ways to get rid of the values in
all the caches on all my cluster nodes.
So from a purely personal point I would favour a mode which is really fast as a
local cache but would have some ways to distribute the invalidation of a cache
to all other nodes.
Not sure how this fits into jcs - don't know the codebase well enough to judge
about it.
LieGrue,
strub
On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau rmannibu...@gmail.com wrote:
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Node { // remote and local API
get(k), put(k, v) (CacheK, V primitive methods)
Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}
EntryRepartitor {
Node[] nodeAndBackups(key)
}
get(key) { // symmetrical for put of course
Node[] nodes = entryRepartitor.nodeAndBackups(key);
for (final Node node : nodes) {
try {
return node.get(key);
} catch(final RemoteCacheException rce) { // API exception
throw rce.getJCacheException();
} catch(final Exception e) { // network exception try next node
// continue
}
}
}
Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.
To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
FYI I attached a patch using a ConcurrentHashMap here
https://issues.apache.org/jira/browse/JCS-127
It is pretty fast compared to previous impl.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
Hi guys,
few questions about jcs:
1) I played a bit with remote cache server etc and didn't find a lot
of use cases, do we keep it this way (linked to 4) )?
2) API: do we use JCache as main API or do we keep core?
3) Reviewing JCache module I really wonder if we shouldn't use a
ConcurrentHashMap instead of a the currently backing CompositeCache
and add on top of this locally optimized implementation two things:
a) eviction (a thread regularly iterating over local items to check
expiry would be enough), b) distribution (see 4) )
4) distributed mode: I wonder if we shouldn't rethink it and
potentially add CacheK, V listeners usable in JCache to know if
another node did something (useful to get consistent stats at least -
basically we need a way to aggregate on each note stats) + use a key
for each node to keep data on a single node + potentially add backup
on another node.
wdyt?
I don't know how much JCS is used ATM and if we can break that much
the API but since that would be a 2.0 I think it is the moment
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] What's next?
That's my experience too. So let's go for the concurrenthashmap impl
(patch on jira) and then see how we do the invalidation stuff in a
2.1?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 19:54 GMT+02:00 Mark Struberg strub...@yahoo.de:
Well my personal experience only:
1.) I barely use distributed caches. I use ehcache in most of my projects as
of today, but do not use the distribution feature much. Way too complicated
2.) What actually IS useful is distributed cache invalidation. The caching
side is fine to just select any values from my DB if they are not yet cached.
But if I change those values, then I really need some ways to get rid of the
values in all the caches on all my cluster nodes.
So from a purely personal point I would favour a mode which is really fast as
a local cache but would have some ways to distribute the invalidation of a
cache to all other nodes.
Not sure how this fits into jcs - don't know the codebase well enough to
judge about it.
LieGrue,
strub
On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Here some pseudo-core details about my first mail:
New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)
NetworkTopology { // impl using udp/tcp/or whatever
Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}
Node { // remote and local API
get(k), put(k, v) (CacheK, V primitive methods)
Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}
EntryRepartitor {
Node[] nodeAndBackups(key)
}
get(key) { // symmetrical for put of course
Node[] nodes = entryRepartitor.nodeAndBackups(key);
for (final Node node : nodes) {
try {
return node.get(key);
} catch(final RemoteCacheException rce) { // API exception
throw rce.getJCacheException();
} catch(final Exception e) { // network exception try next node
// continue
}
}
}
Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.
To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.
wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
FYI I attached a patch using a ConcurrentHashMap here
https://issues.apache.org/jira/browse/JCS-127
It is pretty fast compared to previous impl.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
Hi guys,
few questions about jcs:
1) I played a bit with remote cache server etc and didn't find a lot
of use cases, do we keep it this way (linked to 4) )?
2) API: do we use JCache as main API or do we keep core?
3) Reviewing JCache module I really wonder if we shouldn't use a
ConcurrentHashMap instead of a the currently backing CompositeCache
and add on top of this locally optimized implementation two things:
a) eviction (a thread regularly iterating over local items to check
expiry would be enough), b) distribution (see 4) )
4) distributed mode: I wonder if we shouldn't rethink it and
potentially add CacheK, V listeners usable in JCache to know if
another node did something (useful to get consistent stats at least -
basically we need a way to aggregate on each note stats) + use a key
for each node to keep data on a single node + potentially add backup
on another node.
wdyt?
I don't know how much JCS is used ATM and if we can break that much
the API but since that would be a 2.0 I think it is the moment
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
