0

Jetty has this functionality where it can evict idle HttpSession objects out of memory and persist them on disk (passivation). Once a new request arrives with the same session id, it'll be brought back into memory (activation).

Jetty 9.2 and 9.3 source code for HashSessionManager and HashedSession reveals that the actual HttpSession instances are not discarded during idle eviction process but merely the attributes within them are cleared.

That tells me it is safe to keep a reference to a HttpsSession for a period longer than its active lifespan. And that I should not be worried about having a duplicate of the same session after it is de-idled.

I'm curious to know whether this is a standard behavior of all web server implementations. I could not find any documentation confirming that. Since session management is completely rewritten in jetty 9.4, is it true there as well?

Hooman Valibeigi
  • 95
  • 1
  • 7
  • I examined jetty 9.4 code and figured out a difference. Idle sessions are now deleted from SessionCache. Holding on to passive sessions is no longer safe (contrary to 9.3) since as soon as that object passivates it won't pass the validity checks on read/write operations. – Hooman Valibeigi Nov 15 '16 at 10:19

2 Answers2

0

The HttpSession you access from a HttpServletRequest is only garunteed to be valid for the duration of the Http exchange, once your request is processed, and a response is produced, and the request dispatch is completed, the specific HttpSession instance you accessed is now invalid, and recycled.

It is highly unwise to hold onto it beyond that timeframe, as the object, and its information could be recycled (from an object pool) into a different request/response for a different user.

WebSocket is another animal.

Once the HTTP connection is upgraded to WebSocket, all of the HTTP specific information is invalid.

Why? That's because WebSocket is not HTTP, and the Upgrade stops/terminates the active HTTP exchange.

The implementation in Jetty will recycle the HttpServletRequest, HttpServletResponse, and HttpSession at the point of the upgrade for use on a later HTTP request.

Also of note, the context, lifetime, and lifecycle of the HttpServletRequest, HttpServletResponse, and HttpSession are not defined in the Servlet spec, or the CDI spec. Meaning that if you use/require those objects in a WebSocket, know that you have entered into undefined behavior. It would be wise to copy the information you need from those objects for your WebSocket endpoint to use.

Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
  • I expected to hear that.What about WebSockets? Unfortunately jetty does not update HttpSession's lastAccessTime on each message sent/received via a websocket which could lead to the expiration of the session even though the socket is still connected. – Hooman Valibeigi Nov 15 '16 at 10:09
  • @hoomanv updated for websocket, as that's not HTTP, it has its own gotchas. – Joakim Erdfelt Nov 15 '16 at 13:11
0

The implementation in Jetty will recycle the HttpServletRequest, HttpServletResponse, and HttpSession at the point of the upgrade for use on a later HTTP request.

In jetty 9.4 UpgradeHttpServletRequest holds on to HttpSession ref but nulls HttpServletRequest ref on completion. I'm currently taking advantage of this to share attributes with multiple sockets.

Hooman Valibeigi
  • 95
  • 1
  • 7