When I talk about shortcomings, I think about the lack of Tomcat support for one thing. Tomcat seem to have a bug in the async processing. The first request lets you set the response header, and that response gets parsed correctly on the client side. The following requests in the same async context does not let you set the response headers, and Tomcat seem to give some default headers only. In addition, it also switches to chunked transfer encoding because of missing content length. This results in errors in clients trying to read the response from a Tomcat context. These problems does not occur when using Jetty using the same Servlet 3.0 API's. Jetty's behavior was the same as when using its Continuation API.
The second problem I encountered was that the extension does not always return a result from a request. I saw the same behavior using both the Jetty Continuation API's and the Servlet 3.0 API's. The result of this is that Emite (http://code.google.com/p/emite/) never finished logging in. I also tried using Pidgin (http://www.pidgin.im/), which has BOSH support if you enable it. Using Pidgin I was able to log in successfully, but chatting was a bit problematic. Sending a message to the server wasn't noticed by the server using an already open async request. I know the server never received the message as I had enabled both console logging of all BOSH messages as well as database logging of all chat messages. When Piding lost the connection and created a new one however, the message was resent, and the message got through. I then also received pending messages from others.