Cometd Acknowledged Message Extension

With the release of the latest cometd-jetty in Jetty 6.1.15, the oft requested feature of reliable message delivery is now supported by the Acknowledged Message Extension in the jetty server and in the dojo and jquery clients.

The initial concept of cometd was to provide "web quality" communications between the server and the browser, ie it was not intended to provide a reliable, transactional and/or atomic delivery of messages. The premise was that if your network failed, then messages can be lost. While this is sufficient for many applications, it is not sufficient for many others. Luckily, the Bayeux protocol implemented by cometd provides for an extension mechanism, which cometd-jetty, cometd-dojox and cometd-jquery have now used to provide an acknowledged message mechanism for reliable message delivery.

Server side

To enable cometd-jetty support for acknowledged messages, the extension must be added to the bayeux instance during initialization:

  bayeux.addExtension(new AcknowledgedMessagesExtension());

The AcknowledgedMessageExtension is a per server extension that monitors handshakes from new clients, looking to see if they also support the acknowledged message extension and then adds the AcknowledgedMessagesClientExtension to each client on handshake.

Once added to a client, the AcknowledgedMessagesClientExtension prevents messages being delivered on any request other than a /meta/connect so to prevent the possibility of out of order delivery. The extension also maintains a list of unacked messages and intercepts the /meta/connect traffic to insert and check ack IDs.

Dojox Client

The clients side for dojo is provided by dojox/cometd/ack.js which was released in dojo 1.3.0b2 (but can also be applied to dojo 1.2.x). To enable client side the dojo requires mechanism is used:

  dojo.require("dojox.cometd.ack");

This is sufficient to enable the extension, however it may then be programmatically disable/enabled before initialization by setting the ackEnabled boolean field:

  dojox.cometd.ackEnabled = (dojo.query("#ackInit").attr("checked") == "true");
  dojox.cometd.init(cometdUrl);

JQuery Client

The client side for jquery is enabled by including the jquery.cometd-ack.js file (bundled with jetty 6.1.15):

  <script type="text/javascript" src="../../jquery/jquery.cometd.js"></script>

Details

In order to enable message acknowledgement, both client and server must indicate that they support message acknowledgement. This is negotiated during handshake. On handshake, the client sends "ext":{"ack": "true"} to indicate that it supports message acknowledgement. If the server also supports message acknowledgment, it likewise replies with "ext":{"ack": "true"}.

The extension does not insert ack IDs to every message, as this would impose a significant burden on the server for messages sent to multiple clients (which would need to be reserialized to json for each client). Instead the ack id is inserted in the ext field of the /meta/connect messages that are associated with message delivery. Each /meta/connect request contains the ack ID of the last received ack response: "ext":{"ack": 42}. Similarly, each ack response contains an ext ack ID that uniquely identifies the batch of responses sent.

If a /meta/connect message is received with an ackId lower that any unacknowledged messages held by the extension, then these messages are requeued prior to any more recently queued messages and the /meta/connect response sent with a new ack ID.

Demo

There is an example of acknowledged messages in the dojox chat demo that comes bundled with cometd-jetty.

To run the demo, download the Jetty implementation of cometd, then:

  cd contrib/cometd/demo
  mvn jetty:run

Point your browser to http://localhost:8080/examples/chat/ and make sure to check "Enable reliable messaging?".

Use two different browsers instances to initial a chat session, then briefly disconnect one browser from the network (work offline option will do this). While one browser is disconnected, type some chat in the other browser and this will be received when the disconnected browser is reconnected to the network.

Note that if the disconnected browser is disconnected for in excess of maxInterval (default 10s), then the client will be timed out and the unacknowledged queue discarded.