Currently I am facing an issue regarding vaadin push and undertow session timeout.
As Vaadin is continuously pushing the changes from server, it is keeping the session alive , Hence hindering session timeout happening which was configured using undertow.
SO , I am configuring MANUAL PushMode and trying to push the changes using the scheduler, but still the vaadin is pushing automatically every minute and with the latest vaadin version,we are not able to set pushTimeout and Heartbeat Intervals.
Could you please help me with some clue on how to achieve this manual push mode to work?
Are you sure that what you’re seeing is a regular Vaadin push? You can put a breakpoint in com.vaadin.flow.server.communication.AtmospherePushConnection.push(boolean) to check whether this is what happens and through that also find the cause.
Could it be that what you’re seeing is automatic keep-alive messages used by the underlying Atmosphere library? If that’s the case, then you could maybe configure a longer keep-alive timeout there?
The last thing to note is that Vaadin also has a closeIdleSessions which makes the UIs close themselves after being inactive for a while and this will then also allow the underlying servlet session to be expired shortly after.
with @Push(value=PUSHMODE.MANUAL), it doesnt go the
“com.vaadin.flow.server.communication.AtmospherePushConnection.push(boolean)”.
But every minute I see the vaadin push with “Ajaxrequest.OnReadyStateChange” is being triggered even with MANUAL PUSH MODE (I mean it is behaving same as PUSH with AUTOMATIC Push mode).
If you are updating Grid with Push, that will keep session alive as Grid data fetch mechanism does server call (sort of ack) back after data received. That will be a request that prolongs the session. So I am asking is that what you are doing.
We used to have this noted in our documentation, but has been lost when we restructured the documentation.
Everyone has their own guess of what goes on here. I would rule out Grid if this happens consistently every minute. Atmosphere heartbeat would go over a websocket which means that the reference to Ajaxrequest.OnReadyStateChange wouldn’t make sense.
My guess is that the application uses the push fallback using HTTP long polling instead of using websockets. This may be through explicit configuration or because the browser, the server or some proxy in between has been configured in a way that doesn’t support websockets.
When using HTTP long polling, there’s a new request every single minute to deal with regular HTTP timeouts that are optimized for relatively short HTTP requests. This means that those requests are inevitable when long polling is used.
And that long polling functionality is one of the reasons why we introduced the closeIdleSessions configuration option that I mentioned in a previous post. It’s purpose is to get as close as possible to how things would work without those regular requests while still having a working push channel over regular HTTP.