The JavaScript and Java (both client and server) are definitely production ready, based on the solid Jetty project, and already deployed all around the world from small to big sites.
The Python and Perl implementations are currently lacking active maintainers, and should not be considered production ready.
If you would like to contribute, join the mailing lists (see here) and drop a message.
The problem of putting Apache httpd in front of a Bayeux server is that it will not scale well for moderate to heavy loads.
The reason is that Apache httpd uses the thread-per-request model, which does not scale well in case of long polling connections.
Imagine 1000 Bayeux clients connected to Apache httpd; in such case, Apache httpd will have 1000 outstanding requests for the long polls only, plus any request that may be performed by the clients, so in total 1000+ threads concurrently active at any given time.
The burden of this model on memory and scheduling is quite high.
The asynchronous I/O features of a Bayeux server like Jetty allow to handle the same 1000 Bayeux clients with less than 10 concurrently active threads.
Assume 1000 Bayeux clients long polling every 20 seconds, and assume that each long poll request takes 100 ms to be processed, then we have
1000 long poll requests / 20 s = 50 requests/s 50 requests/s * 100 ms/request = 5 concurrent requests at any given time 5 concurrent requests at any given time => 5 threads active at any given time
Therefore 5 threads are needed by Jetty to handle 1000 Bayeux clients long polling where Apache httpd would need 1000 threads (and we assumed a large processing time of 100 ms/request whereas usual figures are way less than that).
If you have deployments where you expect 500+/1000+ Bayeux clients connected, then Jetty will scale a lot better than Apache httpd.
The problem is not Apache httpd, which is a great server; it is its thread-per-request model.
Therefore, any server using that model will suffer the same problems.
Here we mentioned Apache httpd because it is the most used solution used as front-end for web sites (and because it is a very frequently asked question).
The CometD project does not provide any direct IDE support, if you intend IDE plugins or similar components.
However, in the Primer it is explained how to setup a project with Maven, and the most used Java IDEs have a good support for Maven.
It is used by the Cometd Server implementation to detect multiple CometD clients from the same browser.
See here for a detailed explanation.
The command
ServletContext.getAttribute(Bayeux.ATTRIBUTE)
returns null when it is run before the CometD servlet has had the chance to put the Bayeux object into the servlet (application) context.
This page explains how to use the load-on-startup element in web.xml to specify the order of initialization of the CometD servlet and of your code.
You have a JavaScript CometD client that subscribed to a channel and while publishing to that channel, you notice that it receives the message twice.
This is very common when you have written a Bayeux service like this:
public class MyService extends BayeuxService
{
public MyService(Bayeux bayeux)
{
super(bayeux, "my-service");
subscribe("/my/channel", "processMyMessage");
}
public void processMyMessage(Client remote, Message message)
{
getBayeux().getChannel(message.getChannel(), false).publish(getClient(), message.getData(), null);
}
}
Let's put ourselves in the CometD Server's shoes for a moment: it sees 2 clients subscribed to channel "/my/channel": a remote client that subscribed via the JavaScript API, and a server-side client that is associated to the Bayeux service MyService and that in our example subscribed in MyService's constructor via the subscribe() call.
When the CometD server receives a message on channel "/my/channel" and notifies the clients, the remote client gets the first message, and MyService.processMyMessage() gets called.
But processMyMessage() publishes again on "/my/channel", so the remote clients gets the second message.
This raises the question of why processMyMessage() does not get called recursively ad infinitum ?
The CometD Server detects that the sending client (the first argument to the publish() call) is the client associated with the sending Bayeux service, and avoids the infinite recursion.
Had you put remote instead of getClient() as first argument of publish(), you would have infinitely recursed.
Solutions to this problem are:
processMyMessage() method uses a different channel to publish the dataThe most common solution is to use a service channel.