2.0: Last request in a keepalive causes "URI too long" in log

["Jeffrey W. Baker" <jw...@acm.org>]

Howdy,

I downloaded from-cvs 2.0 sources today to take a whack at writing an
Apache 2.0 module.  I found that when I make keep-alive requests,
closing the socket from the client side generates a "URI too long"
message in the apache_error_log.  This is with the mpm-thread-linux
build option.  A good way to demonstrate the problem is "ab -n 100 -c 5
-k http://localhost:8080/index.html".  ap_bgets seems to get 8192 null
characters from read_with_errors, which generates the error in
read_request_line.

But I was expecting a lot of problems with this code.  What I really
want to know is how people are debugging this beast, on Linux
particularly.  What tools do I need to step through threaded code?  I
realize this is basic but I honestly haven't found a lot of useful
information on the subject.  When I try to attach to a thread with GDB,
the thread becomes defunct.  When I try to attach to a parent process,
all of the threads become detached.

Shall I use a dreaded snapshot version of GDB?

Cheers,
Jeffrey

Re: 2.0: Last request in a keepalive causes "URI too long" in log

["Jeffrey W. Baker" <jw...@acm.org>]

rbb@apache.org wrote:
> 
> > Apache 2.0 module.  I found that when I make keep-alive requests,
> > closing the socket from the client side generates a "URI too long"
> > message in the apache_error_log.  This is with the mpm-thread-linux
> > build option.  A good way to demonstrate the problem is "ab -n 100 -c 5
> > -k http://localhost:8080/index.html".  ap_bgets seems to get 8192 null
> > characters from read_with_errors, which generates the error in
> > read_request_line.
> >
> > But I was expecting a lot of problems with this code.  What I really
> > want to know is how people are debugging this beast, on Linux
> > particularly.  What tools do I need to step through threaded code?  I
> > realize this is basic but I honestly haven't found a lot of useful
> > information on the subject.  When I try to attach to a thread with GDB,
> > the thread becomes defunct.  When I try to attach to a parent process,
> > all of the threads become detached.
> >
> > Shall I use a dreaded snapshot version of GDB?
> 
> Which mpm are you using?  There are two threaded MPM's on Unix,
> mpmt_pthread and dexter.

mpmt_pthread.  ./configure --with-option=common,mpm-pthread-linux

As you suggest I tried the same thing with prefork.  The symptom is
different but the underlying problem is the same.  I can probably send a
patch soon.

Is there read access to a CVS tree somewhere?

-jwb

Re: 2.0: Last request in a keepalive causes "URI too long" in log

[rb...@apache.org]

> Apache 2.0 module.  I found that when I make keep-alive requests,
> closing the socket from the client side generates a "URI too long"
> message in the apache_error_log.  This is with the mpm-thread-linux
> build option.  A good way to demonstrate the problem is "ab -n 100 -c 5
> -k http://localhost:8080/index.html".  ap_bgets seems to get 8192 null
> characters from read_with_errors, which generates the error in
> read_request_line.
> 
> But I was expecting a lot of problems with this code.  What I really
> want to know is how people are debugging this beast, on Linux
> particularly.  What tools do I need to step through threaded code?  I
> realize this is basic but I honestly haven't found a lot of useful
> information on the subject.  When I try to attach to a thread with GDB,
> the thread becomes defunct.  When I try to attach to a parent process,
> all of the threads become detached.
> 
> Shall I use a dreaded snapshot version of GDB?

Which mpm are you using?  There are two threaded MPM's on Unix,
mpmt_pthread and dexter.  I have yet to find a very good way to debug
threaded code on Linux.  GDB does work, but you have to be careful which
thread you debug, because one of the threads is a manager thread, and
debugging it is useless.  The other method is fprintf's in the code to
stderr.  Or, try using the prefork MPM run in single-process mode.  Most
of the code is common between MPM's, so debugging a protocol error in the
prefork MPM will usually also fix the problem in other MPM's.

Ryan


Come to the first official Apache Software Foundation
Conference!!!   <http://ApacheCon.Com/>

_______________________________________________________________________________
Ryan Bloom                        	rbb@ntrnet.net
2121 Stonehenge Dr. Apt #3
Raleigh, NC 27615		Ryan Bloom -- thinker, adventurer, artist,
				     writer, but mostly, friend.
-------------------------------------------------------------------------------