Skip Menu |

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 37113
Status: resolved
Priority: 0/
Queue: POE

People
Owner: Nobody in particular
Requestors: NUFFIN [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Wishlist: A way to stop sessions
Currently there is no way to stop a session cleanly. The reasons for doing this involve shutting down a specific session and it's subsessions if they are misbehaving, and freeing the resources they use, when it does not provide an API to be shutdown or if it's internal state is buggy. Currently POE::NFA and POE::Component::Supervisor would benefit from this functionality. For POE::Component::Supervisor this is required to ensure that a component can be restarted after crashing. Currently POCO::Supervisor violates POE's internals by using an private api to accomplish this. The code I use right now is: my @sessions; my $peek = POE::API::Peek->new; while ( my $s = shift @roots ) { push @roots, $peek->get_session_children($s); push @sessions, $s; } foreach my $session ( reverse @sessions ) { $kernel->_data_ses_stop( $session ); } (@roots is the list of sessions to stop). This does a fairly good job of cleaning up stuck grandchildren. For instance, when POE::Component::Server::JSONRPC crashes due to e.g. an uncought exception, and needs to be restarted, its nested POE::Component::Server::TCP session needs to be cleaned up to free the socket as well. This code does the trick.
On Thu Jun 26 03:14:39 2008, NUFFIN wrote: Show quoted text
> Currently there is no way to stop a session cleanly.
From outside that session, that is. If you do control the code there you need to get the refcount down somehow but this is less of a problem. This API would still be useful to clean up if things seem to be wrong though.
On Thu Jun 26 03:27:38 2008, NUFFIN wrote: Show quoted text
> On Thu Jun 26 03:14:39 2008, NUFFIN wrote:
> > Currently there is no way to stop a session cleanly.
> > From outside that session, that is.
I know we discussed this somewhat on IRC, but I don't recall whether I asked: From the usage standpoint, how is a stop_another_session() method better than throwing a terminal (or non-maskable) signal? For example, you could say: $_[KERNEL]->signal($other_session, "KILL"); Or "UIDESTROY" if you want the death to be unequivocal.
$kernel->signal($session, "KILL") seems to provide a way to kill a session. Please reopen the ticket with an explanation if this isn't quite what you're looking for.