On 5/29/20 10:09 AM, Stefan Eissing wrote:
> Looks good. Now I learned about the "ping" parameter...
Committed as r1878264 with a tweaked comment to make clear what I do.
Getting me to the next possible enhancement. I already had a patch but when
putting it to the mail I got doubts that it could work
due to the fact, that in most use cases HTTP/2 is encrypted.
In AJP a set ping parameter on the worker will also cause an AJP ping to be
sent as the first thing even on fresh connections and
we only wait for the timeout set in the parameter for a reply. The idea behind
this is that the backend might be able to deal with
a TCP handshake, but not with processing a request, because maybe all
processing threads / processes on the backend application
are busy. This way this can be detected quickly and early and we can sent our
request to a different backend in case of a load
balancing scenario.
With HTTP/2 we will likely have a TLS handshake first which likely already
requires a responding backend application. So it would
not work to wait only for ping timeout time on a ping reply as we will already
wait for the timeout set on the socket to get an
answer to our TLS client Hello. So the idea would be to already lower the
socket timeout to ping timeout before the TLS handshake
starts and reset it back after we received the ping from the backend. Opinions?
Regards
Rüdiger
