Re: Another question about codebases and jar versions

Mark Brouwer wrote:
> Logan, Patrick wrote:
>> Or is there a conventional way to get a client with old objects to
>> fail and take some app-specific upgrade measures?
>
> Not that I'm aware of. But now that you ask for it, the same context
> information could be utilized to decide at the server side that it has
> no use to perform any remote method invocation from that proxy in the
> future and to throw an exception that would mark that proxy/service
> useless.
>
> Note however that all this requires a lot of sophistication at the
> backend to keep track of whether version upgrades are compatible and
> some good thinking of the developer, but there are cases where this
> might be worth it. In case of the typical grid application that runs for
> a few hours and is brought down it is probably of no use, but an
> environment where you have services running for months and for which you
> sometimes have to upgrade services (in a 'compatible' way) it might be
> beneficial.

There are a couple of interesting mechanisms that can be exploited to make
updates very mechanical.  One thing simple, is to start a new instance of the
service with a new codebase, and then just stop the old one.  For the general
case of random exports (endpoint created with port 0 specified, and IL Factory
not having a fixed Uuid), the client will experience a RemoteException on the
next call.  It can then take appropriate measures to establish contact with a
new service which will provide the appropriate codebase.  This is probably the
most straight forward way to "change codebases" or "upgrade code".

The primary issue, is how much of the application is downloaded code and how
much of it is in the application class path (client or service).  Through the
application of appropriate classloader hierarchies, you can also have a layer
which watches for changes in codebases, and creates a new classloader to cause
the new codebase to be established.

Object migrations have to be considered so that remaining live objects using the
old codebase have some form of appropriate compatibility (whatever is
appropriate) with the new codebase(s).

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]