[infinispan-dev] JBoss Libra

[Sanne Grinovero]

On 4 February 2012 14:57, Manik Surtani <manik at jboss.org> wrote:
> This is very similar to storeAsBinary.  If this is set to true, then keys and values are serialized and stored as a MarshalledValue which contains the resulting byte[].  So rather than restrict to just byte[] types, we could restrict to:
>
>  * byte[] or any other primitive, primitive array or String
>  * OR, if storeAsBinary is set to true.

+1, the family of known sizes can be extended. We could even do a
recursive calculation and ask the registered Externalizer for the
specific type; it's unlikely we can have this information returned by
all externalizers but many could be able to handle a fairly accurate
estimate.

Precision is more important when allocating buffers for network & co,
so if we enrich the Externalizer API to provide such information it
would be handy to know as well if it's going to be an estimate or a
precise size of serialized form, considering as well that serialized
size isn't necessarily going to match the runtime memory cost.

>
> The tricky part will be to get this to work with Vladimir's LIRS container which works on number of entries.  :)  Vladimir?
>
> Cheers
> Manik
>
> On 3 Feb 2012, at 18:14, Sanne Grinovero wrote:
>
>> New idea: what about implementing a memory-size based eviction policy
>> which only works on values of type byte[] ?
>>
>> The limitation might be strong, but actually applies quite well to
>> some use cases:
>> - Hot Rod
>> - Lucene
>>
>> I think this could serve well more use cases, and specifically for
>> Lucene it would rock, as besides from some small metadata, the bulk of
>> stuff is big arrays of bytes.
>>
>> -- Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev