So the main question I can't help think about is.. scalability. If I have potentially millions of users all hitting my server farm, they are all keeping long-lived connections open. As far as I know, this is a very resource intensive process.. something on the order of a couple 1000 connections tops, per server.. if that. So using something like Comet would mean, unless things have changed, I would probably need hundreds of servers to handle a large load of clients hitting my site because of the limited threads each server could handle to keep the connections open.
The project I am working on has been considering a "push" model, but our thought was having the consumer of our REST api pass in one (or more) methods for which the REST API could push back data. For example, since most consumers of our API will be from web servers that would render the UI using the REST API responses, they could pass us there URL to there server, and when a long task was ready to push more data, using the URL supplied we would simply send the appropriate HTTP "request" to the supplied URL. As part of our API doc, we'd explain each protocol we supprot (initially http, but smtp, email, twitter, etc could be implemented) and what we would send back based.
So I am curious how you handle large loads with regards to server farms and the usual scalability/clustering stuff.
Posted by: andjarnic on September 20, 2008 at 09:35 PM
del.icio.us 
Digg 
DZone 
Furl 
Reddit
java.net RSS Feeds
