PoCo::MQ 0.2.7 released!
David Snopek
I just pushed a 0.2.7 release to CPAN. It contains the fixes discussed here:
http://groups.google.com/group/pocomq/browse_thread/thread/72c91e36ac1beaf9
Which basically means the same old PoCo::MQ will continue to work with
the latest Moose and POE versions.
This should be hitting search.cpan.org and your local CPAN mirror soon!
Happy Hacking!
David Snopek.
Naveed
> Hello EVeryone!
>
> I just pushed a 0.2.7 release to CPAN. It contains the fixes discussed here:
>
>
> Which basically means the same old PoCo::MQ will continue to work with
> the latest Moose and POE versions.
>
> This should be hitting search.cpan.org and your local CPAN mirror soon!
>
> Happy Hacking!
> David Snopek.
Thanks for doing this. I'm really glad to see this project is active
again. But the tests still don't pass for me. I tried on an ubuntu
and a redhat machine. It fails on test t/08_removed_file.t. I get:
ok 1 - setup data dir
ok 2 - MQ started
ok 3 - messages sent
And then it just hangs. Any ideas?
David Snopek
[snip]
> Thanks for doing this. I'm really glad to see this project is active
> again. But the tests still don't pass for me. I tried on an ubuntu
> and a redhat machine. It fails on test t/08_removed_file.t. I get:
> ok 1 - setup data dir
> ok 2 - MQ started
> ok 3 - messages sent
>
> And then it just hangs. Any ideas?
Hrm. It would seem that it is having problems stopping the MQ that it
started to do the tests. I'm not sure what could cause this. My
machine is Debian Lenny and I don't experience this problem.
Basically after that line it does
(t/lib/Poe/Component/MessageQueue/Test/MQ.pm - line 54):
return (kill('TERM', $pid) == 1)
&& (waitpid($pid, 0) == $pid)
&& ($? == 0);
So, its got to be the waitpid() that its hanging on.
This may be related to POE now wanting us to do something with its
internal sig_child() handlers. I don't entirely understand what we
are supposed to do. If I can find the time, I'll look into it, but I
would definitely appreciate any assistance!
Thanks for the bug report!
Happy Hacking,
David Snopek.
Naveed
> 2010/1/23 Naveed <navee...@gmail.com>:
Yes, I think you are right that it has to do with sig_child(). When I
ctrl-c to kill the test after it hangs, I get the following:
6503: !!! Child process PID:6504 reaped:
6503: !!! Your program may not be using sig_child() to reap processes.
6503: !!! In extreme cases, your program can force a system reboot
6503: !!! if this resource leakage is not corrected.
Is this a POE thing? Should we be calling sig_child() somewhere?
David Snopek
Here are some POD docs:
http://search.cpan.org/~rcaputo/POE-1.284/lib/POE/Kernel.pm#sig_child_PROCESS_ID_[,_EVENT_NAME]
But I'm not sure what to do, exactly. The some of the tests fork()
after $poe_kernel has been initialized, so POE was spitting out errors
about can calling $poe_kernel->has_forked(). So, I just threw a call
to it in there, it didn't hurt anything on my system but added those
warnings about needing to call sig_child().
Its very possible that this was a mistake, and we shouldn't be calling
has_forked() but doing something else entirely. One possibility is
trying to prevent POE from being initialized before we fork(). The
other option is calling $poe_kernel->stop(), per the documentation
given here:
http://search.cpan.org/~rcaputo/POE-1.284/lib/POE/Kernel.pm#has_forked
Since it doesn't affect my system, could you try removing the
$poe_kernel->has_forked() lines from the tests and running them again?
Let me know if it still hangs. An interim fix would be just removing
the has_forked() forked call because it might be more trouble than its
worth.
When I have some spare time I'll do some research and try to figure
out what the right thing to do is.
Thanks,
David Snopek.
Naveed
On Jan 25, 7:33 am, David Snopek <dsno...@gmail.com> wrote:
> 2010/1/25 Naveed <navee...@gmail.com>:
> http://search.cpan.org/~rcaputo/POE-1.284/lib/POE/Kernel.pm#sig_child...[,_EVENT_NAME]
>
> But I'm not sure what to do, exactly. The some of the tests fork()
> after $poe_kernel has been initialized, so POE was spitting out errors
> about can calling $poe_kernel->has_forked(). So, I just threw a call
> to it in there, it didn't hurt anything on my system but added those
> warnings about needing to call sig_child().
>
> Its very possible that this was a mistake, and we shouldn't be calling
> has_forked() but doing something else entirely. One possibility is
> trying to prevent POE from being initialized before we fork(). The
> other option is calling $poe_kernel->stop(), per the documentation
> given here:
>
> http://search.cpan.org/~rcaputo/POE-1.284/lib/POE/Kernel.pm#has_forked
>
> Since it doesn't affect my system, could you try removing the
> $poe_kernel->has_forked() lines from the tests and running them again?
> Let me know if it still hangs. An interim fix would be just removing
> the has_forked() forked call because it might be more trouble than its
> worth.
>
> When I have some spare time I'll do some research and try to figure
> out what the right thing to do is.
>
> Thanks,
> David Snopek.
I don't think removing has_forked() is the solution. When I do that,
I get the following, and then it just hangs after ok 7:
$ perl -Ilib t/08_removed_file.t
1..10
ok 1 - setup data dir
ok 2 - MQ started
ok 3 - messages sent
-----
Please address any warnings or errors above this message, and try
again. If there are none, or those messages are from within POE,
then please mail them along with the following information
to bug...@rt.cpan.org:
---
<sg> Kernel now running in a different process (is=29781 was=29779).
You must call call $poe_kernel->has_forked in the child process.
-----
at /usr/local/share/perl/5.10.0/POE/Resource/Signals.pm line 793
POE::Kernel::_data_sig_pipe_send('POE::Kernel', 'TERM') called
at /usr/local/share/perl/5.10.0/POE/Loop/PerlSignals.pm line 27
POE::Kernel::_loop_signal_handler_generic('TERM') called at /
usr/local/share/perl/5.10.0/POE/Loop/Select.pm line 199
eval {...} called at /usr/local/share/perl/5.10.0/POE/Loop/
Select.pm line 199
POE::Kernel::loop_do_timeslice('POE::Kernel=ARRAY(0x86be140)')
called at /usr/local/share/perl/5.10.0/POE/Loop/Select.pm line 323
POE::Kernel::loop_run('POE::Kernel=ARRAY(0x86be140)') called
at /usr/local/share/perl/5.10.0/POE/Kernel.pm line 1276
POE::Kernel::run('POE::Kernel=ARRAY(0x86be140)') called at t/
lib/POE/Component/MessageQueue/Test/MQ.pm line 51
POE::Component::MessageQueue::Test::MQ::start_mq('FileSystem')
called at t/08_removed_file.t line 27
not ok 4 - MQ shut down
# Failed test 'MQ shut down'
# at t/08_removed_file.t line 39.
ok 5 - 100 messages stored
ok 6 - 20 messages removed
ok 7 - MQ restarted
Naveed
> 2010/1/25 Naveed <navee...@gmail.com>:
>
> But I'm not sure what to do, exactly. The some of the tests fork()
> after $poe_kernel has been initialized, so POE was spitting out errors
> about can calling $poe_kernel->has_forked(). So, I just threw a call
> to it in there, it didn't hurt anything on my system but added those
> warnings about needing to call sig_child().
>
> Its very possible that this was a mistake, and we shouldn't be calling
> has_forked() but doing something else entirely. One possibility is
> trying to prevent POE from being initialized before we fork(). The
> other option is calling $poe_kernel->stop(), per the documentation
> given here:
>
> http://search.cpan.org/~rcaputo/POE-1.284/lib/POE/Kernel.pm#has_forked
>
> Since it doesn't affect my system, could you try removing the
> $poe_kernel->has_forked() lines from the tests and running them again?
> Let me know if it still hangs. An interim fix would be just removing
> the has_forked() forked call because it might be more trouble than its
> worth.
>
> When I have some spare time I'll do some research and try to figure
> out what the right thing to do is.
>
> Thanks,
> David Snopek.
Another possibility might be to use this module:
http://search.cpan.org/~rcaputo/POE-1.284/lib/POE/Wheel/Run.pm
Naveed
David Snopek
please try the attached patch? Its against 0.2.7, so you will have to
undo any changes you made to the source for it to apply cleanly.
It removes $poe_kernel->has_forked() and replaces it with a solution
involving $poe_kernel->stop(). On my system is doesn't cause any
problems (of course, none of these things caused any problems on my
system!) but it also doesn't give me any POE warnings.
I'd really like to fix this and do another release. As soon as
someone can tell me if this helps, I'll push one out.
Thank you!
David Snopek.
2010/1/26 Naveed <nave...@gmail.com>:
David Snopek
Unfortunately, POE::Wheel::Run won't help in our case, because we
aren't fork()'ing from inside of POE, in fact, POE isn't even running
when we fork(), its just initialized. So, we just need a way to make
POE happy, fork()'ing after initializing, but before run()'ing. I
think $poe_kernel->stop() is the way to do this but I need someone to
test the patch in my previous e-mail.
David Snopek
to hear from anyone else who was having it as well. In any case, I
will be rolling a new release shortly.
2010/1/26 David Snopek <dsn...@gmail.com>:
Naveed
> I have one confirmation that this patch fixes the problem! I'd love
> to hear from anyone else who was having it as well. In any case, I
> will be rolling a new release shortly.
>
I am happy to report that your patch makes all the tests pass for me
as well :)
Naveed