How to avoid push connection errors to a detached view

Flow
1

I’m implementing the standard Broadcaster pattern in Java EE and I wonder if it is possible to de-register views from push connection tracking in onDetach()?
Otherwise the logs will be filled with errors like

22:45:56,103 ERROR [com.vaadin.flow.server.communication.PushAtmosphereHandler] (Atmosphere-Shared-16) Exception in push connection: java.io.IOException: Connection remotely closed for a62c4c4b-d760-4bf6-a89b-90a0c11a992b

whenever the session expires and the view gets detached.

The sequence of events is as follows:

22:51:56,887 INFO  [org.vaadin.example.Broadcaster] (default task-7) Unregistering org.vaadin.example.MainView@1094dd0
22:51:56,887 INFO  [org.vaadin.example.MainView] (default task-7) org.vaadin.example.MainView@1094dd0 was detached
22:51:56,888 ERROR [com.vaadin.flow.server.communication.PushAtmosphereHandler] (Atmosphere-Shared-30) Exception in push connection: java.io.IOException: Connection remotely closed for 5b1386cb-9c06-4179-af30-c4afe83be74d

So, first the session expires which triggers onDetach() where I unregister the view from the broadcaster and then log that it was detached. Immediately after this there is the IOException.

2

Simplest solution: decrease the log message of that class to FATAL

3

Thanks, this is possible. However, have you done it this way? Would I not want to see other errors from this class, can I safely ignore them?

4

I’ve personally done this for literally the last decade because it was so annoying… but I’m not sure if it’s the best options… at least our apps are stable tho :sweat_smile:

5

I can understand… it seems deceptively simple: just unregister the view from Atmosphere connections list in onDetach(), but I guess the API is not exposed this way.

6

I have not encountered this problem in my test app cdi-demo/src/main/java/org/vaadin/cdidemo/eventbus at master · TatuLund/cdi-demo · GitHub

7

It is naturally Vaadin 8 app, but in Flow the Push integration is the same even today.

8

We have the same Problem. It seems to be related to the fact, we deploy our Vaadin 24 Spring boot app to an external Tomcat 10.1 server via war deployment.