I've just created https://issues.apache.org/jira/browse/RIVER-396 with a new patch for PreferredClassProvider scalability. I would appreciate if anyone would be willing to review my changes. I have not actually tested my change, so I apologize in advance if there are any blatant mistakes.
Chris -----Original Message----- From: Christopher Dolan [mailto:[email protected]] Sent: Wednesday, April 13, 2011 1:02 PM To: [email protected] Subject: RE: SocketPermission and LookupLocatorDiscovery vs. Reggie scalability 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:[email protected]] Sent: Wednesday, April 13, 2011 12:06 PM To: [email protected] 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
