https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
Yann Ylavic changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #13 from Konstantin J. Chernov ---
(In reply to Yann Ylavic from comment #12)
> With MPM worker, pipelined responses are not flushed (up to five)
Well, that explains everything, thank you :)
Is that behavior considered correct?
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #12 from Yann Ylavic ---
The file req_test.txt contains two trailing bytes (one SP and one CR) which
httpd considers as the next incomplete/pipelined request.
With MPM worker, pipelined responses are not flushed (up to five), and s
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #11 from Konstantin J. Chernov ---
Created attachment 35840
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35840&action=edit
Information needed to reproduce the bug
Attached file test_result.zip.
httpd.test.conf + test.con
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #10 from Konstantin J. Chernov ---
> can't it be related to bug 61786 (i.e. does it still happen with the APR
> patch from there)?
I don't see how can it be related.
The issue described here only appears on worker mpm (when apache
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #9 from Yann Ylavic ---
Hi Konstantin,
can't it be related to bug 61786 (i.e. does it still happen with the APR patch
from there)?
If the MPM event wakeup code is buggy (per this other bug report), flushing
data to the client migh
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #8 from Konstantin J. Chernov ---
(In reply to Rainer Jung from comment #6)
> I don't see the 9 seconds in this example. Start at 16:31:19 (Apache), end
> at 16:31:19 (Tomcat). So the same second?
[02/Apr/2018:16:31:19 +0300] [127.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #7 from Rainer Jung ---
Is it possible to provide
- "LogLevel trace8" logs for a reproduction
- more config details and a smaller reproduction scenario? For instance you are
using Tomcat as a proxy backend, but does it also happen
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #6 from Rainer Jung ---
(In reply to Konstantin J. Chernov from comment #4)
> I aborted the request (on the client) after retreiving a pstack. I can wait
> for 30s (Timeout value) if that matters.
>
> Here's the access.log entry:
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #5 from Konstantin J. Chernov ---
After digging a bit deeper, I found out that 2.4.33 was built with worker mpm
(my fault, I guess :)), and 2.4.29 was on event mpm.
Recompiled 2.4.33 with event mpm and the behavior changed -- the c
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #4 from Konstantin J. Chernov ---
I aborted the request (on the client) after retreiving a pstack. I can wait for
30s (Timeout value) if that matters.
Here's the access.log entry:
[02/Apr/2018:16:31:19 +0300] [127.0.0.1]=>[127.0.0.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #3 from Eric Covener ---
Comment on attachment 35834
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35834
pstack #1
weird, they're all reading line-based data and no proxy in any stack. Are you
sure it was still hung/runnin
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
Konstantin J. Chernov changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
--- Comment #2 from Konstantin J. Chernov ---
Created attachment 35834
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35834&action=edit
pstack #1
Attached pstack.21515.
According to access.log the request was handled by pid 21515:tid
https://bz.apache.org/bugzilla/show_bug.cgi?id=62249
Eric Covener changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Eric Coven
15 matches
Mail list logo
