Hello, here is the relevant commit: https://github.com/icing/mod_h2/commit/51085e0c26da1f47ea9cf91930af8cef0dececb9
Stefan Excuse my typo sent from my mobile phone. > Am 02.12.2017 um 14:39 schrieb Stefan Priebe - Profihost AG > <s.pri...@profihost.ag>: > > Hello Luca, > > It’s a problem with the limited fifo queue size of http2. > > Stefan send me a workaround not sure if this one will go into http2 or if he > will release a real fix soon. > > Greets, > Stefan > > Excuse my typo sent from my mobile phone. > >> Am 02.12.2017 um 09:23 schrieb Luca Toscano <toscano.l...@gmail.com>: >> >> Hi everybody, >> >> did I miss an update or are we still waiting for more data? (Don't mean to >> rush you Stefan, just to understand what's the status of the thread :) >> >> Luca >> >> 2017-11-24 15:26 GMT+01:00 Stefan Priebe - Profihost AG >> <s.pri...@profihost.ag>: >>> Thanks i‘ll post a log tonight with a 120s stalled request. >>> >>> Greets, >>> Stefan >>> >>> Excuse my typo sent from my mobile phone. >>> >>>> Am 23.11.2017 um 17:09 schrieb Stefan Eissing >>>> <stefan.eiss...@greenbytes.de>: >>>> >>>> Hey, >>>> >>>> could you try the patch below and produce such a lovely log file again? >>>> H2MaxWorkers please back to before, unconfigured. Thanks! This is a small >>>> change that a) logs the interaction with h2_workers a bit more and makes >>>> sure that time gets lost where I think it does. It also switches the fifo >>>> queue in set mode where duplicate entries are checked, in case that >>>> interferes here. >>>> >>>> Cheers, >>>> >>>> Stefan >>>> >>>> <h2worker_register-v0.diff> >>>> >>>> >>>>> Am 23.11.2017 um 14:16 schrieb Stefan Priebe - Profihost AG >>>>> <s.pri...@profihost.ag>: >>>>> >>>>> Hi, >>>>>> Am 23.11.2017 um 14:10 schrieb Stefan Eissing: >>>>>> Interesting. I assume that otherwise this host is the same (OS/CPU etc.) >>>>>> as others where it runs without probs? >>>>> >>>>> Yes and no i got some more reports by colleagues where they've disabled >>>>> http2 as the customers had unexpected long loading times. >>>>> >>>>>> We are not ghosted by some strange blabla-lake hyper threading thingie >>>>>> singularity? >>>>> >>>>> Huhoh what's that? Any chance to add some more debugging? >>>>> >>>>> Greets, >>>>> Stefan >>>>> >>>>>> >>>>>> Need to think about this. >>>>>> >>>>>>> Am 23.11.2017 um 13:43 schrieb Stefan Priebe - Profihost AG >>>>>>> <s.pri...@profihost.ag>: >>>>>>> >>>>>>> *argh*, i was too fast no it did NOT fix the problem. It even happens >>>>>>> with: >>>>>>> H2MaxWorkers 4096 >>>>>>> >>>>>>> Sorry about that. >>>>>>> >>>>>>> Stefan >>>>>>> >>>>>>>> Am 23.11.2017 um 13:42 schrieb Stefan Priebe - Profihost AG: >>>>>>>> Hello,, >>>>>>>> >>>>>>>> setting: >>>>>>>> H2MaxWorkers 1024 >>>>>>>> >>>>>>>> fixes the issue for me. The main problem is how to i know how many >>>>>>>> workers are needed? How can i detect whether all workers of h2 are >>>>>>>> busy? >>>>>>>> >>>>>>>> Stefan >>>>>>>> >>>>>>>>> Am 22.11.2017 um 13:23 schrieb Stefan Priebe - Profihost AG: >>>>>>>>> Hell Stefan, >>>>>>>>> >>>>>>>>> will send a log to you in a few seconds via private email. >>>>>>>>> >>>>>>>>> Greets, >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>>> Am 21.11.2017 um 23:18 schrieb Stefan Eissing: >>>>>>>>>> sorry for the late reply. for stucks trace2 is best. >>>>>>>>>> >>>>>>>>>>> Am 21.11.2017 um 19:35 schrieb Stefan Priebe - Profihost AG >>>>>>>>>>> <s.pri...@profihost.ag>: >>>>>>>>>>> >>>>>>>>>>> Hello Stefan, >>>>>>>>>>> >>>>>>>>>>> which loglevel do you need? trace2? >>>>>>>>>>> >>>>>>>>>>> Greets, >>>>>>>>>>> Stefan >>>>>>>>>>> >>>>>>>>>>>> Am 21.11.2017 um 16:48 schrieb Stefan Eissing: >>>>>>>>>>>> Never done this, but https://www.howtoforge.com/setenvif_apache2 >>>>>>>>>>>> seems like one way to do make it work. >>>>>>>>>>>> >>>>>>>>>>>>> Am 21.11.2017 um 16:16 schrieb Stefan Priebe - Profihost AG >>>>>>>>>>>>> <s.pri...@profihost.ag>: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 21.11.2017 um 16:06 schrieb Stefan Priebe - Profihost AG: >>>>>>>>>>>>>>>> Am 21.11.2017 um 15:45 schrieb Stefan Eissing: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Am 21.11.2017 um 14:33 schrieb Stefan Priebe - Profihost AG >>>>>>>>>>>>>>>> <s.pri...@profihost.ag>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello Stefan, >>>>>>>>>>>>>>>> Hello Yann, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> me the http2 bug tester is calling again ;-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And the day was going so well... >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm sorry ;-) >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While running two bash curl while loops the one using http1.1 >>>>>>>>>>>>>>>> always >>>>>>>>>>>>>>>> finishes in < 0.05s while the http2 one takes sometimes 0.4 to >>>>>>>>>>>>>>>> 20s to >>>>>>>>>>>>>>>> finish. Sadly i can't reproduce this all the time - mostly >>>>>>>>>>>>>>>> more requests >>>>>>>>>>>>>>>> more failures. As this is a production server i've no idea how >>>>>>>>>>>>>>>> to debug >>>>>>>>>>>>>>>> as the http2 trace logs might flood the harddisk. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hmmm. Do you know if this happens waiting for a response or at >>>>>>>>>>>>>>> the end of a connection? Or in the middle of a body? All GETs >>>>>>>>>>>>>>> or also POSTs? >>>>>>>>>>>>>> >>>>>>>>>>>>>> My Test only contains GET - but most probably there are also >>>>>>>>>>>>>> running >>>>>>>>>>>>>> POST requests but not started by me. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Strangely this only happens between 1pm and 2pm a day but i've >>>>>>>>>>>>>> no idea >>>>>>>>>>>>>> what's different at that time. >>>>>>>>>>>>> >>>>>>>>>>>>> OK i'm also able to reproduce this whenever your want. Can we >>>>>>>>>>>>> activate >>>>>>>>>>>>> trace logging for a specific IP? So i can generate a http2 log? >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can output a lot of information from curl: >>>>>>>>>>>>>> time_namelookup >>>>>>>>>>>>>> time_connect >>>>>>>>>>>>>> time_appconnect >>>>>>>>>>>>>> time_pretransfer >>>>>>>>>>>>>> time_redirect >>>>>>>>>>>>>> time_starttransfer >>>>>>>>>>>>>> >>>>>>>>>>>>>> Another way might be to enable trace logging only for "my" IP? Is >>>>>>>>>>>>>> something like this possible? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Greets, >>>>>>>>>>>>>> Stefan >>>>>>>>>>>> >>>>>>>>>> >>>>>> >>>> >>
