Hash: SHA256


On 8/9/17 11:35 AM, Mark Thomas wrote:
> On 09/08/17 16:09, David Wall wrote:
>> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and 
>> Atmosphere Websockets.
>> We have had reports of sessions logging out while users are
>> active with our Vaadin-based application.  This has been
>> frustrating as we can't seem to track down why Tomcat's session
>> is not being updated, but figure it's something to do with the
>> websockets/push not updating Tomcat reliably.
>> Our app shows a "last sent to server" timestamp that seems to
>> keep current with user activity, updating as the user clicks on
>> buttons, checkboxes, etc.
>> We also have a "list of active sessions" screen that shows all
>> active sessions including the HttpSession.getCreationTime() and 
>> HttpSession.getLastAccessedTime().  We see it appears as if the
>> last accessed time stops being updated when using simple forms
>> that perhaps update via websockets rather than HTTP requests.
>> Our "last sent to server" timestamp shows each of these clicks
>> updating it, but the HttpSession.getLastAccessedTime() is not
>> updating.
>> Is there something about push/websockets or anything else that
>> would cause the HttpSession access time not to update?  I don't
>> think we have a way to update it ourselves as I believe it's
>> managed by Tomcat itself, but as Tomcat is handling the websocket
>> requests, it's unclear why they are not tied to the HttpSession.
>> Anybody have any ideas?  Thanks as we have a lot of frustrated
>> users who would love for us to find out what's going astray.
> What you are seeing is expected behaviour. This was discussed in
> the WebSocket EG. The short version is: - WebSocket requests don't
> update the session's last accessed time - you need an HTTP request
> from the browser to update the session's last accessed time (and
> update the expiry time of the browser's session cookie) - so the
> application has to do periodic HTTP requests.
> You can reduce the frequency of these requests by extending the
> session timeout (remembering you need an HTTP request after this to
> update the browser's cookie). You then need to be careful to reduce
> the timeout again once WebSocket comms end.

Websocket ignoramus, here. Is there a way for (websocket) application
code on the server side to trigger a "touch" of the HttpSession that
is linked with the connection? Or is the problem that the websocket
connection and the HTTP connection are essentially independent?

- -chris
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to