incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raffaele P. Guidi" <>
Subject Re: DM modularization
Date Wed, 15 Feb 2012 07:23:28 GMT
regarding the formatting thing - I honestly don't remember why I did the
choice, di as you think best. Josql is used at the core level to select
items to purge in the background, I already pointed out it can also be a
performance bottleneck but it was easy to correct with ad-hoc code.
Regarding serializers - yes it should be done but I suggest to keep the
default one in the core. The java serializer is a bit too slow to be the
default one, IMHO. All other ideas and news are great, including the
memcached protocol, which I already investigated long ago (there's a java
me cached server with pluggable implementations somewhere in google code
that is a good starting point) and the fact that you'll be able to leverage
DM in some ways.

Il giorno 14/feb/2012 22:29, "Simone Tripodi" <> ha

> Hi all guys,
> I've finally got the chance - because I also have the need - to do
> some serious work on DM - now setting up the environment, experiencing
> the following issues and also got following considerations (some of
> them already afforded but discussions where to nowhere):
> disclaimer: I am not an OSGi guru, but I've been a modularization
> advocate time before OSGi got popularity, so I would like to apply the
> same approach as well:
>  * serializers: all serializers are included by default, I am
> convinced that protostuff serializer can could be extracted as a
> separated module and maybe among other 3rd parties serializers, such
> as Kryo <>, ASF Thrift
> <> and Avro <>, and
> the newer Message Pack <> - users could plug their
> preferred serializer depending on their taste/needs/...
>  * net.sf.josql:gentlyweb-utils:1.5 artifact not found - I did a
> little research and found it on <> -
> while the feature of having an embedded query language is really cool,
> IMHO it could be part of an auxiliary module. I mean, basic query
> system must be supported by combining objects (and fluent APIs could
> help) but I'm not fully convinced on having it as foundation of our
> core module...
> A side question for Raf: I am not aware about performances, but why
> did you prefer j.u.Formatter.format( messagePattern, Object... args
> ).toString() over String.format( messagePattern, Object... args ) ?
> I extensively used the j.u.Formatter in Commons-Digester3 but for
> chaining more than one format in the same message, but I didn't notice
> the benefit of using it for single shot... TIA!
> As you can see, my proposal is having a minimal DM core, with less
> dependencies as possible, that can be easily enriched with aux
> modules...
> please provide your feedbacks, I have some time/energy to put on DM
> and glad to do it!
> TIA,
> -Simo

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