activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: ActiveMQ and Ajax
Date Tue, 18 Apr 2006 17:43:54 GMT
On 4/18/06, ssozonoff <serge@sozonoff.com> 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/

Mime
View raw message