I am writing a VXML application which accepts an incoming SIP voice call and then polls a web service on a Java application running on a Tomcat instance on the same host machine for incoming voice requests (eg. play an audio prompt or collect some digits) from a separate channel. These voice requests are received via a separate WS interface and cached for the VXML sessions to collect. The voice requests may be received anywhere from 0.5s to 30+ seconds after the call is accepted.
Logically, the VXML sessions should poll periodically for new requests and the Java application in Tomcat return a non-blocking response indicating if any requests have been received. However an additional constraint I have is that the CPU cost of making a web service call from the VXML interpreter is quite high, so repeating this regularly for large volumes of simultaneous calls will noticably impact system capacity.
A preferred approach would be to have the web application block the polls from the VXML application until a voice service request arrives in the cache (with a timeout of eg. 5 or 10s). However, I understand using Thread.sleep on servlet threads for long periods of time is a bad idea at the best of times, so I’m looking for an alternative to achieving this.
This application needs to support large volumes of simultaneous sessions on the server (expecting up to 1000 VXML sessions on planned hardware), so just increasing the thread count on Tomcat would not be acceptable.
Is there a way I can have Tomcat sideline the request for a period of time while freeing up the servlet thread for other requests? Per chance, is Tomcat smart enough to do this simply when I use Thread.sleep? 🙂
Thanks,
fb
Long-running requests and non-blocking I/O in Java is generally referred to as “Comet”. Tomcat 6 supports this in a proprietary way, and it’s incorporated into the Servlet 3.0 spec.
See this article to learn about how to do both.