On 4/18/06, ssozonoff <[EMAIL PROTECTED]> wrote: > > Hi James, > > I have been looking at the ActiveMQ Ajax code and docs which is some what > similar to what we are trying to achieve. I have a question. > > 1. I read your arguments for not doing HTTP push. How do you think your > current Ajax polling implementation versus a push based solution scales?
Incidentally the long-poll approach is often labelled "Comet" these days. I'll use that term answering as its a bit less typing... On the client side the Comet approach is a little more lightweight and less likely to fail - as some browsers are not really ready for an infinite JavaScript page with pushlets, so they can die/use up RAM badly. Also the Comet approach deals with dropped connections much neater (as the Ajax client can easily make another long poll if one fails due to, say, some firewall/proxy killing a socket. But really both approaches are quite similar from the browsers perspective - they both use a single socket (with HTTP keepalive); the main difference is rather than streaming JavaScript code with pushlets you can send JavaScript, JSON or XML or other content types using HTTP encoding when using Comet. So rather than tying the HTML page to the distribution technology with pushlets (having to understand the JavaScript functions, variables and objects available on the page on the server side to be able to 'send a message') you can use a looser coupling approach - sending XML or JSON object trees. e.g. many pages could subscribe to the same events and bind the message to the page locally, rather than a publisher being required for every page, knowing the exact JavaScript code to publish. On the server side they are similar; they both use a socket per connected client. The main difference is that the Ajax support in ActiveMQ (using Jetty 6's continuations feature) means we can suspend the servlet to free up the thread when there is no message available for a client; whereas pushlet approaches tend to use up a blocked BIO servlet. Also with Comet we can use the long poll as a keep-alive so that we use threads more efficiently and evict unactive sessions more aggresively. So in summary; the main issue with scalability is the same in both approaches; to have enough boxes dealing with enough sockets to handle your user load. However with the combination of ActiveMQ & Jetty 6 we can both use NIO and threads more efficiently to scale better. Certainly the Ajax approach is a bit more flexible, is much looser coupled and uses much less threads and is a bit more resilitent to network errors and deals more gracefully with failures (e.g. servers temporariy rejecting access when too many clients are online) -- James ------- http://radio.weblogs.com/0112098/
