Hi Willy, > Do you have "option abortonclose" in your config ?
We do not have abortonclose. Do you recommend this if we have a lot of
client-side request aborts (but not connection level closes)? From reading the
docs, I came away conflicted as to the implications. :-)
Best,
Luke
—
Luke Seelenbinder
Stadia Maps | Founder
stadiamaps.com
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 1, 2019 5:28 AM, Willy Tarreau <w...@1wt.eu> wrote:
> 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/1...@2x.png
> > 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/1...@2x.png
> > 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/1...@2x.png
> > 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
publickey - luke.seelenbinder@stadiamaps.com - 0xB23C1E8A.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
