In recent discussions here and elsewhere, it’s become apparent to me that people aren’t aware of some fundamentals of how Jini lookup behaves and some utilities one might typically use to avoid rather obvious pitfalls.
When one performs a successful lookup, a proxy is returned. Because the proxy is a serialized Java construct we may need to download some code (if the proxy is a JERI reflective proxy, there’s no code to download for example). For the sake of this discussion, let’s assume we do need to pull some code down.
What happens under the covers, is we check to see if we already have a classloader for the codebase associated with the proxy. If we do, there’s no need to download the code, we already have what we need. Otherwise we must instantiate a new PreferredClassLoader and download the necessary bytecode.
And for as long as we have a reference to the proxy, the classloader will exist and thus any further code-downloading will be driven by the usual Java rules for classloading.
Obviously if we release our references to the proxy, it’s classes are no longer referenced and the classloader might well be gc’d as it should be.
Potentially, that means that everytime we do a lookup/use proxy/release cycle we could end up having to do code-downloading. Fortunately, there’s a utility available which avoids that issue and, as a side benefit keep’s it’s list of services up-to-date - it’s called LookupCache and can be created via ServiceDiscoveryManager.
Rather than do a direct lookup, we construct a LookupCache with the details of the kind of service we’re interested in and leave it to populate itself appropriately which includes handling the code-downloading aspect. All we then have to do is query the cache. And because the service proxies are now cached we are assured of not needing to repeatedly free and re-instantiate classloaders and incur the overhead of un-necessary code-downloading.
Entries (RSS)