HttpSession NullPointerException on Apache Tomcat 8.5.4

[Cantor, Scott]

> Once we were made aware of these issues, we upped our loggers to DEBUG,
> captured as much diagnostic information from production as possible, and
> then rolled back to Apache Tomcat 8.0.36.

And it's presumably not happening with that version. What about earlier versions of 8.5?

You need to be clearer about your storage configuration, but I'm guessing it's using client-side. That still leaves options open, but I doubt it matters whether local storage is on.

The error is a sanity check, and the container has to be malfunctioning for that to happen without the cookie just getting stomped, it's losing the Java session mid-stream. The client storage plugin is very intolerant of that for reasons I won't get into, I don't know if it's possible to soften it. But once the session is gone, it's going to crash anyway, webflow will just fall over.

You need to file a bug, because I want to reproduce the error handling behavior and see if that's a bug or not, but the session thing is very likely not our bug.

> We made no changes to our IdP configuration during the Tomcat upgrade,
> and only updated Tomcat's server.xml to explicitly use the JSSE-based HTTP
> connector, to maintain parity with our Tomcat 8.0.36 deployment.

Did you try it without that change? What's the default?

> Given that the issue could be coming from any of
> these three components, I figured I'd kick this one open to this list to see if
> anyone else has experienced these issues, and to make the Shibboleth
> developers aware of the problem. If I recall correctly, testing on Tomcat is
> less frequent and extensive than testing on Jetty.

I'm fairly confident it's not an IdP issue. IIt could be something Spring WebFlow is doing, I guess, but that seems unlikely given all the other containers that do work. Occam's Razor?

I think low level Tomcat tracing would be needed to find out why the session is disappearing, since a cookie issue or a load balancer glitch should manifest with any version.

> If this is a conversation better suited to the developers list, I'd be happy to
> take it over there.

There really isn't much we can do either way but track it. It's something we need to be able to reproduce, and it sounds like that requires load (so it's likely a race condition in their code). Can you reproduce it under some load?

-- Scott