-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
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 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmLPEUACgkQHPApP6U8 pFjVpRAAhIk//uWfkihpjwqp75MwDqe4mlAN3zbdvLoa4EU0QJyA8fZRnIFuO7Gg ksQYycpuGniEMPQH+l4Mb3T5/KogTkY3DZrBRh7vN+8oA3ELayuqTxDAdNjjsnmg uKWeYv3obL8pZQuSb5hVFXx4Dfe6pAXWk7CwuHls5Cs97lRqvN9C5lQM1QPArPpt nqNnDUm7HHmrSZVo82bdJxgXfpRXnoIg5qie3wGURHzdQK4JZGpZY7jJDAmM/HTW QNHg2saIFR1ce5YdGD2UZ5KbcVylfP1vX3oQZj9O+ytRGW37qiuAqjkuLZ73gJt7 Xlz/6hAwxq+RMsfysJQitdytAcZj/BZQs3OesvcYxSpG9M2zOs3y6Pi+V7ieRk+i GbwGFzlGzmyA8LWdpgWFNHjGPlGwa04ALtp/zN6MoovULZs9XskUd3PBM622roJ2 A+BUrr1GHo8nbcnStcTdL9JQuyrjFPOyyT+FUQR0pWk/PQKutpMzqoKYgK/CWcBv bxiREyfCOxTMLKkWXp4tZV6zMakdk+/srbPJbW35HS7PJT6iTP1ldWjh2hw4XXbD Jn1OXXJQZ6AHDPGMpKSAvVeCQre/jb6yvFhsgHYz1VjZs5dIw8kqgy5AZrgnjwcX 9azk5oNJon6AplWbnN0QVddP+rmxgiPwyvu7ywgxrlgdU3ykazo= =h6fX -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
