Skip Menu |
 

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 15264
Status: rejected
Priority: 0/
Queue: POE

People
Owner: Nobody in particular
Requestors: aldem-poe [...] aldem.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.3202
Fixed in: (no value)



Subject: POE::Wheel::ReadWrite sometimes didn't free resources
Download (untitled) / with headers
text/plain 1.5k
POE-0.3202; Perl 5.8.0 & 5.8.6; SuSE Linux 8.2 (Kernel 2.4.20) & 9.3 (kernel 2.6.11). The problem: during intensive handling of network connections, processed by Wheel::ReadWrite (bound to socket), sessions didn't stop after ErrorEvent is fired (actually, this is normal "connection closed" event, i.e. ErrorEvent with args 'read' and error code 0). Normally, this event occurs when client closes the connection, but sometimes, _very_ seldom, it happens "by itself" - no idea why. This problem is extremely difficult to reproduce - it could take thousands of requests with high concurrency before the problem appears. I tried to forge a quick-fix, which does the trick - problem disappears. Not sure if I did right thing, but... below is the patch against POE/Wheel/ReadWrite.pm: --- ReadWrite.pm~ 2005-10-24 15:06:06.000000000 +0200 +++ ReadWrite.pm 2005-10-24 15:06:06.000000000 +0200 @@ -186,6 +186,7 @@ $me, $$event_error, 'write', ($!+0), $!, $unique_id ); $k->select_write($handle); + $k->select_read($handle); } # Could write, or perhaps couldn't but only because the @@ -286,6 +287,7 @@ $me, $$event_error, 'read', ($!+0), $!, $unique_id ); $k->select_read($handle); + $k->select_write($handle); } } ); @@ -314,6 +316,7 @@ $me, $$event_error, 'read', ($!+0), $!, $unique_id ); $k->select_read($handle); + $k->select_write($handle); } } );
Download (untitled) / with headers
text/plain 2.1k
I'm not sure this is the right thing to do. A Wheel::ReadWrite could receive a read error 0 when the remote end of a socket calls shutdown() rather than a full close. In this case, stopping the writer means that the local end of the socket cannot flush its buffer. A better idea would be to find out why DESTROY isn't being called when your error handler destroys the Wheel::ReadWrite object. DESTROY contains code to totally clean up the wheel, and triggering it should release your socket. -- Rocco On Mon Oct 24 10:58:45 2005, guest wrote: Show quoted text
> POE-0.3202; Perl 5.8.0 & 5.8.6; SuSE Linux 8.2 (Kernel 2.4.20) & 9.3 > (kernel 2.6.11). > > The problem: during intensive handling of network connections, > processed by Wheel::ReadWrite (bound to socket), sessions didn't > stop after ErrorEvent is fired (actually, this is normal > "connection closed" event, i.e. ErrorEvent with args 'read' and > error code 0). Normally, this event occurs when client closes the > connection, but sometimes, _very_ seldom, it happens "by itself" - > no idea why. > > This problem is extremely difficult to reproduce - it could take > thousands of requests with high concurrency before the problem > appears. > I tried to forge a quick-fix, which does the trick - problem > disappears. Not sure if I did right thing, but... below is the > patch against POE/Wheel/ReadWrite.pm: > > --- ReadWrite.pm~ 2005-10-24 15:06:06.000000000 +0200 > +++ ReadWrite.pm 2005-10-24 15:06:06.000000000 +0200 > @@ -186,6 +186,7 @@ > $me, $$event_error, 'write', ($!+0), $!, $unique_id > ); > $k->select_write($handle); > + $k->select_read($handle); > } > > # Could write, or perhaps couldn't but only because the > @@ -286,6 +287,7 @@ > $me, $$event_error, 'read', ($!+0), $!, $unique_id > ); > $k->select_read($handle); > + $k->select_write($handle); > } > } > ); > @@ -314,6 +316,7 @@ > $me, $$event_error, 'read', ($!+0), $!, $unique_id > ); > $k->select_read($handle); > + $k->select_write($handle); > } > } > );
Download (untitled) / with headers
text/plain 142b
Ticket rejected. Haven't been able to reproduce it, so I can't fix it. The offered solution broke shutdown() semantics and couldn't be used.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.