Re: Controlling the object identification layer implementation

[Mark Brouwer <ma...@cheiron.org>]

Hi all,

Together with the "hook in PreferredClassProvider to determine class
boomerang" I think I come a long way towards being able to evolve
persistent services in time, as well as the ability to provide more
context information in case a client can't communicate with the server
due to maintenance/upgrades e.g..

However so far what I've been working on doesn't provide custom
exceptions that could be utilized by a client to react upon, i.e. to
distinguish between some failure cases for which the current set of
RemoteExceptions are not adequate IMHO.

Therefore I now came up with 2 custom RemoteExceptions that I need to
be able to develop client side failure handling logic, either internally
for usage by specialized proxies or directly for client side utilities.
As they are not specific to my Platform and could be seen as general I
believe they belong in the net.jini namespace (net.jini.jeri ?).
Attached you will find the code for them, although they are still in the
org.cheiron.seven.proxy namespace.

I decided to extend current subclasses of RemoteException and not to
introduce a new branch in the RemoteException hierarchy to be able to
play nice with current common failure handling logic out in the field.
Although I'm not sure whether this is the best thing to do, or whether I
took the right RemoteExceptions as a base class, any input is welcome.

First we have the OfflineException to be thrown by the RMI runtime when
a remote method invocation is performed for a service that is currently
off-line but denoted as a persistent service and as such is expected to
be on-line at some point in the future. The exception allows you to
specify the expected on-line date so client retry logic can take this
into account. Clients can utilize this exception to decide whether they
want to retry, if so when to perform the first retry. If you look for
example to a lookup server implementation, and there is a remote event
listener registered and the lookup server encounters this exception it
can check whether the on-line time is beyond the time the associated
lease expires, if this is the case it could drop the event registration
directly saving itself from performing retries and consuming resources
to keep the events in memory, persist them, etc. A transaction manager
service can utilize this exception to schedule any invocation on
TransactionParticipant and so on.

The other exception is the ObjectIncompatibleException that is thrown
when the specialized proxy has a particular version of mobile code that
is not compatible with the version of the remote object and that such an
invocation is not allowed to take place (due to an evolving codebase
e.g.). As part of the exception it is possible to pass in an object that
might allow the client to restore proper communication with the remote
object.

As an example, if a transaction manager service performs a call to
TransactionParticipant and ObjectIncompatibleException is thrown it
knows that the transaction participant proxy is no longer able to
communicate properly with its backend even while it is on-line,
therefore this is a definite failure. Although if
ObjectIncompatibleException.getProxy() returns an object that implements
TransactionParticipant it can utilize that proxy (likely after proxy
preparation) to continue its operations against the transaction participant.

I'm curious to find out about how others think of these 2 exceptions.
-- 
Mark