Hi Willy, I just confirmed the other patchset works, so I will start going down this road. :-)
While testing the other issue, I discovered something fascinating. Our
application is typically used by clients that cancel requests with reasonable
frequency (5+%). When zooming in and out of maps quickly, it's pretty common
for map tiles to be requested and then the request is canceled from the
client-side, because they are no longer required (out of view, etc.).
There is a strong correlation between client connections canceling requests
(resulting in a HTTP log string of CD--) and then a whole string of requests
immediately after resulting in server connection resets (resulting in SD--).
I've included some example log lines below. This behavior causes no issues when
HTX & h2 mode are disabled for backends (still using h2 on the frontend). If
the additional information triggers any ideas, let me know, otherwise I'm
starting down the list recommended by you and Aleks.
Best,
Luke
—
Luke Seelenbinder
Stadia Maps | Founder
stadiamaps.com
stadiamaps~ tile/tile1 0/0/202/-1/266 -1 0 - - CD-- 2/1/5/5/0 0/0 {} "GET
/tiles/osm_bright/9/344/1...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/202/-1/266 -1 0 - - CD-- 2/1/4/4/0 0/0 {} "GET
/tiles/osm_bright/9/348/1...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/202/-1/266 -1 0 - - CD-- 2/1/3/3/0 0/0 {} "GET
/tiles/osm_bright/9/344/1...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/202/-1/266 -1 0 - - CD-- 2/1/2/2/0 0/0 {} "GET
/tiles/osm_bright/9/348/1...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/202/-1/266 -1 0 - - CD-- 2/1/1/1/0 0/0 {} "GET
/tiles/osm_bright/9/344/1...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/202/-1/266 -1 0 - - CD-- 2/1/0/0/0 0/0 {} "GET
/tiles/osm_bright/9/348/1...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/0/-1/456 -1 0 - - SD-- 2/1/5/5/0 0/0 {} "GET
/tiles/osm_bright/10/690/3...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/0/-1/456 -1 0 - - SD-- 2/1/4/4/0 0/0 {} "GET
/tiles/osm_bright/10/695/3...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/0/-1/456 -1 0 - - SD-- 2/1/3/3/0 0/0 {} "GET
/tiles/osm_bright/10/690/3...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/0/-1/454 -1 0 - - SD-- 2/1/2/2/0 0/0 {} "GET
/tiles/osm_bright/10/695/3...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/0/-1/454 -1 0 - - SD-- 2/1/1/1/0 0/0 {} "GET
/tiles/osm_bright/10/690/3...@2x.png HTTP/2.0"
stadiamaps~ tile/tile1 0/0/0/-1/454 -1 0 - - SD-- 2/1/0/0/0 0/0 {} "GET
/tiles/osm_bright/10/695/3...@2x.png HTTP/2.0"
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 22, 2019 11:33 AM, Willy Tarreau <w...@1wt.eu> wrote:
> On Tue, Jan 22, 2019 at 09:42:53AM +0000, Luke Seelenbinder wrote:
>
> > Hi Willy, Aleks,
> > I will try the things suggested this afternoon (hopefully) or tomorrow and
> > get back to you.
> >
> > > At least if nginx does this it should send a GOAWAY
> > > frame indicating that it will stop after stream #2001.
> >
> > That's my understanding as well (and the docs say as much).
>
> OK.
>
> > I assumed HAProxy
> > would properly handle it, as well, so perhaps it's something else nefarious
> > going on in our particular setup.
>
> Or we might have a bug there as well. I'll recheck the code just in case
> I spot anything.
>
> > There is still the possibility that the bug
> > fixed by Aleks' patches regarding HTX & headers were causing this issue in a
> > back-handed sort of way. I will apply those patches, establish that the
> > headers bug is fixed, and then try the recommendations from this bug to rule
> > out any interactions on that side (a badly written header in our situation
> > could result in a 404, which seemed to be the worst user-facing case of this
> > bug).
>
> Sure, let's address one problem at a time :-)
>
> Willy
publickey - luke.seelenbinder@stadiamaps.com - 0xB23C1E8A.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
