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. ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
