incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raffaele P. Guidi" <raffaele.p.gu...@gmail.com>
Subject Re: Ideas, Suggestions, ...
Date Mon, 10 Oct 2011 06:57:50 GMT
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
>

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