Open nPraml opened 1 year ago
There was one fix, that was related to connector tracker in 8.16.0. That introduced a regression that was fixed in 8.16.1. But there is no changes in it between 8.16.1 and 8.17.0, so this is a bit surprising.
since 28th October we have vaadin 8.17.0 and we get the exeception every day multiple times.
Can you explain it what does it mean and when/why can it happen?
Hi, could you get a look at to this issue? Can you explain it what does the exception mean and when/why can it happen?
Can you explain it what does the exception mean and when/why can it happen?
I think the exception is possible only if connector id is null.
Can you explain it what does the exception mean and when/why can it happen?
I think the exception is possible only if connector id is null.
Yes I know that, but how can the connector id be null after update to vaadin 8.17.0?
Hi @TatuLund ,
we analyzed further. Next to our main application (vaadin 8.17.0) we also have another vaadin application running on the same tomcat (with vaadin 14.8.17).
We got new catalina.out logs and we see the warning [warning] Resynchronizing UI by client's request. A network message was lost before reaching the client and the client is reloading the full UI state. This typically happens because of a bad network connection with packet loss or because of some part of the network infrastructure (load balancer, proxy) terminating a push (websocket or long-polling) connection. If you are using push with a proxy, make sure the push timeout is set to be smaller than the proxy connection timeout
very often. We assume this is from the application with vaadin 14.8.17.
Can this cause the problem with the Vaadin 8 exception? (java.lang.AssertionError: null at com.vaadin.ui.ConnectorTracker.getDiffState(ConnectorTracker.java:700)
)
I found this bug which would be fixed with 14.8.19: https://github.com/vaadin/flow/issues/14232
more details:
expected connector: de.foconis.zak.vaadin.ui.ZAKUI@7b419867 (#0), class de.foconis.zak.vaadin.ui.ZAKUI
no connector found
Request: /UIDL/
Hi, can you give a statement if it can be caused by the vaadin 14 application?
Hi, can you give a statement if it can be caused by the vaadin 14 application?
If you are using MPR and the Vaadin 8 application is embedded in Vaadin 14 using it, then yes. The MPR product is implemented in such a way that it interferes with couple of asserts. This has been "fixed" in Vaadin 8.19.0 so that it does not run those asserts if MPR is present.
We have discovered the problem now, it seems to be happen only in rare cases when multiple threads are involved:
Thread 1:
httpSession.removeSessionAttribute(vaadinService.getSessionAttributeName())
(This is done to force logouts due security reasons and may be NOT executed by a thread that locks any vaadin session)valueUnbound
here: https://github.com/vaadin/framework/blob/master/server/src/main/java/com/vaadin/server/VaadinSession.java#L313Thread 2:
So what we see here is, that
VaadinSession.valueUnbound
FutureAccess
to the vaadin session, that will be executed on next accessAs the code looks like it would handle removing the session attribute with httpSession.removeAttribute
correctly, (at least it tries, because we would have expected to run in this code part https://github.com/vaadin/framework/blob/master/server/src/main/java/com/vaadin/server/communication/UidlRequestHandler.java#L83), we want to ask if this is still the correct way and there is a bug in vaadin code?
We need this to enforce session invalidation on other browser instances.
Roland
@rPraml for me your latest comment seems not to be related to original question about the ConnectorTracker. So should you actually open a new ticket about this.
We invalidate certain user-session with httpSession.removeSessionAttribute(vaadinService.getSessionAttributeName())
Why not httpSession.invalidate()?
Hi,
we check regularly the logs of our customers and an AssertionError occures very often since we updated the vaadin version from 8.16.1 to 8.17.0. Stacktrace:
java.lang.AssertionError: null at com.vaadin.ui.ConnectorTracker.getDiffState(ConnectorTracker.java:700) at com.vaadin.server.LegacyCommunicationManager.encodeState(LegacyCommunicationManager.java:96) at com.vaadin.server.AbstractClientConnector.encodeState(AbstractClientConnector.java:292) at com.vaadin.server.communication.SharedStateWriter.write(SharedStateWriter.java:67) at com.vaadin.server.communication.UidlWriter.write(UidlWriter.java:176) at com.vaadin.server.communication.UidlRequestHandler.writeUidl(UidlRequestHandler.java:125) at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:93) at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1669) at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:464) at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:239) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:215) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
Can you explain it what does it mean and when/why does it happen?
Kind regards Noemi (FOCONIS AG)