CODEWITHSUNDEEP
asp.net-mvcjettycometd
Chris
Chris

Reputation: 741

Implementing Acknowledge-Extension for CometD in Jetty/ASP.NET

we're using CometD 2 to achieve the connection between a central data provider and several backends consuming the data. Up to now, when one of the backends fails briefly, all messages posted in the meantime are lost. Now we heard about the "Acknowledge Extension" for CometD. It is supposed to create a server-side list of messages and delivers them when one of the clients reports to be back online. Here are some questions:

1) Does this also work with several clients?

2) The documentation (http://cometd.org/documentation/2.x/cometd-ext/ack) says: "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." -> does this mean that in case my client doesn't restore within the maxInterval, the messages are lost anyway?

Hence, 2.1) What's the maximal maxInterval? Which consequences does it have to set it to a high value?

2.2) We'd need a secure mechanism for fail outs of at least a few minutes. Is this possible? Are there any alternatives?

3) Is it really only necessary to add the two extensions in both the client and cometD server? We're using Jetty for the server and .NET Oyatel for the client. Does anyone have some experiences with this?

I'm sorry for this bunch of questions, but unfortunately, the CometD project isn't really well documented. I really appreciate any answers.

Cheers, Chris

Upvotes: 1

Views: 428

Answers (1)

Inshallah
Inshallah

Reputation: 4814

1) Does this also work with several Clients

Yes, it does. There is one message queue allocated for each client (see AcknowledgedMessagesClientExtension).

2) does this mean that in case my client doesn't restore within the maxInterval, the messages are lost anyway?

Yes, it does. When the client can't reach the server for maxInterval milliseconds, the server will throw away all state associated with that client.

2.1) What's the maximal maxInterval? Which consequences does it have to set it to a high value?

maxInterval is a servlet parameter of the Cometd servlet. It is internally treated as a long value, so the maximal value for it is Long.MAX_VALUE.

Example configuration:

<init-param>
    <!-- The max period of time, in milliseconds, that the server will wait for
         a new long poll from a client before that client is considered invalid
         and is removed -->
    <param-name>maxInterval</param-name>
    <param-value>10000</param-value>
</init-param>

Setting it to a high value means that the server will wait longer before throwing away the state associated with a client (from the time the client stops contacting the server).

I see two problems with this. First, the memory requirements of the server will potentially be higher (which may also make denial of service easier). Second, the RemoveListener isn't called on the Server before the maxInterval expires, which may require you to implement additional logic that differentiates between "momentarily unreachable" and "disconnected".

2.2) We'd need a secure mechanism for fail outs of at least a few minutes. Is this possible? Are there any alternatives?

Yes, it is possible to configure the maxInterval to last for a few minutes.

An alternative would be to restore any server side state on every handshake. This can be achieved by adding a listener to "/meta/handshake" and publishing a message to a "/service/" channel (to make sure only the server receives the message), or by adding an additional property to the "ext" property of the handshake message. Be careful to let the client restore only valid state (sign it on the server if you must).

3) Is it really only necessary to add the two extensions in both the client and cometD server?

On the server it is sufficient to do something like:

bayeux.addExtension(new AcknowledgedMessagesExtension());

I don't know how you'd do it on Oyatel. In Javascript it suffices to simply include the extension (dojo.require or script include for jQuery).

When a client with the AckExtension connects to the server, a message similar to the following will be logged (from my Jetty console log):

[qtp959713667-32] INFO  org.cometd.server.ext.AcknowledgedMessagesExtension  - Enabled message acknowledgement for client 51vkuhps5qgsuaxhehzfg6yw92

Another note because it may not be obvious: the ack extension will only provide server to client delivery guarantee, not client to server. That is, when you publish a message from the client to the server, it may not reach the server and will be lost.

Once the message has made it to the server, the ack extension will ensure that all recipients connected at that time will receive the message (as long as they aren't unreachable for maxInterval milliseconds).

It is relatively straightforward to implement client-side retrying if you listen to notifications on "/meta/unsuccessful" and resend the message (the original message that failed is passed as message.request to the handler).

Upvotes: 1

Related Questions