A note about mod_shib2 and mod_http2

[Cantor, Scott]

> I had to pull some monitoring reports from 2017 but yes we originally saw CPU
> utilization step up in whole number increments just like it is in our testing now.
> In other words, if our problem was ever CPPXT-116, there is no reason to think
> it isn't still CPPXT-116.  FWIW at that time I provided debug info in #httpd-dev
> and they agreed I was having deadlocks in SP code, which is why we assumed it
> was CPPXT-116.

A deadlock isn't consistent with CPU spikes, at least no conventional definition of the term I'm familiar with. It just hangs on locks doing nothing. I don't know, but I wouldn't imagine CPPXT-116 led to anybody's CPU spiking, so I would doubt that had anything to do with your problem. At the time you had mentioned deadlock, but not the CPU angle.

> All of the httpd processes with high load have pairs of threads which appear to
> be stuck in the xmltooling locking code path I provided in the previous
> message.  At least, I haven't managed to catch them in any other code path and
> the thread IDs remain the same.

But there's nothing there that looks unusual. There are several of those threads in any system running Shibboleth and they'll all be waiting on condition variables in an idle state most of the time. There is no reason to imagine they are hung up, nor would they be consuming CPU.

-- Scott