On Fri, Jan 10, 2003 at 07:06:42PM -0600, Bob Maccione wrote:
> ok, we're just rolling out a really neat replacement for init (at the
> application level) (picture of the screen here:
> http://www.sierraworks.net/tmp/Init.jpg)
That looks amazing. Can I cite it on poe.perl.org?
> My problem is now how do I make it really really stable?
>
> The issues are:
>
> 1: should I wrap each Session->New() in an eval to make sure I can create a
> session when I need too?
>
> reason: could not make stderr pipes: Bad file number at Procs.pm line 544
>
> Of course the error message doesn't tell me what happened, it could have
> been anything. The line of code is a simple Wheel::Run->New().
EBADF indicates that a syscall is receiving a bad file number
somewhere. The actual error is happening in either POE::Pipe or
POE::Pipe::OneWay, but I haven't been able to track it down so far.
The Pipe classes are a maze of twisty work-arounds, all different.
It's just really hard to build a pipe that works everywhere.
If you can make a test case that lets me recreate the problem, I'm
positive it can be fixed. If you've got the resources to look into it
in more detail, you can turn on the DEBUG flags in POE::Pipe and
POE::Pipe::OneWay. Unfortunately those options create copious console
crud.
In the meantime, there's a POE::Exceptions module on the CPAN. It
creates POE::Session instances where event handlers are run under
eval{}. If a session dies for any reason, the death is re-thrown as a
"DIE" signal that can be caught and handled. ARG0 is the message or
object thrown with die().
This incomplete, untested sample creates a session that retries
spawning something until it happens.
POE::Session::Exception->create(
inline_states => {
_start => sub {
$_[KERNEL]->yield("create_wheel");
$_[KERNEL]->sig('DIE','caught_die');
},
caught_die => sub {
if ($_[ARG0] =~ /could not make stderr pipes/) {
$_[KERNEL]->delay(create_wheel => 1);
}
# otherwise shut down?
},
create_wheel => sub {
POE::Wheel::Run->new(...);
}
}
);
I suspect that wrapping a POE::Session constructor call in eval{} will
be dangerous. On error, the stack will be unwound through
POE::Kernel's event dispatcher, which may leave data structures in an
inconsistent state. If you do experiment with it, be sure to have
ASSERT_DEFAULT turned on.
> 2: I'm getting accept errors that is killing the Component::Server::HTTP and
> it happens when you click too fast on the web page, the browser will just
> drop the connections and causes the Component to die. I guess I could run
> the Component::Server::HTTP from yet another session but that seems like
> overkill
PoCo::Server::HTTP uses Server::TCP internally, and Server::TCP shuts
down on error by default. I've committed a change to Server::TCP that
ignores ECONNABORTED, since it's potentially a common problem and
shouldn't kill off servers so easily.
> Any other suggestions for making the app solid (from a POE point of view)
> would be most appriciated...
POE::Wheel::Run is a weak spot in error checking and reporting. Part
of it is the difficulty of creating a new process-- building pipes and
things we've already established can be hard. Part of it is the
difficulty in passing child-process errors back to the parent for
reporting in the main program.
The type of program you're working on gives you a better environment
for beating on and improving Wheel::Run. I'd appreciate any patches
or advice you can provide on it.
-- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
