cometD Acknowledged Message Extension

by Greg WilkinsMarch 27th, 2009

With the release of the latest cometd-jetty in acknowledged messages is now provided in jetty server and in the dojo and jQuery cometD clients, providing more reliable message delivery and ordering.

The initial concept of cometD was to provide “web quality” communications between the server and the browser, i.e. it was not intended to provide 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 mission critical applications. 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.


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 for clients that 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 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 client-side for Dojo is provided by dojox/cometd/ack.js which was released in Dojo 1.3.0b2 (but can also be applied by patch to Dojo 1.2.x). To enable the client-side, the dojo.require mechanism is used:


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

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

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"&gt;&lt;/script>


To enable message acknowledgement, both the client and server must indicate that they support message acknowledgement. This is negotiated during the 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 ack ID 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.


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 browser instances to initialize a chat session, then briefly disconnect one browser from the network (the work offline option will do this). While one browser is disconnected, type a chat message 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 an excess of maxInterval (the default is 10s), then the client will be timed out and the unacknowledged queue is discarded.

Comments are closed.

Copyright 2015 Comet Daily, LLC. All Rights Reserved