Skip navigation.

CometD 2 Strict Message Ordering

CometD 2 Strict Message Ordering

CometD does not enforce, by default, a strict order on message delivery. The reason is that there are (normally) two communication conducts between client and server: the meta connect conduct and the current request conduct (originated, for example, by a publish() performed by the client).
If the server receives two messages in different times for a client - say message1 and message2, it is possible that message1 is included in the response of a meta connect, but message2 is included in the response of a current request.
Because the messages are delivered on two different and independent communication conducts, it is possible that message2 arrives to the client before message1, for example because the thread scheduling on the server favored message2 or because the TCP communication for message1 was somehow slowed down (not to mention that browsers could as well be source of uncertainty).

CometD allows to enforce strict message ordering in two ways: using the acknowledge extension (which also provides delivery guarantee), or by specifying the long-polling.json.metaConnectDeliverOnly parameter for the long-polling server transport or, since CometD 2.4.0, the ws.metaConnectDeliverOnly parameter for the websocket server transport (see the configuration options).

The websocket transport enforces strict message ordering by returning messages via the the meta connect response instead of the current request, even if there is only one conduct.

The callback-polling server transport always enforce strict message ordering (and it is not possible to disable it).

When strict message ordering is enabled, all messages will be delivered via the meta connect response. In the example above, message1 will be delivered to the client, and message2 will wait on the server until another long poll is issued by the client (which happens immediately after message1 has been received).
It is clear that strict message ordering comes at the small price of slightly increased latencies (message2 has to wait the next long poll before being delivered), and slightly more activity for the server (since meta connects will be resumed more frequently than normal).