In the original failover testing, I found the maxInactiveInterval method on the HttpSession object on the new primary node returned -1. This caused the SessionDispatcher logic to immediately fail the session. A value of -1 is potentially valid, and stands for 'never timeout'. So the code testing session validity now checks if the value of this maxInactiveInterval is positive, and if so, puts this positive value into the session (only once) as a mechanism for sharing this info with the failover node. On the new primary node, there's apparently no way to discover what the original value was in web.xml.
This bit would throw an exception checking if the session was expired if the session had expired. The code now catches this exception.
Bug
Major
In the original failover testing, I found the maxInactiveInterval method on the HttpSession object on the new primary node returned -1. This caused the SessionDispatcher logic to immediately fail the session. A value of -1 is potentially valid, and stands for 'never timeout'. So the code testing session validity now checks if the value of this maxInactiveInterval is positive, and if so, puts this positive value into the session (only once) as a mechanism for sharing this info with the failover node. On the new primary node, there's apparently no way to discover what the original value was in web.xml.
This bit would throw an exception checking if the session was expired if the session had expired. The code now catches this exception.