On 12-02-04 11:57 AM, Manik Surtani 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:
*
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
- Original Message -
From: Sanne Grinovero sa...@infinispan.org
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Saturday, February 4, 2012 10:08:16 PM
Subject: Re: [infinispan-dev] JBoss Libra
On 4 February 2012 14:57, Manik Surtani ma...@jboss.org wrote
- Original Message -
From: Sanne Grinovero sa...@infinispan.org
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Monday, February 6, 2012 2:56:58 PM
Subject: Re: [infinispan-dev] JBoss Libra
On 6 February 2012 14:44, Mircea Markus mmar...@redhat.com wrote
On 6 Feb 2012, at 13:59, Vladimir Blagojevic wrote:
On 12-02-04 11:57 AM, Manik Surtani 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
Am 03.02.2012 18:14, schrieb Sanne Grinovero:
New idea: what about implementing a memory-size based eviction policy
which only works on values of type byte[] ?
+1
This would match perfectly to one of my major use cases of ispn :-D
___
infinispan-dev
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
On 4 February 2012 14:57, Manik Surtani ma...@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
Just saw this: https://github.com/wolfc/jboss-libra
We should investigate the possibility of adding this to Infinispan and provide
memory size based eviction, WDYT?
The performance impact would need to be measured too.
EhCache has apparenlty done something similar but from what I heard, it's
IMO, measuring object size using java.lang.instrument is not a good
idea: first of all, it's probably very slow and the time to do so is
linear to the number of live objects. Second, this probably takes into
acount only objects in the cache, but not the cache structures used by
Infinispan,
On 31 Jan 2012, at 09:34, Bela Ban wrote:
IMO, measuring object size using java.lang.instrument is not a good
idea: first of all, it's probably very slow and the time to do so is
linear to the number of live objects.
+1
I remember prototyping this for JBossCache and the harness and that's
On 31 Jan 2012, at 11:06, Mircea Markus wrote:
..or keep the in-memory data in serialized form (byte[]) - that can be
counted - and add an empiric factor (TBD) for the harness/ISPN structure
that holds the data. AFAIK coherence does this.
I believe this is our beset bet. We already
MarshalledValue is already caching the size when serialized to
properly dimension output buffers. This value can be reused..
On 31 January 2012 11:09, Manik Surtani ma...@jboss.org wrote:
On 31 Jan 2012, at 11:06, Mircea Markus wrote:
..or keep the in-memory data in serialized form (byte[]) -
On 1/31/12 11:32 AM, Tristan Tarrant wrote:
On 01/31/2012 10:34 AM, Bela Ban wrote:
The approach I've recommended before is to trigger an eviction policy
based on free/available memory. This can easily be fetched from the JVM
via JMX...
And maybe you're just close to a large GC and you're
On 01/31/2012 03:32 PM, Bela Ban wrote:
IIRC you can look at the size of the young and old generation via JMX,
and there you can see how much memory has accumulated.
Does that work when using G1 ?
Tristan
___
infinispan-dev mailing list
I don't know, but I don't see why not.
If you look at java.lang.{Memory,GarbageCollector,MemoryPool}, there are
a lot of values you can look at, including the details on eden and old.
You can even register for notifications when free memory drops below a
certain threshold, but I've never tried
On Tue, Jan 31, 2012 at 4:49 PM, Bela Ban b...@redhat.com wrote:
I don't know, but I don't see why not.
If you look at java.lang.{Memory,GarbageCollector,MemoryPool}, there are
a lot of values you can look at, including the details on eden and old.
I just looked at G1 with JConsole, it does
17 matches
Mail list logo
