Cometd is a scalable HTTP-based event routing bus that uses a push technology pattern known as Comet. The term ‘Comet’ was coined by Alex Russell in his post ‘Comet: Low Latency Data for the Browser‘. Cometd consists of a protocol spec called Bayeux, javacript libraries (dojo toolkit), and an event server.

Jetty now has just an implementation of the cometd event server that
uses the Continuation mechanism for asynchronous servlets.

Jetty already has comet implementations for DWR and activemq, but both of these use custom protocols which can lead to interoperability problems that cometd intends to solve.

Because browsers commonly permit only two connections to each server, it is not possible for a web page to use more than one Ajax library that is using comet techniques. The intent of cometd is to define a common protocol that can be shared between libraries and thus
encourage interoperability.

Cometd provides a two multi-channel communications paradigm that allows asynchronous message delivery from server to client as well as client to server. The multi-channel nature of the protocol, will eventually allow a single comet connections to be shared between multiple Ajax toolkits

Jetty has implemented the server side of this protocol, which will allow it to be used with whatever client side implementations emerge (currently only dojo, but I plan to port activemq once it is stable). However to achieve true
interoperability, we will need to develop standardized APIs on both the client and server side. Having standard protocol is a start on this, as it defines the capabilities that will need to be expressed in the APIs

Cometd with Jetty

17 thoughts on “Cometd with Jetty

  • August 7, 2006 at 3:03 pm
    Permalink

    I was thrilled to see Cometd being implemented in Jetty.  I’ll be even more thrilled once it’s wired up to a JMS broker (like ActiveMQ).

  • October 14, 2006 at 1:46 pm
    Permalink

    Hi,

    Will it support Reverse Ajax as it is there in DWR?

    Is there  any working example where the server is pushing data to the client?

  • November 21, 2006 at 7:59 pm
    Permalink

    Last night I put together a little Comet hello world using org.mortbay.cometd (Jetty) as the server and dojo.io.cometd as the client. Sorry for the shameless plug, but if you’re interested, please check it out.

  • January 2, 2007 at 9:21 pm
    Permalink

    We are using cometd on a project at my company and have run into an issue that we could really use some help with.

    We are using JBoss with Tomcat 5.5 and I was hoping to keep things that way, so I put the cometd and jetty jar files into my webapp.  What appears to be happening is that when two or more clients are connected through the cometd servlet (using dojo.io library), only the last client within the subscribers list will actually have a message delivered to them.  After some debugging, it looks like only that last client actually has a Continuation.  Is this possibly a by-product of using Tomcat instead of Jetty, or do you think there might be something else going on?

  • January 6, 2007 at 8:44 am
    Permalink

    Almost certainly something is wrong….

    probably best if you send an email to the cometd dev list and we can help you there .  Difficult to have a conversation in blog comments

  • August 15, 2007 at 2:08 pm
    Permalink

    Is there any concrete example of working out reverse ajax (dwr2) with Jetty ? i could not find any !!!

    I have reverse ajax application but it is eating the memory like hell. I think by using Jetty the problem might disappear.

  • June 2, 2009 at 9:56 am
    Permalink

    Hello,
    Is cometd can run on websphere app server? glassfish?
    Thanks a lot.
    Cheers.

  • June 2, 2009 at 3:30 pm
    Permalink

    cometd should run on any app server, but it will scale best on jetty or a servlet 3.0 container.

  • June 3, 2009 at 1:30 pm
    Permalink

    Hello greg,
    Have encounter grizzly? what is the advantage and disadvantage of grizzly over cometd?
    Thanks a lot.

  • June 4, 2009 at 6:28 am
    Permalink

    Eman,
    I’ve not looked at grizzly for a while, but it’s intent was to be a general purpose NIO layer which can be used for many purposes, one of which is extending async behaviour into a servlet container.
    Jetty has a specific purpose NIO layer – it is there to do HTTP and only HTTP. As such I would expect that we could optimize it better and the direct benchmarks that I have seen (albeit some time ago) did show that we were significantly faster than grizzly.

  • June 16, 2009 at 12:00 am
    Permalink

    Hello greg,
    I was assigned to different task for now but I will be doing comet hopefully by the end of this month. By then I should be updating you soon.
    Thanks a lot.
    Cheers.

  • July 16, 2009 at 10:25 am
    Permalink

    Hello greg,
    Im doing comet now and I cannot run my comet enable app using wicket. Also i already read the forums here http://www.nabble.com/-Announce–wicketstuff-push-ported-to-use-wicket-1.4-jetty-6.1.14-to20914051.html specific to UI framework im using and it seems that can only work on jetty server. I also check the glassfish doc http://docs.sun.com/app/docs/doc/820-4496/ghgxn?a=view for suport on comet, i just found this docs and done some integration but i cannot make it work.
    Is there a way to do this in glassfish?
    Thanks a lot.
    Cheers.

  • Pingback:URL

Comments are closed.