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
