AsyncContext#startAsync not supported. Make sure async-supported is set to

Vaadin 6 / 7 / 8
1

I am running Vaadin 7.4.7 on Tomcat 8.0.23 on Java 8.0u45 on Linux with automatic pushmode. We noted several ongoing exceptions like the following, most likely relatedto a heartbeat or other request:

[font=courier new]
May 27, 2015 11:05:13 PM org.atmosphere.cpr.AsynchronousProcessor action
SEVERE: Invalid request state. AsyncContext#startAsync not supported. Make sure async-supported is set to true in web.xml https://example.com/example/ui/PUSH/

May 27, 2015 11:05:19 PM org.atmosphere.cpr.AsynchronousProcessor action
SEVERE: Invalid request state. AsyncContext#startAsync not supported. Make sure async-supported is set to true in web.xml https://example.com/example/ui/PUSH/

May 27, 2015 11:05:25 PM org.atmosphere.cpr.AsynchronousProcessor action
SEVERE: Invalid request state. AsyncContext#startAsync not supported. Make sure async-supported is set to true in web.xml https://example.com/example/ui/PUSH/
[/font]

The corresponding access log shows these were the requests made, all return HTTP STATUS 501:

[font=courier new]
99.123.45.678 - - [27/May/2015:23:05:13 -0700]
“GET /example/ui/PUSH/?v-uiId=3&v-csrfToken=a19e37eb-bb1b-494a-be0a-eb1377cf548c&X-Atmosphere-tracking-id=08e2c407-eded-4704-91cc-a91f4dc6a8c5&X-Atmosphere-Framework=2.2.6.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1432793114129 HTTP/1.1” 501 5 1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

99.123.45.678 - - [27/May/2015:23:05:19 -0700]
“GET /example/ui/PUSH/?v-uiId=3&v-csrfToken=a19e37eb-bb1b-494a-be0a-eb1377cf548c&X-Atmosphere-tracking-id=08e2c407-eded-4704-91cc-a91f4dc6a8c5&X-Atmosphere-Framework=2.2.6.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1432793120129 HTTP/1.1” 501 5 2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

99.123.45.678 - - [27/May/2015:23:05:25 -0700]
“GET /example/ui/PUSH/?v-uiId=3&v-csrfToken=a19e37eb-bb1b-494a-be0a-eb1377cf548c&X-Atmosphere-tracking-id=08e2c407-eded-4704-91cc-a91f4dc6a8c5&X-Atmosphere-Framework=2.2.6.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1432793126108 HTTP/1.1” 501 5 2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36
[/font]

It may be related to this issue I found via Google:
https://github.com/Atmosphere/atmosphere/issues/1973

My vaadin app servlet does have the async supported entry:

[font=courier new]

OpenESignFormsVaadinApplication
com.esignforms.open.vaadin.EsfVaadinServlet

Vaadin UI class to start with
UI
com.esignforms.open.vaadin.EsfVaadinUI


Application widgetset
widgetset
com.esignforms.open.vaadin.widgetset.Open_esignformsvaadinWidgetset


Want idle sessions to expire, after 3 missed heartbeats, since heartbeat will otherwise keep alive as long as the browser is open
closeIdleSessions
true


pushmode
automatic


true

