If the user closes the tab/browser _some_ deinitialization occurs, for instance the Spring SecurityContextHolder is cleared and other things happen. Then, after three missed heart beats, UI.detach() is called and the UI is already semi-deinitialized.
One of the results is the below stack trace, I cannot trace it since there is none of our code in it.
We run
<vaadin-bom.version>7.7.6</vaadin-bom.version>
<vaadin.plugin.version>${vaadin-bom.version}</vaadin.plugin.version>
<vaadin-spring.version>1.0.2</vaadin-spring.version>
Vaadin version: 7.7.6
Tomcat version: 8.5.3
Spring version: Athens-RELEASE
Apr 03, 2017 10:55:54 AM org.atmosphere.container.JSR356Endpoint onError SEVERE: java.io.EOFException at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1222) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.isReadyForRead(NioEndpoint.java:1128) at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:58) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148) at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1425) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745)
Additional disclosure: we run an Nginx front end as proxy. This whole websocket/proxy/SSL/browser connection and´d how they all relate to each other is still kind of a mystery to me.
I'm seeing the same stacktrace:
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: Aug 11, 2017 4:25:31 PM org.atmosphere.container.JSR356Endpoint onError
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: SEVERE:
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: java.io.EOFException
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1244)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1184)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:72)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.websocket.server.WsFrameServer.doOnDataAvailable(WsFrameServer.java:171)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.websocket.server.WsFrameServer.notifyDataAvailable(WsFrameServer.java:151)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1457)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
Aug 11 18:25:31 6745fa5c63fd ecs-cr_td-55-c0b7bedec6a9acb0c901: at java.lang.Thread.run(Thread.java:748)
We're running behind an Amazon Application Load Balancer. According to the documentation the ALB will close frontend connections if the backend hasn't given sign of life during idle_timeout. Could it be that the ping-pong mechanism only acknowledges pings, but doesn't pong?
spring boot : 2.0.0.M5
vaadin: 8.2.0.alpha2
vaadin spring boot: 2.0.1
tomcat embed: 8.5.23
.log(JDK14LoggerAdapter.java:588) |-ERROR |2017-11-03 15:17:33.445|
java.io.IOException: Unable to unwrap data, invalid status [CLOSED]
at org.apache.tomcat.util.net.SecureNioChannel.read(SecureNioChannel.java:618)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1248)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1221)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1194)
at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:72)
at org.apache.tomcat.websocket.server.WsFrameServer.doOnDataAvailable(WsFrameServer.java:171)
at org.apache.tomcat.websocket.server.WsFrameServer.notifyDataAvailable(WsFrameServer.java:151)
at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148)
at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
nginx.conf
server {
listen xxx.xxx.xxx.xxx:443 ssl http2;
server_name mydomain.com;
server_name www.mydomain.com;
server_name ipv4.mydomain.com;
ssl_certificate /opt/psa/var/certificates/cert-HtaT9k;
ssl_certificate_key /opt/psa/var/certificates/cert-HtaT9k;
ssl_client_certificate /opt/psa/var/certificates/cert-4M1dWh;
client_max_body_size 128m;
# disable unsupported ciphers
ssl_ciphers AESGCM:HIGH:!aNULL:!MD5;
# ssl optimizations
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 30m;
add_header Strict-Transport-Security "max-age=31536000";
root "/var/www/vhosts/mydomain.com/httpdocs";
access_log "/var/www/vhosts/system/mydomain.com/logs/proxy_access_ssl_log";
error_log "/var/www/vhosts/system/mydomain.com/logs/proxy_error_log";
location / {
proxy_pass https://xxx.xxx.xxx.xxx:801;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Accel-Internal /internal-nginx-static-location;
access_log off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;
send_timeout 300;
}
add_header X-Powered-By PleskLin;
include "/var/www/vhosts/system/mydomain.com/conf/vhost_nginx.conf";
}
# Vaadin PUSH
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen xxx.xxx.xxx.xxx:80;
server_name mydomain.com;
server_name www.mydomain.com;
server_name ipv4.mydomain.com;
client_max_body_size 128m;
return 301 https://$host$request_uri;
}
Faced same issue (Tested with Tomcat embedded 8.5.27.0).
It seems that the issue only occurs with Tomcat embedded which runs on webapp-runner (https://github.com/jsimone/webapp-runner).
The issue happens whenever below issue occurs:
2018-02-06T17:06:40.721580+00:00 heroku[router]: at=error code=H15 desc="Idle connection" method=GET path="/PUSH?v-uiId=0&v-pushId=9330bb7a-2fea-40a4-a91e-3aa542de74f3&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.3.2.vaadin1-javascript&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&Content-Type=application/json;%20charset=UTF-8&X-atmo-protocol=true" host=www.neonplatform.com request_id=0e7b2e14-be1b-4179-934f-ce0f92feced2 fwd="27.74.157.203" dyno=web.1 connect=0ms service=75208ms status=503 bytes= protocol=http
Not sure this is reason:
https://stackoverflow.com/questions/13063683/h15-on-heroku-sse-request
We face the same problem with:
Vaadin version: 7.7.13
Tomcat version: 8.5.11
Apr 04, 2018 7:57:38 AM org.atmosphere.container.JSR356Endpoint onError SCHWERWIEGEND:
java.io.EOFException
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1221)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1161)
at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:63)
at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148)
at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
@knoobie We also encountered the same problem,Tomcat 9.0.1 websocket,
How did you deal with this problem?
thank you
@kenneyLee Sadly not in a good way.. we ignore it.. anything works (at least it seems so) just the Log spamming is kinda annoying.
Hello there!
We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.
There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):
Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!
Resume of vaadin issues: almost closed by stale bot.
Solution provided by vaadin team: create a new framework.
👏👏👏👏👏
The "problem" is that Atmosphere logs everything here https://github.com/Atmosphere/atmosphere/blob/master/modules/runtime/src/main/java/org/atmosphere/container/JSR356Endpoint.java#L303
So it will produce sometimes some excess log in cases like this, which seems to be non-issue.
In newer version of Atmosphere log level has been reduced to debug, but it is still being logged.
As a follow-up on Tatu's comment:
Here's the issue in the Athmosphere project: https://github.com/Atmosphere/atmosphere/pull/2240
It has been merged into Atmosphere 2.4.15 and 2.5 and onwards. For comparison Vaadin7 uses Athmosphere v2.2. Therefore, for any Vaadin framework which doesn't use a somewhat recent Atmosphere then you'll have to find a way to silence these messages yourself if you don't want them in the log. For example if you are using J.U.L. you can implement a Logging Filter. Similarly for other logging frameworks.
Hello there!
We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.
There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):
Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!