[JBoss-dev] large remoting commit

[Tom E. <te...@e2...>]

I just completed a fairly large checkin to fix some remoting bugs (mostly
related to callbacks) and to add some new features, like being able to call
directly on local server instead of having to go through a transport layer
(which again is really mostly related to callbacks).

Everything is compiling and my remoting tests are working.  However, I am
unable to test all the other subprojects that might be affected.  Only code
changed outside of remoting and jmx was the InvokeRemoteInterceptor class in
the aspect package, which was minor.  Below is a list of all the changes I
have made.

-Tom


1.	Changed Client class to automatically generate a session id (which is a
GUID), so ensures it is unique (which is a requirement for the callbacks).
Since there are several places within the jmx package that seemed to be
setting the session id explicitly with values that need to be preserved, I
have added a getter/setter method for the session id and am calling the
setter before calling the invoke method on the client.

[Nathan, this will solve the problem you had to fix locally where you could
not make multiple calls to the socket server because the socket connection
had been closed.  The problem was when removing the callback handler on the
server side, it could not find the handler in the collection since the id
originally sent to the server was null, then was later populated with a real
id (in your test case being "1").]

2.	Added retry logic to the SocketClientInvoker to do one retry if socket
error trying to call on server.  Will disconnect the socket pool and retry
one time.  If still errors on second try, throws ConnectionFailedException
(as it did before).

3.	Changed the hashCode() method of InvokerLocator class to calculate the
hash code based on the locator's uri each time the hashCode() method is
called.  If variable for hash code set in the constructor, and create two
locators with the exact same String, the hash codes were different, thus
causing problem finding corresponding server invoker for the same client
invoker locator within the InvokerRegistry.

4.	Changed the Client to not take a session id as parameter to invocations.
It can still be explicitly set if need to be, but by default uses an
internally generated session id.

5.	Added constants to the InternalInvoker class for the internal methods
(i.e. addClientListner, removeClientListener, getCallbacks, handleCallbacks,
addListener, removeListener())

6.	Removed getId(), getCallbacks() and destroy() from the
InvokerCallbackHandler interface

7.	Changed the logic of the handling of InvokerCallbackHandlers to be
internal to the remoting framework.  This means that the subsystem handlers
will no longer be responsible for dealing with the handleCallback()
invocations and passing onto their callback handlers.  This is now done
internally by the ServerInvoker class.

8.	Changed the throws from Exception to HandleCallbackException in the
InvokerCallbackHandler's method handleCallback().


Remaining TODO's

1.	Need to make a fixed size list for storing the pull callbacks within
ServerInvokerCallbackHandler.  Currently this is just an ArrayList, so
possible to run out of memory if client never calls to get the callbacks.
2.	Need a way of realizing when client is dead, so can cleanup listener and
callbacks on the server side.
3.	What parameter(s) should the handleCallback() method of
InvokerCallbackHandler interface take?  Currently InvocationRequest, which
makes it very generic, but has no real meaning within callback context.