Re: Relieving some ClassLoader contention in PreferredClassProvider

Mark Brouwer wrote:
> While looking for other problems in the code I also ran into the fact
> that PreferredClassProvider relies heavily on tests for equality on
> objects of type java.net.URL which is bad as this is a blocking
> operation (requires name resolution) and I even doubt whether this is
> correct as this can get you into trouble with codebases that rely on
> virtual hosting (see semantics for equals of URL versus URI). I haven't
> give it much thought yet and I have to start working on a solution, but
> I think most tests should be performed against URIs or the string
> representation of the URL.

I found that in my implementation, I am experiencing classloader inequalities
due to the equality not working reliably.  The end result is that class loaders
are being recreated for certain codebases and I am seeing
"ClassNotFoundException" periodically, at random intervals as short leases (a
configuration error on my part which exposed this behavior) on notify() expire
and a background thread attempts to reestablish the notify() context.

I brought this up on the concurrency-interest mailing list, because
ConcurrentHashMap.putIfAbsent() is randomly returning the wrong value.  I can
partially alter the behavior by replacing putIfAbsent() with a synchronized
block that does the get/put that putIfAbsent() does.  I've backed out my changes
for now because of this issue in my local copy of JTSK-2.1.  But, I will revisit
this directly.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]