Re: Another question about codebases and jar versions

Gregg Wonderly wrote:
> 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".
>

Yep - that's one way but handling all those exceptions has been noted to
be a little programmer unfriendly in some quarters.  Think we can do
better than this - just need to prototype it out.....

> 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]
>

--------------------------------------------------------------------------
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]