[OT] A couple of dubious network problems...

[Dave Hodgkinson <da...@davehodgkinson.com>]

Chaps,

Can I pick the wisdom of the hive here please? I witnessed a couple of
mod_perl related network problems yesterday which are kind of mod_perl
related:

1. On a RH6.0 (yes, ick) box without persistent DBI connections, the
server side of the DBD::mysql connection was successfully closed
(netstat shows nothing), but the client side shows a TIME_WAIT state,
which hangs around for 30 seconds or so before
disappearing. Obviously, using Apache::DBI makes this go away, but
it's disturbing nonetheless. Does this ring any bells?

2. On both RH6 (in the office) and Solaris (at the co-lo) with a
middling-recent Apache and mod_perl, some pages were getting truncated
when sent to the browser. This happens on a variety of browsers and a
variety of pages. Once it happens on a particular combination of page
and browser it's reproducible. Now, the page is definitely being
completely sent to $r-print(), but it's not making it to the browser
(or at least that's what tcpdump shows). Again, any bells ringing?

Thanks,

Dave

Re: [OT] A couple of dubious network problems...

[Dave Hodgkinson <da...@davehodgkinson.com>]

Mark Maunder <ma...@swiftcamel.com> writes:

> Dave Hodgkinson wrote:
> 
> > 1. On a RH6.0 (yes, ick) box without persistent DBI connections, the
> > server side of the DBD::mysql connection was successfully closed
> > (netstat shows nothing), but the client side shows a TIME_WAIT state,
> > which hangs around for 30 seconds or so before
> > disappearing. Obviously, using Apache::DBI makes this go away, but
> > it's disturbing nonetheless. Does this ring any bells?
> 
> Dunno about number 2, but 1 is perfectly normal. TIME_WAIT is a condition
> the OS puts a closed socket into to prevent another app from using the
> socket, just in case the peer host has any more packets to send to that
> port. The host that closes the socket will put the old socket into
> TIME_WAIT. BSD IP stack implementations keep sockets in time_wait for
> about 30 seconds, others go up to 2 minutes. The duration is called 2MSL
> (2 * max_segment_lifetime). Don't worry about it and dont mess with it
> (unless you're consuming 64000+ sockets per 30 seconds, in which case you
> have other problems to deal with ;-)

Does SO_REUSEADDR make this go away?

-- 
David Hodgkinson, Wizard for Hire        http://www.davehodgkinson.com
Editor-in-chief, The Highway Star           http://www.deep-purple.com
Deep Purple Family Tree news                  http://www.slashrock.com
   Interim Technical Director, Web Architecture Consultant for hire

Re: [OT] A couple of dubious network problems...

[Mark Maunder <ma...@swiftcamel.com>]

Dave Hodgkinson wrote:

> 1. On a RH6.0 (yes, ick) box without persistent DBI connections, the
> server side of the DBD::mysql connection was successfully closed
> (netstat shows nothing), but the client side shows a TIME_WAIT state,
> which hangs around for 30 seconds or so before
> disappearing. Obviously, using Apache::DBI makes this go away, but
> it's disturbing nonetheless. Does this ring any bells?

Dunno about number 2, but 1 is perfectly normal. TIME_WAIT is a condition
the OS puts a closed socket into to prevent another app from using the
socket, just in case the peer host has any more packets to send to that
port. The host that closes the socket will put the old socket into
TIME_WAIT. BSD IP stack implementations keep sockets in time_wait for
about 30 seconds, others go up to 2 minutes. The duration is called 2MSL
(2 * max_segment_lifetime). Don't worry about it and dont mess with it
(unless you're consuming 64000+ sockets per 30 seconds, in which case you
have other problems to deal with ;-)

~mark