OpenESignFormsVaadinApplication /VAADIN/* /ui/* [/font]

Is there any additional servlet-mapping I may need since my root / path serves up JSPs, images, javascripts, css, and JSP error pages for several http status codes.

I am guessing that these are heartbeat requests or the like, perhaps when no session or the like is present with a valid UI and/or the user is not logged in, etc. Unfortunately, those requests appear to keep on coming and don’t stop, as if all those error 501s are not stopping the client from trying yet again. I am not positive, but I put an IP address block on the offending client’s IP (from the access logs) and noted the errors stop, but if I unblock after 10-15 minutes, they start right back up. I blocked it for an hour and when I unblocked the IP, the errors did not return, so I presume somehow the vaadin client finally gave up (or the offending browser was closed, but since it was late at night, I doubt a user was involved).

Any thoughts on how to resolve this? Thanks!

2

The log entries indicate that the user is using long polling and the browser is trying to re-establish the push connection, either temporarily losing the connection or after a push has taken place. It will keep trying to do so for a long long time, the default configuration is

reconnectInterval: 5000,
maxReconnectOnClose: 10000000

I can’t see why this reconnect attempt would have async support disabled as you have configured it to be enabled for the servlet handling /ui/*. If the user’s session had expired and if the request would not get stuck in Atmosphere, it should end up in Vaadin’s push handler, which would tell the Vaadin client side about the expiration. At this point, the client side will stop with the reconnect attempts.

3

Thanks for the info, Artur.

Well, I know we installed a new release and restarted Tomcat, so that browser likely had an old connection of some sort as the user probably left his browser open without logging out. In our new release, we also upgraded Vaadin/widgetsets/etc. (we even upgraded Tomcat itself), so there would be no way for it to reestablish a connection and all tomcat session serializations would have been lost.

What are the units for the default config? Is that 5 seconds and 10 million attempts? Can I change them? In our scenario, I think if a client has lost push connection to our web server for 15 minutes, it can just stop (and the user would need to login again). A typical web server restart make take a couple of minutes, which is really the only time there should be a sustained lack of access, and if it is sustained, it should really just stop and force the user to reconnect/login. We are not really even using push (still waiting for it seem stable, and it is much better now), though it does help with a few race conditions where it seems our UI would be an update out of sync until they clicked a button or the like. So we might even think it’s okay for push reconnects to wait 10 or 15 seconds.

Can I change the default settings to achieve something like that? How would those values be configured?

4

The units are indeed 5000ms and 10M attempts. You can configure them using ui.getPushConfiguration(). There are no helpers for those parameters so you have to use setParameter(String,String) for it.

5

Thanks, Artur. I presume the 10M attempts is over the lifetime of the browser session? It’s such a big number, I’m wondering what the downfall would be if I set it to 15 seconds retry and 1000 attempts (about 4 hours of failed attempts). Does the attempt count reset when it reconnects, or is it a total over all errors during a Vaadin UI session?

6

It’s reset whenever the connection is re-established, so the default is in practice “never give up, never surrender” and the actual value does not matter. Setting it to something smaller should not cause any issues.

7

I’m getting exactly the same error message (using version 7.4.2):

SEVERE: Invalid request state. AsyncContext#startAsync not supported. Make sure async-supported is set to true in web.xml

when using either long polling or streaming. Websockets works fine.
async-supported is set to true. Atmosphere even seems to detect this:

INFO: Atmosphere is using async support: org.atmosphere.container.JSR356AsyncSupport running under container: Apache Tomcat/8.0.14 using javax.servlet/3.0 and jsr356/WebSocket API

8

Do you have any filters etc which do not have async-supported set?

Websockets take a different path after the connection has been established, bypassing all servlets/filters so it is natural that they work differently in this case.

9

No, there are no filters in web.xml. And there’s only one servlet, which is a subclass of VaadinServlet. It does instantiate our own service subclass of VaadinServletService in createServletService(). Could that have something to do with this?
Other methods like init() and servletInitialized() are also overridden but call super.

The problem is I can’t use Websockets in production (because of some issue with the infrastructure between browser and server not supporting Websockets), so need to fall back to streaming or long-polling.

10

Actually, our VaadinServletService subclass just override requestStart/requestEnd to set/clear the username in the slf4j MDC (Mapped Diagnostic Context) and both call super() in any case. So I doubt that’s the issue.

11

If you set a breakpoint at org.atmosphere.cpr.AsynchronousProcessor:135 you might be able to find out some more

12

hello all

i am using
[b]

SimplePageCachingFilter
net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter


SimplePageCachingFilter
/*

then i am getting error like
[/b]
AsyncContext#startAsync not supported. Make sure async-supported is set to true in web.xml http://localhost:8080/ywc/PUSH/
please suggest me.

13

Did you try adding true for your filter?

14

no
i added this one and it is working.
thanks.