Forcing local class resolution (and avoiding the class server)

[Patrick Wright <pd...@gmail.com>]

Hi

In order to work around some occasional but troublesome issues where
our codebase servers become unavailable or unresponsive, we want to
experiment with having our service clients defer to local JARs for
loading service interfaces. Our current deploy configuration has all
clients deploying with the necessary classes anyway, so we feel we can
save ourselves the trouble of downloading JARs which won't change
between deploys in any case.

So--am now trying to figure out how this works. I haven't found an
authoritative guide, but what I have so far:
- every client should have jsk-platform and jsk-resources JARs in
their classpath
- every client should have the (otherwise downloaded) service
interface classes in their classpath

>From some old mail threads, it seemed that that should be enough, but
the service -dl.jars were still being pulled. I've tried adding a
PREFERRED.LIST to the first downloadable JAR in the codebase string,
using a very broad (package-wide) preferred name expression, but the
PreferredClassLoader is still picking them up via a download in the
clients.

Alternately, it seems that if I could force the codebase for my
service to be null, the PreferredClassLoader would look for the
classes locally, but I am not sure how to do that--the
NonActivatableServiceStarter, for example, doesn't allow a null export
codebase.

I'm sure I am just one step away from getting the configuration right,
and would appreciate some tips.


Thanks!
Patrick

Re: Forcing local class resolution (and avoiding the class server)

[Patrick Wright <pd...@gmail.com>]

Hi Peter

Thanks so much for your reply--the tip about disabling the Security
Manager turned out to work. By not setting a Security Manager, my
client is not loading all service interface and proxy implementation
classes locally, very cool.

Some quick notes to anyone who comes across this later:
- no changes required in the server (leaving remote codebase as-is)
- in client, jsk-platform, jsk-lib and jsk-resources all in classpath
- in client, reggie-dl as well as other support classes for remoting
in classpath
- in client, complete downloadable APIs in classpath, including remote
interfaces and any service proxy implementation classes as well, e.g.
complete content of -dl.jar files that would otherwise be delivered in
download
- in client, don't set a security manager

The nice thing about this solution is that by just choosing to enable
or disable the security manager we can enable remote code downloading
or disable it.

To track what is happening in the client, turn up JDK logging
- can put logging settings in a file, e.g. /tmp/logging.properties
- add command line flag -Djava.util.logging.file=/tmp/logging.properties
- enable logging at level FINEST for the loader classes
net.jini.loader.pref.PreferredClassLoader.level = FINEST
net.jini.loader.pref.PreferredClassLoader.preferred.level = FINEST
net.jini.loader.pref.PreferredClassLoader.exception.level = FINEST
net.jini.loader.pref.PreferredClassProvider.level = FINEST
net.jini.loader.level = FINEST
net.jini.url.level = FINEST

This produces a high volume of output, including on loading standard
JDK classes, so enable logging selectively.

I want to add, in case anyone thinks this loses one of the benefits of
Jini, namely dynamic code downloading, that in our case, we are trying
to work around infrastructure issues--stability and accessibility of
codebase servers--in an environment where we control the server and
client deploys completely. We don't have the time to invest in
improving availability for the codebase servers (which would be
another solution), so in our case this is a good alternative.

Thanks again, Peter. Saved me a lot of stress.

Cheers!
Patrick

Re: Forcing local class resolution (and avoiding the class server)

[Dennis Reedy <de...@gmail.com>]

Just for clarity's sake here...

We only need dynamic classloading if we dont have all classes in the  
classpath of all the participating JVMs here. If the setup described  
here results in everything being in the classpath, and the  
ClassLoaders that create the services do not return anything in their  
respective overloaded getURLs() implementation (codebase is null),  
then have we not achieved the same thing? That being no codebase  
annotation for classes?

On Oct 2, 2009, at 1051AM, Geoffrey Arnold wrote:

> Reading back over Peter's email, I believe that he was simply  
> reiterating that a client requires more than just the service's  
> interface when remote code downloading is disabled, thus you must  
> include the entire contents of the service-dl.jar in the client's  
> classpath.  While adding the entire server.jar would work, it's  
> overkill for Patrick's issue.
>
> On Oct 2, 2009, at 8:50 AM, Geoffrey Arnold wrote:
>
>>
>> On Oct 2, 2009, at 12:27 AM, Peter Jones wrote:
>>
>>> Just to be clear, you mean service proxy implementation classes  
>>> too, the entire contents of the services' -dl.jar files?  (Service  
>>> interfaces used by the client will typically be loaded locally  
>>> anyway.)
>>
>> It looks like in the case of the JSK, the service-dl.jars are just  
>> a subset of the service.jars.  What's the reasoning behind  
>> including the service-dl.jars in the client codebase if Patrick's  
>> already including the service.jars there?
>>
>> Thanks,
>> Geoff.
>

