Async request performance with SIP Servlet's in Tomcat 7

Question

I've read that Asyn processing of HTTP request in Tomcat 7 through the use of SIP can improve a web applications performance, but I wasn't sure how true this was. I have read that when the browser makes its HTTP request, the thread that handles that request spawns a new thread that sits and waits for new activity at the SIP enpoint, and then the thread which initially handled the request is freed. But now there is still one thread sitting idle listening at the SIP endpoint. Is this really better?

Answer 1

It should be made clear that while converged HTTP/SIP applications can make a great deal out of asynchronous processing support in the server side, it is the asynchronous processing feature alone that provides greater performance for the web server.

Java Servlet 3.0 introduced support for asynchronous request processing and Apache Tomcat 7 implements Java Servlet 3.0, so you have support for asynchronous processing there.

Mobicents Sip Servlets 2.x (http://www.mobicents.org/products_sip_servlets.html) platform is already integrated with Tomcat 7, while the team is working towards integration with JBoss AS 7, which means that a converged HTTP/SIP application running on MSS 2.x platform, can benefit of the asynchronous processing support. You can see an example of a converged HTTP/SIP application making use of the asynchronous processing support here.

What Java Servlet 3.0 asynchronous support provides, is a way to place the request in a queue while waiting for a resource to become available or waiting for an event, and recycle the original thread, thus make it available for new clients. While the request is in the queue, no web server threads are consumed for this. That is a more efficient way to handle the available web server threads.

So for your question, a converged application will anyway wait for certain SIP messages, such as SIP INVITE or SIP BYE, and will act as needed. If now in this picture you add the Java Servlets 3.0 asynchronous processing, you can have a user interface (client's web page) that can be updated in every SIP message without any expensive AJAX polling mechanism or proprietary APIs. That will happen by placing the client's request in a queue while waiting for a SIP message and the original thread will be freed. When a new SIP message comes up, then a response will be send to the client.

Hoped that helped.