Re: Relieving some ClassLoader contention in PreferredClassProvider
Gregg Wonderly <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
Peter Jones wrote: > On Thu, Jan 04, 2007 at 04:56:41PM -0600, Gregg Wonderly wrote: > >>Peter Jones wrote: >> >> >>>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. > > Wait, are you suggesting that an actual HTTP request is attempted > during the process of getting the permission for each codebase URL? Yes, my vhttp handler serves streams from multiple possible locations (cache or net) and its returns from openConnection() either a file: URL openConnection() value or a deferred http: URL openConnection() value. This is a detail associated with my implementation of that handler. 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]