Re: Forcing local class resolution (and avoiding the class server)

[Geoffrey Arnold <ge...@geoffreyarnold.com>]

Reading back over Peter's email, I believe that he was simply  
reiterating that a client requires more than just the service's  
interface when remote code downloading is disabled, thus you must  
include the entire contents of the service-dl.jar in the client's  
classpath.  While adding the entire server.jar would work, it's  
overkill for Patrick's issue.

On Oct 2, 2009, at 8:50 AM, Geoffrey Arnold wrote:

>
> On Oct 2, 2009, at 12:27 AM, Peter Jones wrote:
>
>> Just to be clear, you mean service proxy implementation classes  
>> too, the entire contents of the services' -dl.jar files?  (Service  
>> interfaces used by the client will typically be loaded locally  
>> anyway.)
>
> It looks like in the case of the JSK, the service-dl.jars are just a  
> subset of the service.jars.  What's the reasoning behind including  
> the service-dl.jars in the client codebase if Patrick's already  
> including the service.jars there?
>
> Thanks,
> Geoff.

Re: Forcing local class resolution (and avoiding the class server)

[Geoffrey Arnold <ge...@geoffreyarnold.com>]

On Oct 2, 2009, at 12:27 AM, Peter Jones wrote:

> Just to be clear, you mean service proxy implementation classes too,  
> the entire contents of the services' -dl.jar files?  (Service  
> interfaces used by the client will typically be loaded locally  
> anyway.)

It looks like in the case of the JSK, the service-dl.jars are just a  
subset of the service.jars.  What's the reasoning behind including the  
service-dl.jars in the client codebase if Patrick's already including  
the service.jars there?

Thanks,
Geoff.

Re: Forcing local class resolution (and avoiding the class server)

[Peter Jones <pc...@roundroom.net>]

On Oct 1, 2009, at 3:44 PM, Patrick Wright wrote:

> Hi
>
> In order to work around some occasional but troublesome issues where
> our codebase servers become unavailable or unresponsive, we want to
> experiment with having our service clients defer to local JARs for
> loading service interfaces.

Just to be clear, you mean service proxy implementation classes too,  
the entire contents of the services' -dl.jar files?  (Service  
interfaces used by the client will typically be loaded locally anyway.)

> Our current deploy configuration has all
> clients deploying with the necessary classes anyway, so we feel we can
> save ourselves the trouble of downloading JARs which won't change
> between deploys in any case.
>
> So--am now trying to figure out how this works. I haven't found an
> authoritative guide, but what I have so far:
> - every client should have jsk-platform and jsk-resources JARs in
> their classpath
> - every client should have the (otherwise downloaded) service
> interface classes in their classpath

Again, you mean the service proxy implementation classes too, the - 
dl.jar files?

> From some old mail threads, it seemed that that should be enough, but
> the service -dl.jars were still being pulled. I've tried adding a
> PREFERRED.LIST to the first downloadable JAR in the codebase string,
> using a very broad (package-wide) preferred name expression, but the
> PreferredClassLoader is still picking them up via a download in the
> clients.
>
> Alternately, it seems that if I could force the codebase for my
> service to be null, the PreferredClassLoader would look for the
> classes locally, but I am not sure how to do that--the
> NonActivatableServiceStarter, for example, doesn't allow a null export
> codebase.

How about an empty string?

> I'm sure I am just one step away from getting the configuration right,
> and would appreciate some tips.

There are various ways to disable RMI class loading on the client, if  
that's what you want.  One way would be to not set a security manager,  
if the only reason you had been setting one was because RMI class  
loader providers require it (i.e. you're not loading untrusted code  
any other way).  Another would be to set an RMIClassLoader provider  
that ignores codebase annotation values (perhaps just forwarding to  
the default provider, accessible via  
RMIClassLoader.getDefaultProviderInstance, but with null codebase  
values).

-- Peter