This question should be posted in
http://community.jboss.org/en/infinispan?view=discussions along with further
info such as version of Infinispan used...etc.
On May 21, 2011, at 10:22 PM, Anders wrote:
Hi,
Im getting the following error whenever i try to write to inifnispan
over
On 18 May 2011, at 17:23, Manik Surtani wrote:
On 18 May 2011, at 13:32, Sanne Grinovero wrote:
1. Suggesting deferring local locks till prepare-time: wouldn't this
create a potentially large number of transaction failures? Since write
skews and overwriting may become a problem if
3. Need to think more about this, around implications of correctness of
lock acquisition is reordered. But in terms of algorithm, sorting on
identity hashcode won't work since this will be different on different
requestor JVMs.
The algorithm does NOT sort on identity hash code, but
Hi Galder
Sorry I'm replying so late
On Thu, May 19, 2011 at 2:02 PM, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1102
First of all thanks to Dan for his suggestion on reservoir
sampling+percentiles, very good suggestion:). So, I'm looking
On 5/23/11 6:15 PM, Dan Berindei wrote:
I totally agree, combining adaptive size with buffer reuse would be
really cool. I imagine when passing the buffer to JGroups we'd still
make an arraycopy, but we'd get rid of a lot of arraycopy calls to
resize the buffer when the average object size
2011/5/23 이희승 (Trustin Lee) trus...@gmail.com:
On 05/23/2011 07:40 PM, Sanne Grinovero wrote:
2011/5/23 Dan Berindeidan.berin...@gmail.com:
On Mon, May 23, 2011 at 7:04 AM, 이희승 (Trustin Lee)trus...@gmail.com
wrote:
On 05/20/2011 03:54 PM, Manik Surtani wrote:
Is spanning rows the only real
On Mon, May 23, 2011 at 7:44 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
To keep stuff simple, I'd add an alternative feature instead:
have the custom externalizers to optionally recommend an allocation buffer
size.
In my experience people use a set of well known types for the key,
2011/5/23 Dan Berindei dan.berin...@gmail.com:
On Mon, May 23, 2011 at 7:44 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
To keep stuff simple, I'd add an alternative feature instead:
have the custom externalizers to optionally recommend an allocation buffer
size.
In my experience
On Mon, May 23, 2011 at 10:12 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
2011/5/23 Dan Berindei dan.berin...@gmail.com:
On Mon, May 23, 2011 at 7:44 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
To keep stuff simple, I'd add an alternative feature instead:
have the custom
On 5/23/11 6:50 PM, Dan Berindei wrote:
From my experience, reusing and syncing on a buffer will be slower than
making a simple arraycopy. I used to reuse buffers in JGroups, but got
better perf when I simply copied the buffer.
We wouldn't need any synchronization if we reused one buffer
On 5/23/11 8:42 PM, Dan Berindei wrote:
On Mon, May 23, 2011 at 7:44 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
To keep stuff simple, I'd add an alternative feature instead:
have the custom externalizers to optionally recommend an allocation buffer
size.
In my experience
2011/5/23 Bela Ban b...@redhat.com:
On 5/23/11 6:50 PM, Dan Berindei wrote:
From my experience, reusing and syncing on a buffer will be slower than
making a simple arraycopy. I used to reuse buffers in JGroups, but got
better perf when I simply copied the buffer.
We wouldn't need any
On Mon, May 23, 2011 at 11:50 PM, Bela Ban b...@redhat.com wrote:
On 5/23/11 6:44 PM, Sanne Grinovero wrote:
To keep stuff simple, I'd add an alternative feature instead:
have the custom externalizers to optionally recommend an allocation buffer
size.
In my experience people use a set of
13 matches
Mail list logo
