Hi Luke,
On Fri, Feb 22, 2019 at 10:03:12AM +0000, Luke Seelenbinder wrote:
> Hi List, Willy,
>
> After transitioning to 1.9.4, I can say things are much more stable when
> using h2 on the frontend. Thanks for all the bug fixes and patches since
> 1.9.0! I'll be upgrading to 1.9.5 when it comes out, so I'm looking forward
> to that.
Great!
> I have one question: we track error rates across our fleet via response codes
> (5xx being considered errors) and we're noticing something a bit interesting
> in h2 mode. Given the following log lines:
>
> fra-magellan-tosaq haproxy[8845]: 178.23.xxx.xxx:49243
> [22/Feb/2019:06:58:29.986] stadiamaps~ tile/tile2 0/0/-1/-1/9 503 0 - - CC--
> 66/66/3/1/0 0/0 {...} "GET /tiles/osm_bright/9/263/[email protected] HTTP/2.0"
> fra-magellan-tosaq haproxy[8845]: 178.23.xxx.xxx:49243
> [22/Feb/2019:06:58:30.001] stadiamaps~ tile/tile3 0/0/-1/-1/10 503 0 - - CC--
> 66/66/2/1/0 0/0 {...} "GET /tiles/osm_bright/9/264/[email protected] HTTP/2.0"
> fra-magellan-tosaq haproxy[8845]: 178.23.xxx.xxx:49243
> [22/Feb/2019:06:58:30.019] stadiamaps~ tile/tile2 0/0/-1/-1/7 503 0 - - CC--
> 66/66/3/1/0 0/0 {...} "GET /tiles/osm_bright/9/265/[email protected] HTTP/2.0"
> fra-magellan-tosaq haproxy[8845]: 195.143.xxx.xxx:36064
> [22/Feb/2019:07:14:52.759] stadiamaps~ tile/tile3 0/0/-1/-1/12 503 0 - - CC--
> 78/78/1/1/0 0/0 {...} "GET /data/openmaptiles/3/1/2.pbf HTTP/2.0"
> fra-magellan-tosaq haproxy[8845]: 195.143.xxx.xxx:36064
> [22/Feb/2019:07:14:52.961] stadiamaps~ tile/tile3 0/0/-1/-1/853 503 0 - -
> CC-- 77/77/0/0/0 0/0 {...} "GET /data/openmaptiles/3/2/2.pbf HTTP/2.0"
>
> Why is the response code recorded as 503? If I'm interpreting the logs
> correctly, the client connected and disconnected before the request could
> even be passed to the backend, so shouldn't that be a -1 response code?
It really depends how/where/when the error was triggered. When forwarding
a connection, aborting the output can have the effect of an error being
triggered on the connection, which is immediately reported and detected
as such. That doesn't mean we shouldn't improve this, but this also means
trying to figure the exact sequence of events and trying to hack them to
consider alternate error reports.
> mainly want to know if we can safely ignore these errors or if perhaps it's a
> bug / undocumented behavior in h2 mode.
Do you have "option abortonclose" in your config ? If you have it, it can
indeed be a client abort that was sent and caused the outgoing request to
be aborted. If you don't have it, it *could* be a real connection error
that was misreported as a client abort because the client side technically
is already closed once the request is received from H2. But I'm not seeing
a non-null retry count in your logs so I have a doubt about this.
> For reference we're using H2 fe, mode htx, be H1.1 in our config currently.
OK that's useful indeed, thanks.
Willy
