Home

News: Developing with Comet and Java

  1. Developing with Comet and Java (5 messages)

    Explore the different implementations of developing with Comet. See how popular Java Web servers like Jetty and Tomcat have enabled Comet applications, and learn how to program with each server. And finally, learn about the standardization proposals for Comet in Java that are part of the upcoming Servlet 3.0 and JavaEE 6 specifications.
  2. CometD & DWR[ Go to top ]

    Dojo offers a nice abstraction on the Comet side called CometD (http://cometdproject.dojotoolkit.org/). DWR's comet implementation is also very usefull as it chooses the ideal implementation depending on the capabilities of the web server (http://directwebremoting.org/dwr/reverse-ajax/index.html).
  3. "At this point you might be thinking that there is a major problem with both long polling and streaming. The request stays alive on the server for a long time. This breaks the one thread per request model, as the thread for a request never gets freed up. Even worse, this thread will be sitting idle until there is data to send back. This definitely will not scale. Luckily, modern Java Web servers have ways of addressing this." I've read this again again but there is no empirical fact, threads are cheap, basically a thread is a piece of memory and memory is cheap and modern thread schedulers can handle thousands of threads with no problem and almost no latency when switching between alive threads (even lower if the threads are idle the typical scenario in a long polling application). You have many reasons to upgrade to a modern application server, but in my opinion this is not the best one. More about this.
  4. "At this point you might be thinking that there is a major problem with both long polling and streaming. The request stays alive on the server for a long time. This breaks the one thread per request model, as the thread for a request never gets freed up. Even worse, this thread will be sitting idle until there is data to send back. This definitely will not scale. Luckily, modern Java Web servers have ways of addressing this."

    I've read this again again but there is no empirical fact, threads are cheap, basically a thread is a piece of memory and memory is cheap and modern thread schedulers can handle thousands of threads with no problem and almost no latency when switching between alive threads (even lower if the threads are idle the typical scenario in a long polling application).

    You have many reasons to upgrade to a modern application server, but in my opinion this is not the best one.

    More about this.
    Jose, I agree. Async HTTP is a corner case. I get a little nervous with people making such a big deal out of Async HTTP when the use case for it is < 1% of applications basically because it would greatly increase the complexity of your application. Still, it *IS* a cool feature ;-) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  5. I want to clarify something, my criticism is to the claim "many threads do not scale", I'm not talking about Comet, in my opinion Comet is going to be a basic piece of many web applications and web sites because basically Comet (polling or long polling) = Real Time Web. Almost any web which frequently and randomly changes, for instance this site, can benefit from Comet (polling, long polling etc are details). In the future asynchronous requests (managed by asynchronous servlets) may be the de facto standard for Comet (long polling) because long polling is by nature event based and any NIO dispatcher gives turn to the user code in an event based form, this does not have very much to do with scaling. The problem with a NIO approach for Comet is NIO dispatcher delegates the control of the dispatcher thread to the user code, user code can abuse or stall a NIO thread (of course a good developer will execute a small chunk of processing to give back the thread as soon as possible). I think the best is to have both options for long polling (server point of view): 1) Synchronous long polling: The thread is retained until something in the server occurs and need to be notified to the client. Uses a thread by user (client) waiting for notifications. Thread abuse when executing user code is not a problem because the thread is a normal thread and only associated to the user, the thread scheduler of the kernel can transparently reclaim (stop) the thread to give turn to other threads. This approach works in any servlet container. Disadvantage: any thread need a stack, stack size must be tuned to save memory because this approach is memory intensive. 2) Asynchronous long polling: Using NIO or similar asynchronous technology present in the servlet container. Only the request is hold not the thread. In this mode the developer must be careful to avoid thread abuse because the thread used to execute user code is a "core thread" of the NIO engine used to dispatch to other users simulating a thread scheduler. Advantage: may need less memory. In my opinion both approaches have nothing to do with scalability. I'm not including memory, anyway in my opinion memory is not a problem in synchronous long polling, because the number of stacks that any average system can hold in memory exceeds by far the number of (concurrent) users the system can manage in a real world application. The synchronous approach is already supported by my web framework (ItsNat), the second I expect to be implemented in a short future. Both approaches can be implemented in any Java web framework.
  6. I want to clarify something, my criticism is to the claim "many threads do not scale", I'm not talking about Comet, in my opinion Comet is going to be a basic piece of many web applications and web sites because basically Comet (polling or long polling) = Real Time Web.
    I'm also not for COMET. There's really no reason an AJAX client can't block on an HTTP GET or POST waiting for events. You're just bastardizing the HTTP protocol by using it solely as a connection establishment mechanism for little performance gain. You also require extra javascript code to be downloaded, cached, maintained, and interpretted by your client. The less moving parts, the better.