Skip Menu |

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 4845
Status: resolved
Priority: 0/
Queue: POE
People
Owner: Nobody in particular
Requestors: sharding [...] ccbill.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Tue Jan 06 16:08:29 2004 sharding [...] ccbill.com - Ticket created
Subject: CLOSE_WAIT stuff
Date: Tue, 6 Jan 2004 14:08:22 -0700
From: "Shay Harding" <sharding [...] ccbill.com>
To: <bug-POE [...] rt.cpan.org>
Ok, not sure if this is a bug in POE or a bug in me. I included all the files I am testing with so you can see the behavior I am experiencing. I tried to identify any lingering references to the sockets or whatever, but my session stops as it should after it has nothing else to do. I assume that wouldn't happen if something was keeping it alive. I also did a Dumper(\%Heap) to make sure it has no weird references still hanging about. %Heap is my global heap outside of the POE kernel to use with the module. Basically the module is a re-write of POE::Component::Client::TCPMulti I found on CPAN. server.pl => binds to 127.0.0.1 : 3333 client.pl => uses the module I am working on to send data to server.pl code.pm => I had this symlinked to /tmp/modules/POE/Component/Client/MultiConnect.pm Start server.pl Run client.pl netstat -an will show a CLOSE_WAIT and FIN_WAIT2. The FIN_WAIT2 disappears after about 60 seconds. The CLOSE_WAIT never disappears. Not sure what else to do to get rid of the CLOSE_WAIT. Thanks, Shay Harding aka kellewic
  Mon Jan 12 01:40:03 2004 RCAPUTO [...] cpan.org - Correspondence added
It turns out that this is perfectly fine behavior under the current Server::TCP rules. In your test case, you specify ClientShutdownOnError => 0, which means Server::TCP will not automatically close the socket on error. That includes the read error 0 that signifies EOF on the socket. The two major ways to "resolve" this issue are (1) Say tough, it's your deal for turning that knob. It's up to you to shut down the client on the specific errors where it makes sense. (2) Decide that read error 0 isn't really an error, and patch Server::TCP to always shutdown on it. I've chosen #1 for now. It permits the greatest flexibility with the least general overhead. -- Rocco Caputo - rcaputo@pobox.com - http://poe.perl.org/
  Mon Jan 12 01:40:04 2004 RCAPUTO [...] cpan.org - Status changed from 'new' to 'resolved'