Re: Relieving some ClassLoader contention in PreferredClassProvider

Peter Jones wrote:
> 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 am interested in acceptable behavior in both cases.  The .implies() is one
thing that causes all URLs to be queried (one optimization I added was to check
for an HttpURLConnection instance and request a "HEAD" instead of "GET").  A non
operating codebase host, will hang all threads for at least the TCP timeout
period foreach URL.openConnection() at least.  So, I am really concerned overall
about minimizing the impact any particular failure has on unrelated threads.

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

Yes a counting Semaphore would probably be a better choice since we have at
least as many threads as we will be needing to perform the work, at our disposal
already.

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]