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 :
> 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 :
> > 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
> 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) (Cache 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 :
> >>> 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 :
> 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 Cache 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
Re: [jcs] What's next?
Oops, wrong address, sorry :)
2014-05-07 12:03 GMT+02:00 Raffaele P. Guidi :
> 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 :
>
> 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 :
>> > 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) (Cache 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 :
>> >>> 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.
>> >>>
&g
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 : > 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: Google+ Apache Commons brand page
DirectMemory has also a facebook page. I would be happy to give admin rights to whoever is interested in mantaining it. With twitter it's a bit more complicated as multiple ownership is not allowed - probably the account should be shared (not sure if it complies with their terms of use). Ciao, R Il giorno 23/dic/2011 15:42, "Christian Grobmeier" ha scritto: > On Fri, Dec 23, 2011 at 4:23 PM, Emmanuel Bourg wrote: > > Thank you for reserving the page Christian. In the same vein we should > > probably register an Apache Commons account on Twitter. > > +1 > > > I think this raises an interesting point: we lack the tools to properly > > communicate directly on the commons.apache.org site. The announcements > are > > not displayed on the home page, probably because Commons comes from > Jakarta > > that did this for its sub projects. > > thats true... should be addressed. > > What has happened to Simones "fluido" effort? Picking this up again > might be a good chance > > > Ideally I imagine the news should be posted on our site and replicated > > automatically on Google+ and Twitter. I don't know if other Apache > projects > > do this already. > > Directmemory does twitter, and Apache Struts does Twitter and G+: > https://plus.google.com/116578204419118022943/posts > https://twitter.com/#!/TheApacheStruts > > Actually I like the utilizing of Struts very much. > > Automatically on G+ is not possible imho. We would need to create +1 > buttons, and people can share a page on G+. > Twitter might be possible, but when should it update? I mean, what > hook could we use? > > The other projects I know or have heard of are doing all the stuff > manually (specifically a few volunteers of the PMC do) > > Cheers > Christian > > > > > Emmanuel Bourg > > > > > > > > Le 23/12/2011 09:32, Christian Grobmeier a écrit : > >> > >> Hey there, > >> > >> > >> I want to mention that I have reserved the G+ brand page "Apache > Commons" > >> https://plus.google.com/106381282762520124070 > >> > >> At the moment we don't use such stuff, but we probably should do. > >> Anyway once I can transfer ownership of this page to Commons and once > >> this project wants to have that page, I am willing to transfer of > >> course. In the meanwhile I can try to post updates to it on the > >> Commons ongoings, if folks agree. So far i have not done anything with > >> it. > >> > >> Let me know. > >> > >> Cheers > >> Christian > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [JCS] - proposal on a off-heap plugin for JCS based on DirectMemory
We could also provide a high performance serializer/deserializer based on protostuff... but, in any case let's follow the simplest path to demonstrate the case, there will always be room for improvement. I'm sure Mir will show us something as soon as it will be ready... I used to put stuff in github gists, in these cases, what is the best way for the ASF? Ciao, R On Sat, Nov 19, 2011 at 5:59 PM, Thomas Vandahl wrote: > On 19.11.11 09:43, Raffaele P. Guidi wrote: > > It depends on what JCS requires to manage. If it handles tcehe key-valu > > mapping on its own (as I suppose it does) you shouldn't need to use DM's > > CacheService (it would be a waste of memory) which does the same. > > CacheService puts KV mapping on top of MemoryStorageService (and some > more > > things such as the background jobs for eviction that maybe are already > > handled by JCS) . > > Yes that is the case. JCS auxiliaries are just an extension to an > existing cache infrastructure. JCS handles everything from key-value > mapping to event handling, idle time and life time management. For > auxiliaries, there is a pluggable serializer/deserializer available. > > If possible, I would like to see some code to get a better idea of what > your plans are. > > Bye, Thomas. > > PS: I'm subscribed to directmemory-dev@i.a.o, so we can drop the > personal mail addresses from the communication. >
Re: [JCS] - proposal on a off-heap plugin for JCS based on DirectMemory
It depends on what JCS requires to manage. If it handles the key-value mapping on its own (as I suppose it does) you shouldn't need to use DM's CacheService (it would be a waste of memory) which does the same. CacheService puts KV mapping on top of MemoryStorageService (and some more things such as the background jobs for eviction that maybe are already handled by JCS) . I of course don't know well the internals of JCS so it's just a good guess. Ciao, R Il giorno 19/nov/2011 00:34, "Mir Tanvir Hossain" < mir.tanvir.hoss...@gmail.com> ha scritto: > Hi Everyone, after looking into the DirectMemory code, I figured that > instead of using MemoryManagerService, I can directly use the CacheService > interface. The CacheServiceImpl class seems to do almost all the work. So I > am thinking why rewrite the same code? What do you think? > > -Mir > > On Thu, Nov 10, 2011 at 12:53 PM, Raffaele P. Guidi < > raffaele.p.gu...@gmail.com> wrote: > >> Mir (in cc) volounteered on this task - I think he could start following >> your advice to use IndexDiskCache as a template and try to implement it on >> top of our MemoryManagerService. I suggest Mir and I subscribe to the >> commons mailing lists (I already did) and Thomas (and anyone interested) >> subscribes to directmemory-dev to simplify communication. I will open a >> jira for the task. >> >> Ciao, >>R >> >> >> On Wed, Nov 9, 2011 at 7:03 PM, Thomas Vandahl wrote: >> >>> On 09.11.11 00:10, Raffaele P. Guidi wrote: >>> > This is not so different from an indexed file, just it is in memory - >>> maybe >>> > you could take a look at the code (which is fairly simple) and get >>> back to >>> > us with some more targeted questions. >>> >>> I understand that the plugin is supposed to be added as an auxiliary >>> cache module, right? If so, the IndexedDiskCache could be used as a >>> template. How do you suggest we proceed? >>> >>> Bye, Thomas. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >
Re: [JCS] - proposal on a off-heap plugin for JCS based on DirectMemory
Mir (in cc) volounteered on this task - I think he could start following your advice to use IndexDiskCache as a template and try to implement it on top of our MemoryManagerService. I suggest Mir and I subscribe to the commons mailing lists (I already did) and Thomas (and anyone interested) subscribes to directmemory-dev to simplify communication. I will open a jira for the task. Ciao, R On Wed, Nov 9, 2011 at 7:03 PM, Thomas Vandahl wrote: > On 09.11.11 00:10, Raffaele P. Guidi wrote: > > This is not so different from an indexed file, just it is in memory - > maybe > > you could take a look at the code (which is fairly simple) and get back > to > > us with some more targeted questions. > > I understand that the plugin is supposed to be added as an auxiliary > cache module, right? If so, the IndexedDiskCache could be used as a > template. How do you suggest we proceed? > > Bye, Thomas. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [JCS] - proposal on a off-heap plugin for JCS based on DirectMemory
Cool. Basically the plugin should fit in the middle between standard heap cache and the lateral (network) plugin. DirectMemory exposes two basic services: the memorystorage, which acts almost like a malloc(), allocating large buffers which can be split in "slices" described by a Pointer structure (with a start and a length). The (higher level) Cache facade allocates memory using the MemoryStorage and saves the pointers into a map handling transparent serialization of objects (using protostuff). This is not so different from an indexed file, just it is in memory - maybe you could take a look at the code (which is fairly simple) and get back to us with some more targeted questions. Just to recap a bit the rationale behind it: direct memory is supposed to be a bit slower than heap (because objects need to be serialized and unserialized back) but way faster than the file system and - most of all - it is not garbage collected, thus removing the pain of gc pauses even using huge buffers (even of several GBs) in memory. Here is some reference on the matter from the original project wiki [1], my blog [2] and terracotta bigmemory product pages [3]. https://github.com/raffaeleguidi/DirectMemory/wiki http://raffaeleguidi.wordpress.com/2011/01/12/directmemory-benchmark-heap-vs-off-heap-vs-orientdb/ http://www.terracotta.org/products/bigmemory Ciao, R On Tue, Nov 8, 2011 at 9:39 PM, Thomas Vandahl wrote: > On 08.11.11 20:59, Raffaele P. Guidi wrote: > > Are you guys interested in merging efforts on this? > > Yes, absolutely. I, however, would need some introduction into the > subject to understand how this is supposed to work. I can assure my > support for the integration into the JCS code. > > Bye, Thomas. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[JCS] - proposal on a off-heap plugin for JCS based on DirectMemory
Hi, we discussed on our mailing list about integrating DirectMemory (which has recently begun incubation [1]) as a JCS off-heap plugin. We find that this could be more profitable, for us and the community in the whole, than spending time and effort building DirectMemory as a fully featured cache, and could let us just focus on off-heap management (our "core business"). This would make JCS+DirectMemory the only open source cache solution with a off-heap option around (both ehcache and hazelcast off-heap plugins are paid products). Are you guys interested in merging efforts on this? Regards, Raffaele [1] http://incubator.apache.org/directmemory/
