Re: Relieving some ClassLoader contention in PreferredClassProvider

On Wed, Jan 03, 2007 at 10:21:14AM -0600, Gregg Wonderly wrote:
> Peter Jones wrote:
>> Why bother executing the task in a thread pool, instead of just
>> using the current thread, which has nothing better to do at that
>> point, and executes it directly in the unmodified implementation?
>
> There are a couple of issues which I am trying to deal with in
> making these changes.  Predominately, it's about eliminating the
> locking that slow network connections create in this code.  But the
> primary issue is making progress visible.  If a user is on a slow
> cellphone connection and talking to 5 hosts each hosting 20 services
> that's about 100 codebase class loaders that need to resolved and
> created.  Having 100 network connections running over a slow link,
> trying to test the classloader permissions, will create a huge delay
> and then a bunch of activity.

Just to be clear, is the network activity that you are concerned about
only the name->address resolution done by SocketPermission.implies
during PreferredClassProvider.createClassLoader?  Or is it also the
resolution potentially done by URL.equals during the table lookup and
the "boomerang" search (PreferredClassProvider.findOriginLoader)?

> I'm trying to create some continuous activity by limiting the total
> number of simultaneous things going on.

Ah-- well that still wouldn't seem to require that the tasks be run in
separate threads; a Semaphore should accomplish it without increasing
the total thread count.  And I am inclined to think that this is a
specialized enough requirement that it should indeed be separated from
the general improvement of reducing the table locking-- like in an
overridden PreferredClassProvider.createClassLoader method.

-- Peter

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