river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: SocketPermission and LookupLocatorDiscovery vs. Reggie scalability
Date Wed, 13 Apr 2011 18:01:39 GMT
Understood, Patricia, but I'm not aware of a java.util.concurrent class
that facilitates that pattern of a check-then-set on a cache Map while
using weak keys. The old algorithm just locked the whole Map across the
check & set -- it was correct but was too slow.  The new algorithm
breaks that into a lock per key, but that's not correct behavior because
global changes to the Map are no longer synchronized under a single
lock.

Gregg did part of the algorithm with a Java 1.5 ConcurrentHashMap, but
the old HashMap is now the source of the problem.  If Gregg agrees that
his patch is indeed flawed (and it's not just a misunderstanding) then
maybe I'll try to write a new patch.

Chris

-----Original Message-----
From: Patricia Shanahan [mailto:pats@acm.org] 
Sent: Wednesday, April 13, 2011 12:06 PM
To: dev@river.apache.org
Subject: Re: SocketPermission and LookupLocatorDiscovery vs. Reggie
scalability

On 4/13/2011 9:56 AM, Christopher Dolan wrote:
...
> Putting the loaderTable access in the "synchronized (key)" block means
> that the HashMap can be modified from multiple threads.  It seems to
me
> that you must either change the loaderTable to be some other kind of
> concurrent map, or redo the locking so the put() is synchronized on
> loaderTable.
...

We are now committed to JDK 1.5, and can use java.util.concurrent.

Patricia


Mime
View raw message