https://bz.apache.org/bugzilla/show_bug.cgi?id=65402
--- Comment #11 from Florian Meister <f...@sfs.com> --- (In reply to Stefan Eissing from comment #9) > Ok, if the SSE source sends roughly every 30 seconds, this explains what I > see: > - the browser closes > - mod_http2 acknowledges, and marks the worker thread as being aborted > - the worker thread is in a blocking read and gets some data after 30 > seconds, detects the frontend connection is gone and terminates itself. To reproduce the behavior I have to navigate a few times through the web app (initiate route changes). When no route change happens (the event-sources are not destroyed and built up again) the app works as expected. > What I do not see is any "blocking" behaviour in the server. If you see a > request in the browser dev tools that is not answered, you should see the > URL of that request and then we can check if we see it in the server logs > and what is happening to it. Yes I can reproduce you a log with an exact (1s) time when the first request is "pending" in the browser and which one. FYI: I've also tried firefox to ensure it's not a browser problem. > For the SSE source requests, the browser will most likely show a "waiting" > status since the complete response is never received - as intended for the > SSE, right? Absolutely correct. The HTTP Headers are sent by the server with ContentType: text/eventstream. Then the response body never finishes (ideally. sometimes the request is canceled by the browser or through some other hardware/software inbetween). Maybe another helpful insight is that when using nginx it works (as already written). nginx has a lot more tcp connections to the backend in close/wait state. for some reason it seems that it finishes every tcp connection when a http request is finished and establish a new one. I've made no special configuration regarding keepalive, its the default config. Apache2 has much fewer connections in the backend and seems to reuse them - regardless if I enable or disable keepalive. I'll come back to you with the new logs. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org