Re: Relieving some ClassLoader contention in PreferredClassProvider

Mark Brouwer wrote:
> Hi Gregg,
>
> On 10/26/06, Gregg Wonderly <[email protected]> wrote:
>> While in Brussels at JCM10, I talked to Bob Scheifler about some
>> contention in
>> ClassLoader creation that I've been seeing with one of my customers.
>> They have
>> two parts of their network, one which is local, and quite quick.  The
>> other is
>> low bandwidth, and has lot of latency involved in access across it.
>> My Jini
>> based desktop environment, makes Unicast lookup calls to 5 different
>> machines in
>> their environment, which each machine having about 40 services.  The
>> lookups
>> return fairly quickly, but the initial classloader creation causes the
>> higher
>> speed network related lookup and processing threads to get delayed by
>> the slower
>> network.
>
> Very good catch :-) and something needs to be done about it. The only
> problem I have with your solution is that it relies on J2SE 5
> features. I think one of the discussions, if the future Apache project
> will start this century, will be whether we want to make the jump to
> J2SE 5. So far I'm still inclined to stay with J2SE 1.4 for
> interoperability reasons with most of the installed base of J2EE
> application servers. But maybe PreferredClassProvider is an exception
> as this is likely not something that you are able to configure for
> your J2EE application server anyway.

In hindsight I believe that some strange behavior I've seen in the past
with loads of services starting in instances of Seven can be traced down
to this issue in PreferredClassProvider. As this is high priority for
Seven and I'm still committed to J2SE 1.4 I've created a fix to
PreferredClassProvider that allows for higher concurrency when creating
class loaders by only locking on an object related to the class loader
key. Now that we can start with the River project hopefully it will get
fixed there too soon, but the code is available from the Cheiron
repository
http://scm.cheiron.org:1665/@md=d&cd=//cheiron/jsk/version/2.1/src/net/jini/loader/pref/&cdf=//cheiron/jsk/version/2.1/src/net/jini/loader/pref/PreferredClassProvider.java&sr=163&c=4kl@//cheiron/jsk/version/2.1/src/net/jini/loader/pref/PreferredClassProvider.java


I have no clue what the performance characteristics are of this
implementation versus Gregg's solution, but I think that the extra
synchronization can be neglected in the typical real world scenario.

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.

Happy new year to all,
--
Mark

--------------------------------------------------------------------------
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]