Oh great, a good one, I will use it in the future :) I mentioned this
mechanism (which you call "staging" - a pretty CMS oriented term ;) in the
proposed roadmap - I quote from the wiki (
http://wiki.apache.org/directmemory/ProposedRoadmap)
It [DirectMemory] used to have three layers (heap, off-heap, file/nosql) and
> to authomatically push forward/backward in the chain items according to
> their usage. *It turned out overly complicated and mostly inefficent at
> runtime* (probably mostly because of my poor implementation).
Thing is, from my point of view (or should I say POV? :D) the *USP of
DirectMemory is off-heap storage itself*. All other cache implementation
(ehcache, oscache, even JSC) already have "staging" (promotion and demotion
of items from one layer to another according to some rules). DirectMemory is
the only open source solution for off-heap on the JVM. And that's it.
Nevertheless I think that (again, see in the wiki) adding basic heap, file
and lateral storages would make it a complete one-stop cache solution and
it's well worth the effort.
Ciao,
R
On Mon, Oct 10, 2011 at 4:46 PM, Daniel Manzke <[email protected]
> wrote:
> Hi Raffaele,
>
> a USP is a Unique Selling Point or in Open Source, the One Thing which
> makes
> you different. :)
>
> With Staging I mean the Mechanismn, which was implemented by you in the
> first Version. There a Object was able to be transfered from "Live", to a
> serialized Form, to a Off-Heap Form.
> You have implemented it, while using your different Storages.
>
> <snip>
>
> public void disposeOverflow() {
> heapStore().overflowToNext();
> offHeapStore().overflowToNext();
>
> diskStore().overflowToNext();
>
> }
> </snip>
> *
> *
> *Bye,
> *
>
> Daniel
>
> 2011/10/10 Raffaele P. Guidi <[email protected]>
>
> > Uhm not sure I understand your 'staging' concept and for sure I don't
> know
> > what a USP is. There are two layers in directmemory, one that delivers
> > slices of bytebuffers and the other one that automatically serializes and
> > saves objects off heap synchronously. A possible improvement is doing
> this
> > asynchronously to gain speed - if this is what you mean with staging.
> > Anyway
> > DM could grow both as a standalone cache and as a plugin for other
> > products,
> > there is room for both things. Did you check the roadmap in the wiki?
> >
> > Ciao,
> > R
> >
> > On Monday, October 10, 2011, Daniel Manzke <[email protected]
> >
> > wrote:
> > > Hi guys,
> > >
> > > I have read about the submit of DirectMemory to the ASF and I really
> > > appreciate it. Due the fact that I know Simone for some time and he
> asked
> > > me, if I want to participate here are my first Things which are in my
> > mind.
> > > ;)
> > >
> > > I'm working for an Enterprise Content Management Vendor in Germany and
> > > started some years ago with reading about Things like BigMemory,
> OrientDB
> > > and how to build File Caches.
> > > From the beginning of DirectMemory @ github, I was interested in this
> > > project, because I had the same Idea. So I started to play around with
> it
> > > and the best of DirectMemory was the Concept of Staging!
> > > Automatically/Manually submitting an Object from normal live, to
> > serialized
> > > heap, to off-heap. With the last big change, this concept was killed,
> if
> > I'm
> > > right. (just had a short look into the github repo)
> > > At the moment I'm not sure, what the aim of DirectMemory is. Is it the
> > Idea
> > > to be a pluggable Layer for other Cache Implementations or is it
> > "another"
> > > Cache Implementation?
> > > BigMemory and also ElasticMemory (by Hazelcast) is mostly used for
> > Caching.
> > > To get often used Stuff out of the Garbage Collector.
> > >
> > > I'm still thinking, that the Staging mechanismn was the USP and you
> > should
> > > not forget it.
> > >
> > > I talked with Simone about the outstanding migration and the code you
> > want
> > > to bring to the ASF. At the moment I'm not sure, because with the last
> > > submit, you are near to a Pool which delivers slices of ByteBuffer.
> > >
> > > Don't get me wrong, this is the first step, but there is room for a lot
> > of
> > > improvements, especially the Design of the APIs and the Implementations
> > > (Staging was done in nearly one class ;)) itself.
> > > Would be nice to get some more informations what the aim for the 1.0
> is.
> > >
> > >
> > > Just some thoughts. Maybe a little bit rough. :) And I'm would be happy
> > to
> > > bring some Thoughts/Requirements from the Enterprise Business into the
> > > project. (and also Commits if you want to :))
> > >
> > > Bye and Best Regards,
> > > Daniel
> > >
> >
>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke
>
