Ron wrote : | I. The central change has been to push callbacks back down into the Remoting layer. In particular, where on HEAD ServerConsumerEndpoint.Deliverer gets the ServerInvokerCallbackHandler's Client and delivers messages to the client side using Client.invoke(), on the HTTP branch it calls ServerInvokerCallbackHandler.handleCallback(). As a result, Messaging can take advantage of Remoting's variety of callback options. | That's good. Using the callback abstraction correctly is the right way to go. Ron wrote : | (a) push callbacks: a Connector (complete with ServerSocket) is created on the client side, and calling ServerInvokerCallbackHandler.handleCallback() causes an invocation to be made from server side to client side. | Not an option. Or not anymore, at this stage. The socket transport will be rendered irrelevant soon, one way or another, so we don't want to waste any more time on that. See http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979236 If it currently works with the socket transport, that's good, but we need to get the multiplex transport working ASAP. Ron wrote : | (b) poll callbacks: calling ServerInvokerCallbackHandler.handleCallback() causes the callback to be stored (possibly on disk) until the client side polls for pending callbacks. No ServerSocket is created on the client side. | Yes, but no disk. For non persistent messages we don't care anyway, and for persistent messages, they're already stored by the channel, so we're covered. Disk at that level can only slow down things. Obviously this can be configured. Right? Ron wrote : | In order to replace invocations with callbacks, a callback acknowledgement facility was added to Remoting. When ServerConsumerEndpoint.Deliverer sends a callback, it also stores the callback in a pendingCallbacks HashSet, from which it is removed upon acknowledgement. | According to Tim, we don't need that. Sending the message from server to client should be fully asynchronous, so we don't need acknowledgments. More on this here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=92954. Care to comment, Tim? Ron wrote : | II. The new Messaging specific serialization structure interacts with callbacks to generate some added complexity in JMSWireFormat. Because of the two forms of callbacks, there are two delivery modes for callbacks, and each has to be unwound to expose the ClientDelivery. For example, callback polling delivers an ArrayList of pending callbacks, and each ClientDelivery in the list has to be processed separately. There's also another related issue. In pull or poll mode, callbacks are stored on the server, which might involve writing them to secondary storage. Currently, the application's designated serialization type determines how the callbacks are transferred to and from disk, but MessagingObjectInputStream and MessagingObjectOutputStream are derived from the standard java classes, which can't handle Messaging non-Serializable messages. For now I've worked around the problem in my local version of Remoting, but the problem still needs to be resolved. Is there any reason the Messaging can't use JBoss Serialization? | You lost me here. I'll look tomorrow at the code. Ron wrote : | IV. Right now the HTTP branch runs with my own private version of Remoting. I've checked in a copy of jboss-remoting.jar in the lib directory. | Good. As soon as we agree on changes, I would asume that Tom can release an Alpha (or Beta) so we can pick the jar from repository. Ron wrote : | V. It's 4am and right now it looks like everything's broken. Great. Well, it WAS working. | It will work again :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979243#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...