java.lang.AssertionError: null in ConnectorTracker

[nPraml]

java.lang.AssertionError: null in ConnectorTracker

[TatuLund]

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.

[TatuLund]

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.

[nPraml]

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?

[nPraml]

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?

[TatuLund]

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.

[nPraml]

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?

[nPraml]

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: vaadin/flow#14232

[nPraml]

more details:

• when we updated the application from 8.16.1 to 8.17.0, the other app would be updated from 14.8.11 to 14.8.17
• the vaadin 8 application lost his connector (we have extended the logging):

expected connector: de.foconis.zak.vaadin.ui.ZAKUI@7b419867 (#0), class de.foconis.zak.vaadin.ui.ZAKUI
no connector found
Request: /UIDL/

[nPraml]

Hi, can you give a statement if it can be caused by the vaadin 14 application?

[rPraml]

We have discovered the problem now, it seems to be happen only in rare cases when multiple threads are involved:

Thread 1:

1. We invalidate certain user-session with 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)
2. As we do not have the session lock here, VaadinSession does listen on valueUnbound here: https://github.com/vaadin/framework/blob/master/server/src/main/java/com/vaadin/server/VaadinSession.java#L313
3. The above code adds "session destroy" code to the pendingAccessQueue of the (unlocked) session

Thread 2:

1. The second thread tries to handle a request by the user, see https://github.com/vaadin/framework/blob/master/server/src/main/java/com/vaadin/server/communication/UidlRequestHandler.java#L77
2. It will find the Session and the UI - in the meantime Thread1 starts to invalidate the session and removes the attribute from the HTTP-session
3. It will run all pending actions (which will invalidate the UI) and the following code in "getDiffState" cannot handle this case properly.

So what we see here is, that

1. That removing the "vaadinSession" attribute from the HTTP session is tried to be handled by the vaadin code in VaadinSession.valueUnbound
2. There is also a code path, when there is no lock on the vaadin session, this adds a pending FutureAccess to the vaadin session, that will be executed on next access
3. These FutureTasks are executed during writeUidl and will remove the current UI, so that the assert in connectorTracker fails, because the UI is detached.

As 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

[TatuLund]

@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.

[TatuLund]

We invalidate certain user-session with httpSession.removeSessionAttribute(vaadinService.getSessionAttributeName())

Why not httpSession.invalidate()?