Re: [OT] A couple of dubious network problems...
Mark Maunder <[EMAIL PROTECTED]> 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 Hirehttp://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...
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
[OT] A couple of dubious network problems...
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