Search code examples
tomcatjettycometd

Cometd on Tomcat

I am trying to deploy cometd (3.0.1) on tomcat (7.0.50). Previously I was using cometd (3.0.1) with jetty 9.2.2.

I can see cometd is dependent on some jetty library as mentioned here , but what are these dependencies?

Also I was following this post, and was confused with "concurrent async writes".

It is said that "CometD 3 has been modified to avoid concurrent async writes, which are allowed by the specification but that Tomcat rejects."

Does it mean something related to this "true". Should I make it false? Cometd FAQ's

Can someone help?

Thanks

EDIT
With jetty I am using following jars. Which of them can I remove if I am using tomcat.

jetty-client.jar,
jetty-continuation.jar,
jetty-http.jar,
jetty-io.jar,
jetty-jmx.jar,
jetty-security.jar,
jetty-servlet.jar,
jetty-servlets.jar,
jetty-server.jar,
jetty-util.jar,
jetty-util-ajax.jar,
jetty-webapp.jar,
jetty-deploy.jar,
jetty-xml.jar,
jetty-annotations.jar
Solution

  • CometD 3 is fully portable across Servlet containers, so it will work in Tomcat as well as in Jetty, modulo bugs in either container.

    The Jetty libraries CometD depends on are fully portable too (being just utility libraries). The exact dependencies depend on what feature of CometD you want. The minimal set is:

    • jetty-util
    • jetty-util-ajax

    However, it is strongly recommended that you use a dependency tool like Maven and forget about manually satisfying the dependencies for your project.

    CometD provides the primer and tutorials to get you started.

    The JSR 356 WebSocket standard provides a way to send WebSocket messages using asynchronous APIs.

    While the Jetty implementation of JSR 356 allows concurrent usage of those APIs, the Tomcat implementation does not. Since concurrent usage of those APIs is common in CometD, it turned out that CometD was working fine in Jetty, but not in Tomcat. Therefore, CometD was modified to avoid concurrent writes for the sake of portability across containers, since the JSR 356 specification was too vague about the exact semantic of the APIs.

    UPDATE: There are 2 ways of handling concurrent usage of the WebSocket APIs.

    The first is that the WebSocket implementation takes care of the concurrency; applications like CometD can call the WebSocket APIs concurrently, and internally the implementation has synchronized blocks, or queueing or whatever other solution applies to make sure the messages are not corrupted. Two threads will be able to call the WebSocket APIs concurrently, but eventually the message processing will be serialized and the messages sent one after the other.

    The second is to have the application (CometD) take care of the concurrency and apply synchronized blocks, or queueing, etc. before calling the WebSocket APIs.

    Jetty implemented the first solution, Tomcat did not. Because of this, CometD has been modified to implement the second solution.

    This means that you can use the CometD API concurrently (which eventually will end up calling the WebSocket APIs) without worry, because the concurrency is taken care of properly by CometD, in order to be portable across Servlet Containers and their WebSocket implementations.

    WebSocket async writes have nothing to do with <async-supported> in web.xml, which you must have enabled anyway, as specified in the documentation.