Pinging the list once again,
If atleast the below goes in, it would be possible to submit patches
to increase the coverage independently of the build patches. (I would
like to add more coverage in other interesting modules too.)
| - discussion on dtrace patches by Theo seems to have
Ruediger Pluem wrote:
+if (r-clength 0) {
+return r-clength;
+}
+else if (r-main == NULL || r-main == r) {
There are subrequests that have themselves as parent?
It's code from mod_jk. Can be overengineering.
But this does mean that the container receives a request,
-Ursprüngliche Nachricht-
Von: Mladen Turk
Gesendet: Freitag, 19. September 2008 11:18
An: dev@httpd.apache.org
Betreff: Re: svn commit: r696614 - in /httpd/httpd/trunk:
CHANGES modules/proxy/mod_proxy_ajp.c
Ruediger Pluem wrote:
Or does it simply error out without
Plüm, Rüdiger, VF-Group wrote:
Without the patch the container side will presume the next packet
(can be new request or ping) is first body packet.
So with the patch the connection to the container can be reused and
the state of the connection in the container is that it waits for a
new
-Ursprüngliche Nachricht-
Von: Mladen Turk
Gesendet: Freitag, 19. September 2008 11:45
An: dev@httpd.apache.org
Betreff: Re: svn commit: r696614 - in /httpd/httpd/trunk:
CHANGES modules/proxy/mod_proxy_ajp.c
Plüm, Rüdiger, VF-Group wrote:
Without the patch the container
Hi,
I've got a apache core file due to a crash from a 3rdparty module. But
the first thread shown in thread apply all bt full is this:
Core trace extracted from /usr/local/httpd/service/httpd/core.20252
follows:
Using host libthread_db library /lib/i686/nosegneg/libthread_db.so.1.
warning: Can't
-Ursprüngliche Nachricht-
Von: Vinay Y S
Gesendet: Freitag, 19. September 2008 12:48
An: dev@httpd.apache.org
Betreff: Understanding apache core traces
invoked). Is this expected behavior? Can I rely on the understanding
that the thread that has the sig_coredump handler
On 09/19/2008 11:24 PM, Adam Woodworth wrote:
Now that we're using 2.2.9 in the field, I've noticed a problem with
r657443, or at least it's a problem for our application.
r657443 added code to shutdown the connection w/o any response with an
EOC in the case that a second (or later) request
