The more I research ReentrantReadWriteLock the more shocked I am. Not
only that a thread wanting to acquire write lock first has to release
read lock, but we can block forever even if we release the read lock if
we have acquired that read lock reentrantly. Each call to unlock just
reduces the
On Wed, May 11, 2011 at 11:25 AM, Vladimir Blagojevic
vblag...@redhat.com wrote:
The more I research ReentrantReadWriteLock the more shocked I am. Not
only that a thread wanting to acquire write lock first has to release
read lock, but we can block forever even if we release the read lock if
Hi,
I've added a possible solution to https://issues.jboss.org/browse/ISPN-1049,
can you please take a look and tell me what you think?
Cheers,
Mircea
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
Hi,
The basic problem behind this is that I need to be notified when a new
consistent hash is installed.
ATM there isn't any support (of which I know) for a
@ConsistenHashChangeListener.
I'm thinking to add such notifications either:
a) internally: Observer pattern on DistributionManager
On 11 May 2011, at 13:29, Sanne Grinovero wrote:
First thing I thought when reading your email was OMG do we support
on-the-fly hash implementation changes? crazy!
That's obviously not the case, but if you name it as
@ConsistenHashChangeListene that's what I would think.
good point :-)
2011/5/11 Mircea Markus mircea.mar...@jboss.com:
On 11 May 2011, at 13:29, Sanne Grinovero wrote:
First thing I thought when reading your email was OMG do we support
on-the-fly hash implementation changes? crazy!
That's obviously not the case, but if you name it as
On 11 May 2011, at 15:53, Sanne Grinovero wrote:
2011/5/11 Mircea Markus mircea.mar...@jboss.com:
On 11 May 2011, at 13:29, Sanne Grinovero wrote:
First thing I thought when reading your email was OMG do we support
on-the-fly hash implementation changes? crazy!
That's obviously not the
Were we developing for OSGi I would certainly agree with you. However in many
environments today we can reasonably expect the TCCL to be set and to be able
to load the classes we need. So whilst making it part of the API is the safest
option, it's also making complicated an API for the sake of
On Wed, May 11, 2011 at 5:51 PM, Mircea Markus mircea.mar...@jboss.com wrote:
On 11 May 2011, at 13:57, Dan Berindei wrote:
With the new push-based rebalancing code, we install the new CH before
doing any rebalancing work, so the inconsistency window should be much
smaller.
In theory we
The current behaviour is both.
But there are good reasons for finer grained control. Please have a look at
https://issues.jboss.org/browse/ISPN-1097 and let me know what you think!
Cheers
Manik
--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani
Lead, Infinispan
I'm also wondering how the equals is performed on a serialized key; I
assume they are compared as byte[], but if that's the case that should
be clearly documented as it would ignore any custom equals()
implementation.
If instead all keys are deserialized for each equals operation... well
I
Wouldn't any rehash affect the locality of these generated keys, or am I
missing something?
Erik
-Original Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Dan Berindei
Sent: Wednesday, May 11, 2011 12:47 PM
To:
Hi,
Whenever I'm switching branches from 4.2.x to master the build in IDEA takes
ages(even more, about 5 mins!!!). Most of the time is spent is Building
non-OSGi libraries for module...
Any idea on what can be done to speed things up?
Cheers,
Mircea
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote:
Were we developing for OSGi I would certainly agree with you. However in
many environments today we can reasonably expect the TCCL to be set and to
be able to load the classes we need.
14 matches
Mail list logo
