"ovidiu wrote : | "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. | | | The polling style of callbacks will work just as well with the socket transport, which as I mention on http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979219 is an alternative to the multiplex transport. "ovidiu" wrote : | 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? | Actually, Tom wrote a "callback store" which blocks instead of writing to disk when it's running out of heap. I think that was done at Tim's request. It can be specified with the Connector configuration "ovidiu" wrote : | | 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. | The first real problem I ran up against in Messaging was that sometimes ServerConsumerEndpoint.stop() would return before the client side had a chance to acknowledge all of its delivered messages. I put in acknowledgements to prevent that problem. Now, stop() waits until all outstanding deliveries have been handed over to the MessageCallbackHandler. This duplicates the earlier behavior when callbacks were handled explicitly by Messaging. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979285#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...