Re: Relieving some ClassLoader contention in PreferredClassProvider

Bob Scheifler wrote:
>> I think reliability doesn't equals performance so I would also like to
>> add that to the list, because many of the equals calls are within the
>> synchronized block.
>
> Can you explain how that relates to reliability?

What one calls reliability another calls predictability and another
might call something just damn slow at regular intervals, so I hope that
beside the tag I put on this problem my real concern is/has become clear.

To me reliable is an equals that doesn't change over time and that
returns within some predictable time (hopefully constant time). As
equals of URL might consult Internet resources the time to returns is
unpredictable and in a worst case might take minutes or even more to
return, even when the first resolve for that particular host worked just
fine but the entry is evicted from the cache.

As URL.equals() is heavily used in the synchronized block from where the
class loader creation takes place it means in the case that URL.equals
takes a very long time all operation that ultimately result in the
creation of a class loader are blocked.

Due to this coupling between threads the system might show behavior of
hanging in case of problems with the name resolver, and these happen in
reality.

>> And virtual hosting is affected by the current semantics.
>
> Do you have any actual practical demand for virtual hosting of codebases?

Not at this time, but on the day you need it you don't have it.

> And can you say what real problems result from the current semantics?

Maybe I don't understand your question that well, but are performance,
reliability and the chance of conflicts with virtual hosting no real
problems? (and remember questions like this can't be answered reliably,
given a largely silent user base ;-) )


BTW Bob can you come up with an example of a URL that can't be
recognized as a valid URI according to RFC 2396 and that might have been
a workable codebase annotation, I tried to find an example but I couldn't.
--
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]