This is really great stuff Tom. You guys do great work. Some other things that need to get done in the future:
1. Have SOAP transport work as a servlet within web-container 2. Develop a broadcast abstraction so that we can integrate multicast libraries like JavaGroups. It would be cool if you could still handle the classloading on received multicast messages. 3. Setup an initialization process the first time a client connects to a URI in which the client asks the server for any transport interceptors or other services like the DTM that must be installed. This will alleviate some of the initialization mess that is on the client right now 4. Investigate on whether the same Interceptor and Invocation class can be used for Remoting, AOP/EJB. This may simplify some code and maybe avoid some unnecessary object creations. I'll probably be looking into 3 and 4. I'll run the changes by you before I commit anything to make sure I'm not interfering with any of your plans. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Tom > Elrod > Sent: Wednesday, June 18, 2003 12:11 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] large remoting commit > > > 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 ------------------------------------------------------- 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
