0

I've not been able to find a clear answer as to whether or not CometD's long polling mechanism uses a persistent connection, or disconnects and then reconnects after a message is pushed to it.

The reason this is important to me is that I am currently using a long polling push client which disconnects and reconnects after every message (or batch of messages) is sent from the server, and the reconnect time introduces random latency which I am looking to get rid of. I am assuming it does this for compatibility's sake, as it makes every "push" just look like a really long request/response, which should work on any and every browser.

So, does CometD's long polling use a persistent, long-lived http connection? If the answer is yes, is it conditional? That is, are there cases/browsers where it falls back to a "request/response/reconnect" per message sent?

joshv
  • 123
  • 4

1 Answers1

0

CometD long polling is using HTTP 1.1, and therefore persistent connections.

When CometD is used from a browser, the browser manages the connection pool and the HTTP protocol version, and CometD does not add any Connection header to close the connection after every message: all it is left to the browser, and my experience is that the long poll always stays on the same connection.

When the CometD Java client library is used, the same applies: Jetty's HTTP client manages the connection pool, defaults to HTTP 1.1 and keeps the connections open. The main difference with browsers is that Jetty HTTP client allows more than few (usually 6) connections per domain, so it is appropriate for load testing simulations. Check out the CometD performance report.

The updated CometD documentation can be found at http://docs.cometd.org.

It is wrong to say that "Long polling by definition does not use a persistent connection but reconnects". HTTP 1.1 is perfectly capable to send multiple long pollings over the same connection, and CometD does exactly that.

I am not aware of cases where clients like browsers fallback to open/request/response/close behaviour when using HTTP 1.1, unless this is explicitly requested by the application adding a Connection: close header to HTTP requests or responses (CometD does not do this).

With WebSocket, CometD opens 1 connection only, persistent, and all the messages are exchanged over that connection, until the application decides to close the connection by disconnecting the CometD client.

sbordet
  • 16,856
  • 1
  • 50
  • 45
  • thanks for the info. I deleted my answer for it was obviously wrong. – luksch May 02 '13 at 04:20
  • Actually this does appear to be incorrect. With the default configuration, connecting to tomcat, the long-polling transport polls for 40 seconds, and disconnects/reconnects if it does not receive a message. If it does receive a message, it disconnects and then reconnects again. Perhaps there's some means of configuring it to not behave this way, but by default it behaves in the canonical long-polling fashion. – joshv Sep 20 '13 at 20:10