Callback acknowledgements

[ron_sigal]

Integrating the Remoting http transport into JBossMessaging has uncovered a requirement in Messaging for Remoting callbacks to generate acknowledgements, and we're soliciting comments on the nature of these acknowledgements.

Messaging will be using push callbacks, or, in the case of unidirectional transports (e.g., socket, http), "pseudo-push" or "poll" callbacks, in which an org.jboss.remoting.callback.CallbackPoller polls the server for callbacks and then pushes them to an InvokerCallbackHandler. The CallbackPoller acts in place of the server side ServerInvokerCallbackHandler, which handles pure push callbacks. The requirement in Messaging is to get an acknowledgement when InvokerCallbackHandler.handleCallback() has returned. This acknowledgement can be sent by CallbackPoller or ServerInvokerCallbackHandler in the cases of pseudo-push and push callbacks, respectively.

Beyond these requirements from Messaging, we're looking for the right set of acknowledgement concepts and the right set of API changes to implement them. The main question is: What does an acknowledgement mean? Messaging needs an acknowledgement that indicates that the callback has been transferred to the client. Now, it seems desirable for the implementation of a CallbackListener interface to be independent of how callbacks are configured, which raises the question of how pull callbacks should be acknowledged. An acknowledgement sent just before Client.getCallbacks() returns would be an approximation to indicating that the callback has been passed to the client. The advantage of sending acknowledgements from Client, CallbackPoller, and ServerInvokerCallbackHandler is that they are all handled inside of Remoting and require no application level action on the client side.

However, the pull callback acknowledgement is liable to spawn race conditions. A stronger kind of acknowledgement would be for the application to call a new Client.acknowledgeCallback() method. It requires an API change, but it seems to offer a more reliable and conclusive acknowledgement. Moreover, this same form of acknowledgement would be available for push and poll callbacks as well.

One solution would be to have two levels of acknowledgements: Remoting and application. Either or both could be requested by the CallbackListener.

Comments?

[timfox]

Messaging has no requirement to get acknowledgements that messages have been delivered to the client side.

(The HTTP transport might use acknowledgments internally to manage it's buffer -although I am not sure that is the best way to do it- but that's an implementation detail of the HTTP transport).

We want to be able to send messages asynchronously from the server to the client (i.e. don't wait for a response).

This is part of what I have been going on about for a while (bi directional asynchronous transport).

[ron_sigal]

"timfox" wrote:
Messaging has no requirement to get acknowledgements that messages have been delivered to the client side.

There may be no formal messaging requirement for acknowledgements, but it seems to derive from the current implementation. Currently, messaging delivers messages from the server to the client by the synchronous Remoting Client.invoke() method, and ServerConsumerEndpoint.stop() waits for the completion of the call to invoke():

 this.executor.execute(new Deliverer());
 //Now wait for it to execute
 Future result = new Future();
 this.executor.execute(new Waiter(result));
 result.getResult();

Now, if you want to have the client side poll for messages, then the completion of the Deliverer only means that the messages have been handed over to Remoting. My understanding is that you want all messages that have left ServerConsumerEndpoint to be delivered to MessageCallbackHandler before concluding ServerConsumerEndpoint.stop(), and the only way I can see to get that information is to get an acknowledgement from the client side. Let me know if I've misinterpreted something.

(The HTTP transport might use acknowledgments internally to manage it's buffer -although I am not sure that is the best way to do it- but that's an implementation detail of the HTTP transport).

My understanding is that this issue isn't specific to the HTTP transport. Messaging's current use of the socket transport involves a callback Remoting Client on the server side contacting a ServerSocket on the client side. I thought you wanted to avoid the client side ServerSocket in all cases. Or does this restriction apply only to the HTTP transport?