Details
-
Type:
Task
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Beta
-
Fix Version/s: 2.0.1
-
Component/s: Push Library
-
Labels:None
-
Environment:ICEfaces, Tomcat 7
Description
When ICEfaces is configured to use Servlet 3.0, the following Exception occurs with ICEpush:
Caused by: java.lang.IllegalStateException: Calling [asyncComplete()] is not valid for a request with Async state [DISPATCHED]
at org.apache.coyote.AsyncStateMachine.asyncComplete(AsyncStateMachine.java:186)
at org.apache.coyote.http11.Http11Processor.actionInternal(Http11Processor.java:506)
at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:809)
at org.apache.coyote.Request.action(Request.java:344)
at org.apache.catalina.core.AsyncContextImpl.complete(AsyncContextImpl.java:83)
at org.icepush.servlet.AsyncAdaptingServlet$AsyncRequestResponse.respondWith(AsyncAdaptingServlet.java:66)
at org.icepush.BlockingConnectionServer.respondIfPendingRequest(BlockingConnectionServer.java:196)
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Indeed ICEpush with Tomcat 7.0 and async. support enabled does not work. The responses on the blocking connection seem to have the correct content (fixed sized), but the content is marked as 'chunked' which confuses the browser.
The reason why ICEpush fails in Tomcat 7.06 is due to the HTTP headers missing in the blocking connection response.
To find out more about how Tomcat 7 works I devised a simple test, a servlet that parks the request and then after 5 seconds responds.
Setting the headers just before the response is sent does not succeed in actually sending the headers over the wire:
protected void doGet(HttpServletRequest request, final HttpServletResponse r) throws ServletException, IOException {
final AsyncContext ctx = request.startAsync();
ctx.start(new Runnable() {
public void run() {
try
catch (Exception e)
{ e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. }}
});
}
Setting the headers on the request thread before or after the AsyncContext is acquired succeeds in sending the headers over the wire:
protected void doGet(HttpServletRequest request, final HttpServletResponse r) throws ServletException, IOException {
final AsyncContext ctx = request.startAsync();
r.setHeader("bla", "fffff");
r.setContentType("text/plain");
r.setContentLength("------".getBytes().length);
r.getWriter().print("------");
ctx.start(new Runnable() {
public void run() {
try { Thread.sleep(5000); ctx.complete(); } catch (Exception e) { e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. }
}
});
}
Need to see if there's a Tomcat bug issue reported for this, and if not, report it.
Setting the contentType prior to async operations seems to fix the problem:
response.setContentType("text/xml");
asyncContext = request.isAsyncStarted() ? request.getAsyncContext() : request.startAsync();
Since the contentType can likely be set twice, the recommended fix is to call setContentType as above, then rely on re-setting it in other cases. This will at least have the effect of supporting Servlet 3.0 except under error conditions.
The current Tomcat implementation may be expecting that the headers are set prior to the return of the original service() method.
Set default text/xml content type to workaround Tomcat's limitation (headers are sent only when added on the request thread).
Issue recorded in Tomcat's bug tracking system: https://issues.apache.org/bugzilla/show_bug.cgi?id=50753
Looks like the issue was already fix in Tomcat 7.0.8 version.
Looks like Tomcat 7 fails in the same way as GlassFish 3.0.1.