incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Manzke <daniel.man...@googlemail.com>
Subject Re: Ideas, Suggestions, ...
Date Mon, 10 Oct 2011 18:29:34 GMT
Now we are on the same road. I'm totally with you. :)

And your description is the fact, why I'm watching DirectMemory from the
Beginning on and like described before, I would be happy, if I can help you
all with the Project.

(Still fighting through the last mails about Proposal, Roadmap, ... )

Bye,
Daniel

2011/10/10 Raffaele P. Guidi <raffaele.p.guidi@gmail.com>

> 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 <
> daniel.manzke@googlemail.com
> > 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 <raffaele.p.guidi@gmail.com>
> >
> > > 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 <
> daniel.manzke@googlemail.com
> > >
> > > 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
> >
>



-- 
Viele Grüße/Best Regards

Daniel Manzke

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message