I'm using a library whereby I can fire off a query with an attached listener onto it and receive event updates through the listener's method.
How can I be sending these updates to the client whenever there's a new event?
I can only think of having threads running in the background and store these events onto a queue and perform long polling with AJAX to receive these updates.
Is there anyway to go about it where I can get every single event onto the client the second it happens?
Is ActiveMQ something worth looking into? I'm asking because I'm not sure whether I need to.
Your help is appreciated.
Andreas Markitanis wrote:How can I be sending these updates to the client whenever there's a new event?
You can't. HTTP is a stateless, request-repsonse protocol. How would you even know whether the client is still even looking at your pages? They're probably off updating Facebook or watching YouTube videos. How would you even know how to find the client?
The only possibility is a technology such as comet that holds open a connection for long periods. Most people wouldn't touch it with a ten foot pole. Myself included.
Your best bet would be to look beyond HTTP. Perhaps you need a fat client downloaded via Java Web Start. Or maybe an Applet.
If HTTP is my only choice, would background threads do? Storing the events in some sort of Thread safe container and sending to the client the latest events by AJAX polling?
Bear Bibeault wrote:Connections are expensive. If you only expect a handful of users, it may be OK. But it does not scale well.
Not necessarily true. It all comes down to the way you handle your HTTP requests. Use blocking-IO and you'll hit a bottleneck pretty soon.
On the other hand, using non-blocking IO i.e Tomcat or Jetty with asynchronous requests, has the capability to scale well. You can then use long polling techniques to mimic a constantly open connection to the server. Push data as soon as it comes in, and then after you process the response immediately fire a new AJAX request.
Bear Bibeault wrote:That was my point exactly. Polling allows for short requests to update status. Long-open connections, not so much.
Please be sure to read a post in its entirety before posting.
That's was not my point though.
My point is that you can use polling for delayed responses (i.e long-open connections) as well, and it will scale, given that your server architecture supports non blocking IO.