The COMET (Async HTTP/Delayed Response/Ajax Push…) technique can be applied in any situation where “server push” is desired over HTTP protocol (which has obvious routing, security/TLS, and compression GZIP advantages), whether this is server/server communication, Server/RichClient or Server/Thin Client (Ajax).

The COMET approach provides low latency, low bandwidth combination, and as an added bonus you even get heartbeat/keepalive for free, when you have the typical 30-second timeout “null” message being returned to the client, ensuring that the client libraries and other network components do not disconnect the HTTP/Socket connection.

So you could argue, that the COMET approach is ideally suited to any application, where a client wish to subscribe to data from a channel/web service. I am currently involved in a large infrastructure project, where Rich Clients connect to web services to subscribe to data channels. The transport format is ATOM (over HTTP) and to get low latency, COMET is applied. We are currently looking into moving to RESTEasy with ATOM/Asynchronous HTTP since this implementation seems very elegant.

Background COMET article: http://en.wikipedia.org/wiki/Comet_(programming)

Thanks. Interesting use case.

I think there’s more use cases for “async http” than just the comet technique for ajax. For example, consider the case where a servlet wants to make a number of webservices calls to mashup some data. If each webservice call is executed synchronously, then on a moderately busy site this can rapidly eat up servlet container threads. Allowing the calls to be asynchronous and proceed in parallel (where possible of course) can free-up precious servlet container threads and thereby make the site more available. We implemented a webapp to show this. The servlet makes calls to eBay using Jetty’s async http client, and suspends the servlet until the results of all the REST calls are available. The numbers clearly show the benefit of this type of approach.

best regards
Jan

Anyway, your idea will solve the problem when a user got some cool non-blocking data access layer or uses only in-memory data structure, so I don’t think it’s a bad idea. I was just wondering what would be the real use case is.

@Path(“/myresource”)
@GET
@Execution(“detached”) // @Execution(“attached”) is assumed implicitly
public Object getMyResource() {
… the thread that called this method is detached from its thread pool automatically …
… once the execution of this method completes, the thread is returned to the thread pool or is destroyed (if the pool size has reached to its maximum already) …
}