Hi! Thanks for that input. I would like to understand what's going before making changes. :)
Cheers, Daniel > On 24. Aug 2018, at 00:56, Igor Cicimov <ig...@encompasscorporation.com> > wrote: > > Hi Daniel, > > We had similar issue in 2015, and the answer was: server timeout was too > short. Simple. > > On Thu, 23 Aug 2018 9:56 pm Daniel Schneller > <daniel.schnel...@centerdevice.com > <mailto:daniel.schnel...@centerdevice.com>> wrote: > Friendly bump. > I'd volunteer to do some documentation amendments once I understand the issue > better :D > >> On 21. Aug 2018, at 16:17, Daniel Schneller >> <daniel.schnel...@centerdevice.com >> <mailto:daniel.schnel...@centerdevice.com>> wrote: >> >> Hi! >> >> I am trying to wrap my head around an issue we are seeing where there are >> many HTTP 504 responses sent out to clients. >> >> I suspect that due to a client bug they stop sending data midway during the >> data phase of the request, but they keep the connection open. >> >> What I see in the haproxy logs is a 504 response with termination flags >> "sHNN". >> That I read as haproxy getting impatient (timeout server) waiting for >> response headers from the backend. The backend, not having seen the complete >> request yet, can't really answer at this point, of course. >> I am wondering though, why it is that I see the I don't see a termination >> state indicating a client problem. >> >> So my question (for now ;-)) boils down to these points: >> >> 1) When does the server timeout actually start counting? Am I right to >> assume it is from the last moment the server sent or (in this case) received >> some data? >> >> 2) If both "timeout server" and "timeout client" are set to the same value, >> and the input stalls (after the headers) longer than that, is it just that >> the implementation is such that the server side timeout "wins" when it comes >> to setting the termination flags? >> >> 3) If I set the client timeout shorter than the server timeout and produced >> this situation, should I then see a cD state? If so, would I be right to >> assume that if the server were now to stall, the log could again be >> misleading in telling me that the client timeout expired first? >> >> I understand it is difficult to tell "who's to blame" for an inactivity >> timeout without knowledge about the content or final size of the request -- >> I just need some clarity on how the read the logs :) >> >> >> Thanks! >> Daniel >> >> >> >> >> -- >> Daniel Schneller >> Principal Cloud Engineer >> >> CenterDevice GmbH >> Rheinwerkallee 3 >> 53227 Bonn >> www.centerdevice.com <http://www.centerdevice.com/> >> >> __________________________________________ >> Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina, Michael Rosbach, >> Handelsregister-Nr.: HRB 18655, HR-Gericht: Bonn, USt-IdNr.: DE-815299431 >> >> Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche >> und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige >> Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie >> bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter >> Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. >> beigefügter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht >> gestattet. >> >> >
signature.asc
Description: Message signed with OpenPGP
