perl.poe http://www.nntp.perl.org/group/perl.poe/ ... Copyright 1998-2016 perl.org Mon, 27 Jun 2016 07:47:33 +0000 ask@perl.org Re: Trigger an event from outside an event handler by pablo baez El 29/03/16 a las 13:13, Rocco Caputo escribi&oacute;:<br/>&gt; POE::Kernel-&gt;post( $destination, &quot;event&quot;, @optional_args );<br/>&gt;<br/><br/>I found the answer a few minutes after posting my question here. Thank <br/>you very much though.<br/><br/>Regards,<br/><br/>Pablo<br/> http://www.nntp.perl.org/group/perl.poe/2016/03/msg5102.html Thu, 31 Mar 2016 13:49:43 +0000 Re: Trigger an event from outside an event handler by Rocco Caputo POE::Kernel-&gt;post( $destination, &quot;event&quot;, @optional_args ); <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>&gt; On Mar 29, 2016, at 10:25, pablo baez &lt;pab_24n@hotmail.com&gt; wrote: <br/>&gt; <br/>&gt; Hi, <br/>&gt; <br/>&gt; I&#39;m a POE newbie and looking at the documentation, I don&#39;t find a way to trigger an event of a specific session, from outside an event handler of that session. How can I do that? <br/>&gt; <br/>&gt; Thanks in advance. <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2016/03/msg5101.html Tue, 29 Mar 2016 16:13:19 +0000 Trigger an event from outside an event handler by pablo baez Hi,<br/><br/>I&#39;m a POE newbie and looking at the documentation, I don&#39;t find a way to <br/>trigger an event of a specific session, from outside an event handler of <br/>that session. How can I do that?<br/><br/>Thanks in advance.<br/> http://www.nntp.perl.org/group/perl.poe/2016/03/msg5100.html Tue, 29 Mar 2016 16:00:14 +0000 Re: [COMMERCIAL] POE and Activestate perlapp fail on MacOSX by Rocco Caputo Hi, Craig. <br/> <br/>According to http://code.activestate.com/lists/perl-tk/13841/ the error seems to be coming from within Tk, so it&#39;s understandable the tests without Tk would pass. <br/> <br/>That URL suggests calling Tk::exit() or $poe_main_window-&gt;destroy() after POE::Kernel-&gt;run() returns may solve the problem. I&#39;m inclined to believe it since the &quot;during global destruction&quot; implies that objects may be in the throes of out-of-order destruction. Ensuring a clean, orderly shutdown of Tk is probably a good thing in general. <br/> <br/>Since your test program isn&#39;t calling POE::Kernel-&gt;run(), just invoking $poe_main_window-&gt;destroy() or Tk::exit() at the end should be enough to see if it&#39;s going to help. <br/> <br/>The &quot;-e syntax OK&quot; suggests that the error is happening as a result of a &quot;perl -c&quot; check within PerlApp. Can you reproduce the error with just &quot;perl -c mactst.pl&quot;? <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>&gt; On Jan 5, 2016, at 08:42, Craig Votava &lt;craig.votava@alcatel-lucent.com&gt; wrote: <br/>&gt; <br/>&gt; Hi Rocco- <br/>&gt; <br/>&gt; The PerlMonks solution seems to be for a different problem on a different platform, but this is a good suggestion that yielded interesting results: <br/>&gt; <br/>&gt; Needed to comment out POE::Resource:Statistics (when did that go away?) <br/>&gt; The perlapp fails when &ldquo;use Tk;&rdquo; is uncommented <br/>&gt; The perlapp succeeds when &ldquo;use Tk;&rdquo; is commented out <br/>&gt; The perlapp succeeds when all the POE lines are commented out and the &ldquo;use Tk&rdquo; is uncommented. <br/>&gt; <br/>&gt; So maybe the PerlMonks solution isn&rsquo;t as far off as I thought. It looks like we have a perlapp-Tk-POE issue. <br/>&gt; <br/>&gt; What would be a good next step? <br/>&gt; <br/>&gt; Thanks <br/>&gt; -Craig <br/>&gt; <br/>&gt; #!/usr/local/ActivePerl-5.20/bin/perl <br/>&gt; use warnings; <br/>&gt; use strict; <br/>&gt; <br/>&gt; use Tk; <br/>&gt; <br/>&gt; use POE qw (Loop::TkActiveState); <br/>&gt; use POE::Loop::TkActiveState; <br/>&gt; use POE::Kernel; <br/>&gt; use POE::Session; <br/>&gt; use POE::Resource::Aliases; <br/>&gt; use POE::Resource::Events; <br/>&gt; use POE::Resource::Extrefs; <br/>&gt; use POE::Resource::FileHandles; <br/>&gt; use POE::Resource::Sessions; <br/>&gt; use POE::Resource::SIDs; <br/>&gt; use POE::Resource::Signals; <br/>&gt; #use POE::Resource::Statistics; <br/>&gt; <br/>&gt; if(! defined($poe_main_window)) { die &quot;\$poe_main_window not defined&quot; }; <br/>&gt; <br/>&gt; $ perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean --force --lib lib --exe mca mactst.pl <br/>&gt; PerlApp 9.4.0 build 298593 (perl 5.14.0) <br/>&gt; Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved. <br/>&gt; Commercial license S2EB72B1777B for Craig Votava &lt;Craig.Votava@alcatel-lucent.com &lt;mailto:Craig.Votava@alcatel-lucent.com&gt;&gt; <br/>&gt; <br/>&gt; -e syntax OK <br/>&gt; Free non-Callback 1032e2a88 RV=0 during global destruction. <br/>&gt; . (1): <br/>&gt; 0 0x103801558 IV f=00000001 undef(1) <br/>&gt; SV = IV(0x103801548) at 0x103801558 <br/>&gt; REFCNT = 1 <br/>&gt; FLAGS = () <br/>&gt; IV = 0 <br/>&gt; &#39;mactst.pl&#39; had compilation errors. <br/>&gt; <br/>&gt; <br/>&gt;&gt; On Jan 4, 2016, at 10:48 PM, Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt; Hi, Craig. <br/>&gt;&gt; <br/>&gt;&gt; The PerlMonks thread you quoted ends with a solution to the OP&#39;s problem. The mactst.pl you quoted doesn&#39;t seem to implement that solution, so my first recommendation would be to try that. <br/>&gt;&gt; <br/>&gt;&gt; -- <br/>&gt;&gt; Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt;&gt; On Jan 4, 2016, at 13:34, Craig Votava &lt;craig.votava@alcatel-lucent.com &lt;mailto:craig.votava@alcatel-lucent.com&gt;&gt; wrote: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Folks- <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; I&rsquo;m running Yosemite (MacOSX 10.10.5) on a MacPro (Mid 2010) and am trying to use ActiveState&rsquo;s perlapp to create an executable perl script. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; I have been successful in creating some perl scripts that don&rsquo;t use POE, however when I try a script using POE, I get the following error: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean --force --lib lib --exe mca mactst.pl <br/>&gt;&gt;&gt; PerlApp 9.4.0 build 298593 (perl 5.14.0) <br/>&gt;&gt;&gt; Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved. <br/>&gt;&gt;&gt; Commercial license S2EB72B1777B for Craig Votava &lt;Craig.Votava@alcatel-lucent.com &lt;mailto:Craig.Votava@alcatel-lucent.com&gt;&gt; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; -e syntax OK <br/>&gt;&gt;&gt; Free non-Callback 101ea3e08 RV=0 during global destruction. <br/>&gt;&gt;&gt; . (1): <br/>&gt;&gt;&gt; 0 0x104012158 IV f=00000001 undef(1) <br/>&gt;&gt;&gt; SV = IV(0x104012148) at 0x104012158 <br/>&gt;&gt;&gt; REFCNT = 1 <br/>&gt;&gt;&gt; FLAGS = () <br/>&gt;&gt;&gt; IV = 0 <br/>&gt;&gt;&gt; &#39;mactst.pl&#39; had compilation errors. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; The contents of mactst.pl is as follows: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; #!/usr/local/ActivePerl-5.20/bin/perl <br/>&gt;&gt;&gt; use warnings; <br/>&gt;&gt;&gt; use strict; <br/>&gt;&gt;&gt; use Tk; <br/>&gt;&gt;&gt; use POE; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; if(! defined($poe_main_window)) { die &quot;\$poe_main_window not defined&quot; }; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; This *MAY* have something to do with an issue about the POE::Loop that gets selected (read about it here &lt;http://www.perlmonks.org/?node_id=758312&gt;), but I&rsquo;m not sure. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; How can I debug this? <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Any help is much appreciated! <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Thanks <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; -Craig <br/>&gt;&gt;&gt; <br/>&gt;&gt; <br/>&gt; <br/> http://www.nntp.perl.org/group/perl.poe/2016/01/msg5099.html Tue, 05 Jan 2016 14:24:55 +0000 Re: [COMMERCIAL] POE and Activestate perlapp fail on MacOSX by Craig Votava Hi Rocco- <br/> <br/>The PerlMonks solution seems to be for a different problem on a different platform, but this is a good suggestion that yielded interesting results: <br/> <br/>Needed to comment out POE::Resource:Statistics (when did that go away?) <br/>The perlapp fails when &ldquo;use Tk;&rdquo; is uncommented <br/>The perlapp succeeds when &ldquo;use Tk;&rdquo; is commented out <br/>The perlapp succeeds when all the POE lines are commented out and the &ldquo;use Tk&rdquo; is uncommented. <br/> <br/>So maybe the PerlMonks solution isn&rsquo;t as far off as I thought. It looks like we have a perlapp-Tk-POE issue. <br/> <br/>What would be a good next step? <br/> <br/>Thanks <br/>-Craig <br/> <br/>#!/usr/local/ActivePerl-5.20/bin/perl <br/>use warnings; <br/>use strict; <br/> <br/>use Tk; <br/> <br/>use POE qw (Loop::TkActiveState); <br/>use POE::Loop::TkActiveState; <br/>use POE::Kernel; <br/>use POE::Session; <br/>use POE::Resource::Aliases; <br/>use POE::Resource::Events; <br/>use POE::Resource::Extrefs; <br/>use POE::Resource::FileHandles; <br/>use POE::Resource::Sessions; <br/>use POE::Resource::SIDs; <br/>use POE::Resource::Signals; <br/>#use POE::Resource::Statistics; <br/> <br/>if(! defined($poe_main_window)) { die &quot;\$poe_main_window not defined&quot; }; <br/> <br/>$ perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean --force --lib lib --exe mca mactst.pl <br/>PerlApp 9.4.0 build 298593 (perl 5.14.0) <br/>Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved. <br/>Commercial license S2EB72B1777B for Craig Votava &lt;Craig.Votava@alcatel-lucent.com&gt; <br/> <br/>-e syntax OK <br/>Free non-Callback 1032e2a88 RV=0 during global destruction. <br/>. (1): <br/> 0 0x103801558 IV f=00000001 undef(1) <br/>SV = IV(0x103801548) at 0x103801558 <br/> REFCNT = 1 <br/> FLAGS = () <br/> IV = 0 <br/>&#39;mactst.pl&#39; had compilation errors. <br/> <br/> <br/>&gt; On Jan 4, 2016, at 10:48 PM, Rocco Caputo &lt;rcaputo@pobox.com&gt; wrote: <br/>&gt; <br/>&gt; Hi, Craig. <br/>&gt; <br/>&gt; The PerlMonks thread you quoted ends with a solution to the OP&#39;s problem. The mactst.pl you quoted doesn&#39;t seem to implement that solution, so my first recommendation would be to try that. <br/>&gt; <br/>&gt; -- <br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; <br/>&gt; <br/>&gt;&gt; On Jan 4, 2016, at 13:34, Craig Votava &lt;craig.votava@alcatel-lucent.com &lt;mailto:craig.votava@alcatel-lucent.com&gt;&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt; Folks- <br/>&gt;&gt; <br/>&gt;&gt; I&rsquo;m running Yosemite (MacOSX 10.10.5) on a MacPro (Mid 2010) and am trying to use ActiveState&rsquo;s perlapp to create an executable perl script. <br/>&gt;&gt; <br/>&gt;&gt; I have been successful in creating some perl scripts that don&rsquo;t use POE, however when I try a script using POE, I get the following error: <br/>&gt;&gt; <br/>&gt;&gt; perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean --force --lib lib --exe mca mactst.pl <br/>&gt;&gt; PerlApp 9.4.0 build 298593 (perl 5.14.0) <br/>&gt;&gt; Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved. <br/>&gt;&gt; Commercial license S2EB72B1777B for Craig Votava &lt;Craig.Votava@alcatel-lucent.com &lt;mailto:Craig.Votava@alcatel-lucent.com&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; -e syntax OK <br/>&gt;&gt; Free non-Callback 101ea3e08 RV=0 during global destruction. <br/>&gt;&gt; . (1): <br/>&gt;&gt; 0 0x104012158 IV f=00000001 undef(1) <br/>&gt;&gt; SV = IV(0x104012148) at 0x104012158 <br/>&gt;&gt; REFCNT = 1 <br/>&gt;&gt; FLAGS = () <br/>&gt;&gt; IV = 0 <br/>&gt;&gt; &#39;mactst.pl&#39; had compilation errors. <br/>&gt;&gt; <br/>&gt;&gt; The contents of mactst.pl is as follows: <br/>&gt;&gt; <br/>&gt;&gt; #!/usr/local/ActivePerl-5.20/bin/perl <br/>&gt;&gt; use warnings; <br/>&gt;&gt; use strict; <br/>&gt;&gt; use Tk; <br/>&gt;&gt; use POE; <br/>&gt;&gt; <br/>&gt;&gt; if(! defined($poe_main_window)) { die &quot;\$poe_main_window not defined&quot; }; <br/>&gt;&gt; <br/>&gt;&gt; This *MAY* have something to do with an issue about the POE::Loop that gets selected (read about it here &lt;http://www.perlmonks.org/?node_id=758312&gt;), but I&rsquo;m not sure. <br/>&gt;&gt; <br/>&gt;&gt; How can I debug this? <br/>&gt;&gt; <br/>&gt;&gt; Any help is much appreciated! <br/>&gt;&gt; <br/>&gt;&gt; Thanks <br/>&gt;&gt; <br/>&gt;&gt; -Craig <br/>&gt;&gt; <br/>&gt; <br/> http://www.nntp.perl.org/group/perl.poe/2016/01/msg5098.html Tue, 05 Jan 2016 14:10:43 +0000 Re: POE and Activestate perlapp fail on MacOSX by Rocco Caputo Hi, Craig. <br/> <br/>The PerlMonks thread you quoted ends with a solution to the OP&#39;s problem. The mactst.pl you quoted doesn&#39;t seem to implement that solution, so my first recommendation would be to try that. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>&gt; On Jan 4, 2016, at 13:34, Craig Votava &lt;craig.votava@alcatel-lucent.com&gt; wrote: <br/>&gt; <br/>&gt; Folks- <br/>&gt; <br/>&gt; I&rsquo;m running Yosemite (MacOSX 10.10.5) on a MacPro (Mid 2010) and am trying to use ActiveState&rsquo;s perlapp to create an executable perl script. <br/>&gt; <br/>&gt; I have been successful in creating some perl scripts that don&rsquo;t use POE, however when I try a script using POE, I get the following error: <br/>&gt; <br/>&gt; perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean --force --lib lib --exe mca mactst.pl <br/>&gt; PerlApp 9.4.0 build 298593 (perl 5.14.0) <br/>&gt; Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved. <br/>&gt; Commercial license S2EB72B1777B for Craig Votava &lt;Craig.Votava@alcatel-lucent.com &lt;mailto:Craig.Votava@alcatel-lucent.com&gt;&gt; <br/>&gt; <br/>&gt; -e syntax OK <br/>&gt; Free non-Callback 101ea3e08 RV=0 during global destruction. <br/>&gt; . (1): <br/>&gt; 0 0x104012158 IV f=00000001 undef(1) <br/>&gt; SV = IV(0x104012148) at 0x104012158 <br/>&gt; REFCNT = 1 <br/>&gt; FLAGS = () <br/>&gt; IV = 0 <br/>&gt; &#39;mactst.pl&#39; had compilation errors. <br/>&gt; <br/>&gt; The contents of mactst.pl is as follows: <br/>&gt; <br/>&gt; #!/usr/local/ActivePerl-5.20/bin/perl <br/>&gt; use warnings; <br/>&gt; use strict; <br/>&gt; use Tk; <br/>&gt; use POE; <br/>&gt; <br/>&gt; if(! defined($poe_main_window)) { die &quot;\$poe_main_window not defined&quot; }; <br/>&gt; <br/>&gt; This *MAY* have something to do with an issue about the POE::Loop that gets selected (read about it here &lt;http://www.perlmonks.org/?node_id=758312&gt;), but I&rsquo;m not sure. <br/>&gt; <br/>&gt; How can I debug this? <br/>&gt; <br/>&gt; Any help is much appreciated! <br/>&gt; <br/>&gt; Thanks <br/>&gt; <br/>&gt; -Craig <br/>&gt; <br/> http://www.nntp.perl.org/group/perl.poe/2016/01/msg5097.html Tue, 05 Jan 2016 04:48:18 +0000 POE and Activestate perlapp fail on MacOSX by Craig Votava Folks- <br/> <br/>I&rsquo;m running Yosemite (MacOSX 10.10.5) on a MacPro (Mid 2010) and am trying to use ActiveState&rsquo;s perlapp to create an executable perl script. <br/> <br/>I have been successful in creating some perl scripts that don&rsquo;t use POE, however when I try a script using POE, I get the following error: <br/> <br/>perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean --force --lib lib --exe mca mactst.pl <br/>PerlApp 9.4.0 build 298593 (perl 5.14.0) <br/>Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved. <br/>Commercial license S2EB72B1777B for Craig Votava &lt;Craig.Votava@alcatel-lucent.com&gt; <br/> <br/>-e syntax OK <br/>Free non-Callback 101ea3e08 RV=0 during global destruction. <br/>. (1): <br/> 0 0x104012158 IV f=00000001 undef(1) <br/>SV = IV(0x104012148) at 0x104012158 <br/> REFCNT = 1 <br/> FLAGS = () <br/> IV = 0 <br/>&#39;mactst.pl&#39; had compilation errors. <br/> <br/>The contents of mactst.pl is as follows: <br/> <br/>#!/usr/local/ActivePerl-5.20/bin/perl <br/>use warnings; <br/>use strict; <br/>use Tk; <br/>use POE; <br/> <br/>if(! defined($poe_main_window)) { die &quot;\$poe_main_window not defined&quot; }; <br/> <br/>This *MAY* have something to do with an issue about the POE::Loop that gets selected (read about it here &lt;http://www.perlmonks.org/?node_id=758312&gt;), but I&rsquo;m not sure. <br/> <br/>How can I debug this? <br/> <br/>Any help is much appreciated! <br/> <br/>Thanks <br/> <br/>-Craig <br/> http://www.nntp.perl.org/group/perl.poe/2016/01/msg5096.html Mon, 04 Jan 2016 23:45:10 +0000 Re: POE::Kernel->stop() will trigger _stop in the next release by Rocco Caputo Hi. With the limited information I have, I&#39;m guessing that you have _stop handlers with side effects that affect resources shared between parent and child. For example, shutting down a socket that the parent still needs. I wouldn&#39;t limit my investigation to that scope, but I would start there. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>&gt; On Nov 11, 2015, at 19:31, Deven Parekh &lt;parekh.deven@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; Hello, <br/>&gt; <br/>&gt; Thank you for the quick response. <br/>&gt; <br/>&gt; I will try to generate a test case for the above. <br/>&gt; <br/>&gt; In the mean time if this helps, I did a hand edit to the stop subroutine in POE::Kernel and replaced <br/>&gt; <br/>&gt; $self-&gt;_data_ses_stop($session-&gt;ID); <br/>&gt; <br/>&gt; (which appears in the latest version ) <br/>&gt; <br/>&gt; with <br/>&gt; <br/>&gt; $self-&gt;_data_ses_free($session-&gt;ID); <br/>&gt; <br/>&gt; (which was how it was in previous version) <br/>&gt; <br/>&gt; and the program is working as expected now. <br/>&gt; <br/>&gt; <br/>&gt; I will try to generate a test case and send it for debugging. <br/>&gt; <br/>&gt; Thanks in advance, <br/>&gt; <br/>&gt; Best Regards. <br/>&gt; <br/>&gt; On Tue, Nov 10, 2015 at 2:53 PM, Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; wrote: <br/>&gt; I don&#39;t expect the change to cause the behavior you&#39;ve reported. <br/>&gt; <br/>&gt; If you can reduce your program to a self-contained test case, something I can run myself using only easily installed, public dependencies, I can investigate what happened. <br/>&gt; <br/>&gt; -- <br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; <br/>&gt; <br/>&gt;&gt; On Nov 10, 2015, at 15:12, Deven Parekh &lt;parekh.deven@gmail.com &lt;mailto:parekh.deven@gmail.com&gt;&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt; Hello, <br/>&gt;&gt; <br/>&gt;&gt; Is it possible that it breaks the following capability of POE::Wheel::Run <br/>&gt;&gt; Running POE::Kernel in the Child &lt;&gt; <br/>&gt;&gt; Calling POE::Kernel-&gt;run() in the child process effectively resumes the copy of the parent process. This is rarely (if ever) desired. <br/>&gt;&gt; <br/>&gt;&gt; More commonly, an application wants to run an entirely new POE::Kernel instance in the child process. This is supported by first stop()ping the copied instance, starting one or more new sessions, and calling run() again. For example: <br/>&gt;&gt; <br/>&gt;&gt; Program =&gt; sub { <br/>&gt;&gt; # Wipe the existing POE::Kernel clean. <br/>&gt;&gt; $poe_kernel-&gt;stop(); <br/>&gt;&gt; <br/>&gt;&gt; # Start a new session, or more. <br/>&gt;&gt; POE::Session-&gt;create( <br/>&gt;&gt; ... <br/>&gt;&gt; ); <br/>&gt;&gt; <br/>&gt;&gt; # Run the new sessions. <br/>&gt;&gt; POE::Kernel-&gt;run(); <br/>&gt;&gt; } <br/>&gt;&gt; <br/>&gt;&gt; I had a program that used the above construct which works fine with <br/>&gt;&gt; POE =&gt; $VERSION = &#39;1.354&#39;; <br/>&gt;&gt; POE::Wheel::Run =&gt; $VERSION = &#39;1.354&#39;; <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; However with <br/>&gt;&gt; POE =&gt; $VERSION = &#39;1.367&#39;; <br/>&gt;&gt; POE::Wheel::Run =&gt; $VERSION = &#39;1.367&#39;; <br/>&gt;&gt; <br/>&gt;&gt; It seems calling POE::Kernel-&gt;stop(); it stops the POE::Kernel instance in parent as well. <br/>&gt;&gt; <br/>&gt;&gt; Just wondering if the above change could be causing this behaviour (?) <br/>&gt;&gt; <br/>&gt;&gt; Thanks in advance. <br/>&gt;&gt; Best Regards <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; On Thu, Oct 30, 2014 at 4:00 PM, Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; wrote: <br/>&gt;&gt; Hello, everyone. I hope you&#39;ve been well. <br/>&gt;&gt; <br/>&gt;&gt; It&#39;s come to my attention that POE::Kernel-&gt;stop() isn&#39;t triggering _stop handlers. This seems wrong, so I&#39;ve changed it. I hope it doesn&#39;t break anything, but I&#39;m mentioning it here in case people want to check in advance of a release. <br/>&gt;&gt; <br/>&gt;&gt; I&#39;ve already run it past irc.perl.org &lt;http://irc.perl.org/&gt; #poe, and nobody objected. <br/>&gt;&gt; <br/>&gt;&gt; -- <br/>&gt;&gt; Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; <br/>&gt;&gt; <br/>&gt; <br/>&gt; <br/> http://www.nntp.perl.org/group/perl.poe/2015/11/msg5095.html Thu, 12 Nov 2015 02:01:49 +0000 Re: POE::Kernel->stop() will trigger _stop in the next release by Deven Parekh Hello,<br/><br/>Thank you for the quick response.<br/><br/>I will try to generate a test case for the above.<br/><br/>In the mean time if this helps, I did a hand edit to the stop subroutine<br/>in POE::Kernel and replaced<br/><br/>$self-&gt;_data_ses_stop($session-&gt;ID);<br/><br/>(which appears in the latest version )<br/><br/>with<br/><br/>$self-&gt;_data_ses_free($session-&gt;ID);<br/><br/>(which was how it was in previous version)<br/><br/>and the program is working as expected now.<br/><br/><br/>I will try to generate a test case and send it for debugging.<br/><br/>Thanks in advance,<br/><br/>Best Regards.<br/><br/>On Tue, Nov 10, 2015 at 2:53 PM, Rocco Caputo &lt;rcaputo@pobox.com&gt; wrote:<br/><br/>&gt; I don&#39;t expect the change to cause the behavior you&#39;ve reported.<br/>&gt;<br/>&gt; If you can reduce your program to a self-contained test case, something I<br/>&gt; can run myself using only easily installed, public dependencies, I can<br/>&gt; investigate what happened.<br/>&gt;<br/>&gt; --<br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com&gt;<br/>&gt;<br/>&gt; On Nov 10, 2015, at 15:12, Deven Parekh &lt;parekh.deven@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; Hello,<br/>&gt;<br/>&gt; Is it possible that it breaks the following capability of POE::Wheel::Run<br/>&gt; Running POE::Kernel in the Child<br/>&gt;<br/>&gt; Calling POE::Kernel-&gt;run() in the child process effectively resumes the<br/>&gt; copy of the parent process. This is rarely (if ever) desired.<br/>&gt;<br/>&gt; More commonly, an application wants to run an entirely new POE::Kernel<br/>&gt; instance in the child process. This is supported by first stop()ping the<br/>&gt; copied instance, starting one or more new sessions, and calling run()<br/>&gt; again. For example:<br/>&gt;<br/>&gt; Program =&gt; sub {<br/>&gt; # Wipe the existing POE::Kernel clean.<br/>&gt; $poe_kernel-&gt;stop();<br/>&gt;<br/>&gt; # Start a new session, or more.<br/>&gt; POE::Session-&gt;create(<br/>&gt; ...<br/>&gt; );<br/>&gt;<br/>&gt; # Run the new sessions.<br/>&gt; POE::Kernel-&gt;run();<br/>&gt; }<br/>&gt;<br/>&gt; I had a program that used the above construct which works fine with<br/>&gt;<br/>&gt; POE =&gt; $VERSION = &#39;1.354&#39;;<br/>&gt;<br/>&gt; POE::Wheel::Run =&gt; $VERSION = &#39;1.354&#39;;<br/>&gt;<br/>&gt;<br/>&gt; However with<br/>&gt;<br/>&gt; POE =&gt; $VERSION = &#39;1.367&#39;;<br/>&gt; POE::Wheel::Run =&gt; $VERSION = &#39;1.367&#39;;<br/>&gt;<br/>&gt; It seems calling POE::Kernel-&gt;stop(); it stops the POE::Kernel instance in parent as well.<br/>&gt;<br/>&gt; Just wondering if the above change could be causing this behaviour (?)<br/>&gt;<br/>&gt; Thanks in advance.<br/>&gt;<br/>&gt; Best Regards<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; On Thu, Oct 30, 2014 at 4:00 PM, Rocco Caputo &lt;rcaputo@pobox.com&gt; wrote:<br/>&gt;<br/>&gt;&gt; Hello, everyone. I hope you&#39;ve been well.<br/>&gt;&gt;<br/>&gt;&gt; It&#39;s come to my attention that POE::Kernel-&gt;stop() isn&#39;t triggering _stop<br/>&gt;&gt; handlers. This seems wrong, so I&#39;ve changed it. I hope it doesn&#39;t break<br/>&gt;&gt; anything, but I&#39;m mentioning it here in case people want to check in<br/>&gt;&gt; advance of a release.<br/>&gt;&gt;<br/>&gt;&gt; I&#39;ve already run it past irc.perl.org #poe, and nobody objected.<br/>&gt;&gt;<br/>&gt;&gt; --<br/>&gt;&gt; Rocco Caputo &lt;rcaputo@pobox.com&gt;<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; http://www.nntp.perl.org/group/perl.poe/2015/11/msg5094.html Thu, 12 Nov 2015 00:31:49 +0000 Re: POE::Kernel->stop() will trigger _stop in the next release by Rocco Caputo I don&#39;t expect the change to cause the behavior you&#39;ve reported. <br/> <br/>If you can reduce your program to a self-contained test case, something I can run myself using only easily installed, public dependencies, I can investigate what happened. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>&gt; On Nov 10, 2015, at 15:12, Deven Parekh &lt;parekh.deven@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; Hello, <br/>&gt; <br/>&gt; Is it possible that it breaks the following capability of POE::Wheel::Run <br/>&gt; Running POE::Kernel in the Child &lt;&gt; <br/>&gt; Calling POE::Kernel-&gt;run() in the child process effectively resumes the copy of the parent process. This is rarely (if ever) desired. <br/>&gt; <br/>&gt; More commonly, an application wants to run an entirely new POE::Kernel instance in the child process. This is supported by first stop()ping the copied instance, starting one or more new sessions, and calling run() again. For example: <br/>&gt; <br/>&gt; Program =&gt; sub { <br/>&gt; # Wipe the existing POE::Kernel clean. <br/>&gt; $poe_kernel-&gt;stop(); <br/>&gt; <br/>&gt; # Start a new session, or more. <br/>&gt; POE::Session-&gt;create( <br/>&gt; ... <br/>&gt; ); <br/>&gt; <br/>&gt; # Run the new sessions. <br/>&gt; POE::Kernel-&gt;run(); <br/>&gt; } <br/>&gt; <br/>&gt; I had a program that used the above construct which works fine with <br/>&gt; POE =&gt; $VERSION = &#39;1.354&#39;; <br/>&gt; POE::Wheel::Run =&gt; $VERSION = &#39;1.354&#39;; <br/>&gt; <br/>&gt; <br/>&gt; However with <br/>&gt; POE =&gt; $VERSION = &#39;1.367&#39;; <br/>&gt; POE::Wheel::Run =&gt; $VERSION = &#39;1.367&#39;; <br/>&gt; <br/>&gt; It seems calling POE::Kernel-&gt;stop(); it stops the POE::Kernel instance in parent as well. <br/>&gt; <br/>&gt; Just wondering if the above change could be causing this behaviour (?) <br/>&gt; <br/>&gt; Thanks in advance. <br/>&gt; Best Regards <br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; On Thu, Oct 30, 2014 at 4:00 PM, Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; wrote: <br/>&gt; Hello, everyone. I hope you&#39;ve been well. <br/>&gt; <br/>&gt; It&#39;s come to my attention that POE::Kernel-&gt;stop() isn&#39;t triggering _stop handlers. This seems wrong, so I&#39;ve changed it. I hope it doesn&#39;t break anything, but I&#39;m mentioning it here in case people want to check in advance of a release. <br/>&gt; <br/>&gt; I&#39;ve already run it past irc.perl.org &lt;http://irc.perl.org/&gt; #poe, and nobody objected. <br/>&gt; <br/>&gt; -- <br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com &lt;mailto:rcaputo@pobox.com&gt;&gt; <br/>&gt; <br/> http://www.nntp.perl.org/group/perl.poe/2015/11/msg5093.html Tue, 10 Nov 2015 20:54:08 +0000 Re: POE::Kernel->stop() will trigger _stop in the next release by Deven Parekh Hello,<br/><br/>Is it possible that it breaks the following capability of POE::Wheel::Run<br/>Running POE::Kernel in the Child<br/><br/>Calling POE::Kernel-&gt;run() in the child process effectively resumes the<br/>copy of the parent process. This is rarely (if ever) desired.<br/><br/>More commonly, an application wants to run an entirely new POE::Kernel<br/>instance in the child process. This is supported by first stop()ping the<br/>copied instance, starting one or more new sessions, and calling run()<br/>again. For example:<br/><br/> Program =&gt; sub {<br/> # Wipe the existing POE::Kernel clean.<br/> $poe_kernel-&gt;stop();<br/><br/> # Start a new session, or more.<br/> POE::Session-&gt;create(<br/> ...<br/> );<br/><br/> # Run the new sessions.<br/> POE::Kernel-&gt;run();<br/> }<br/><br/>I had a program that used the above construct which works fine with<br/><br/>POE =&gt; $VERSION = &#39;1.354&#39;;<br/><br/>POE::Wheel::Run =&gt; $VERSION = &#39;1.354&#39;;<br/><br/><br/>However with<br/><br/>POE =&gt; $VERSION = &#39;1.367&#39;;<br/>POE::Wheel::Run =&gt; $VERSION = &#39;1.367&#39;;<br/><br/>It seems calling POE::Kernel-&gt;stop(); it stops the POE::Kernel<br/>instance in parent as well.<br/><br/>Just wondering if the above change could be causing this behaviour (?)<br/><br/>Thanks in advance.<br/><br/>Best Regards<br/><br/><br/><br/><br/>On Thu, Oct 30, 2014 at 4:00 PM, Rocco Caputo &lt;rcaputo@pobox.com&gt; wrote:<br/><br/>&gt; Hello, everyone. I hope you&#39;ve been well.<br/>&gt;<br/>&gt; It&#39;s come to my attention that POE::Kernel-&gt;stop() isn&#39;t triggering _stop<br/>&gt; handlers. This seems wrong, so I&#39;ve changed it. I hope it doesn&#39;t break<br/>&gt; anything, but I&#39;m mentioning it here in case people want to check in<br/>&gt; advance of a release.<br/>&gt;<br/>&gt; I&#39;ve already run it past irc.perl.org #poe, and nobody objected.<br/>&gt;<br/>&gt; --<br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com&gt; http://www.nntp.perl.org/group/perl.poe/2015/11/msg5092.html Tue, 10 Nov 2015 20:12:44 +0000 Re: Better ways than call() by John Thanks. That helps a bunch.<br/><br/>John<br/>On Nov 9, 2015 7:47 AM, &quot;Rocco Caputo&quot; &lt;rcaputo@pobox.com&gt; wrote:<br/><br/>&gt; Hi, John.<br/>&gt;<br/>&gt; There&#39;s no requirement to store everything in $_[HEAP]. Data that must be<br/>&gt; accessible outside a session can be stored somewhere else.<br/>&gt;<br/>&gt; For example, if you&#39;re using object_states to handle events, each call<br/>&gt; gets a reference to the object: $_[OBJECT]. So you can store data<br/>&gt; particular to the object in the object handling events. Normal accessors<br/>&gt; can be used to access it. This gets tricky fast since mutators and other<br/>&gt; methods that initiate actions in the underlying session may still involve<br/>&gt; post() or call(). POE::Component::Resolver does the tricky parts, but it<br/>&gt; doesn&#39;t do the simpler thing you need.<br/>&gt;<br/>&gt; There could be a shared dictionary for accessible data. This could be as<br/>&gt; basic as a hash in a scope outside the session. The %users hash in<br/>&gt; http://poe.perl.org/?POE_Cookbook/Chat_Server is this sort of thing. I<br/>&gt; prefer something like this when peer sessions must coordinate their work.<br/>&gt;<br/>&gt; External code that requests work from a session can also pass in a<br/>&gt; reference where state will be stored. This could be a reference to some<br/>&gt; structure both the requester and the worker agree upon. I prefer to use<br/>&gt; objects for this, since the contract between requester and worker can be<br/>&gt; encoded and enforced in methods.<br/>&gt;<br/>&gt; --<br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com&gt;<br/>&gt;<br/>&gt; &gt; On Nov 9, 2015, at 08:06, john &lt;john@tonebridge.com&gt; wrote:<br/>&gt; &gt;<br/>&gt; &gt; The POE::Kernel documentation indicates this for call():<br/>&gt; &gt;<br/>&gt; &gt; call() returns the value returned by the EVENT_NAME handler. It can do<br/>&gt; this because the handler is invoked before call() returns. call() can<br/>&gt; therefore be used as an accessor, although there are better ways to<br/>&gt; accomplish simple accessor behavior.<br/>&gt; &gt;<br/>&gt; &gt; What are some of those ways? I tried a simple subroutine but don&#39;t seem<br/>&gt; to have access to things like the heap. I guess I could pass those in but<br/>&gt; than things don&#39;t seem as simple anymore.<br/>&gt; &gt;<br/>&gt; &gt; John<br/>&gt;<br/>&gt; http://www.nntp.perl.org/group/perl.poe/2015/11/msg5091.html Mon, 09 Nov 2015 16:18:32 +0000 Re: Better ways than call() by Rocco Caputo Hi, John. <br/> <br/>There&#39;s no requirement to store everything in $_[HEAP]. Data that must be accessible outside a session can be stored somewhere else. <br/> <br/>For example, if you&#39;re using object_states to handle events, each call gets a reference to the object: $_[OBJECT]. So you can store data particular to the object in the object handling events. Normal accessors can be used to access it. This gets tricky fast since mutators and other methods that initiate actions in the underlying session may still involve post() or call(). POE::Component::Resolver does the tricky parts, but it doesn&#39;t do the simpler thing you need. <br/> <br/>There could be a shared dictionary for accessible data. This could be as basic as a hash in a scope outside the session. The %users hash in http://poe.perl.org/?POE_Cookbook/Chat_Server is this sort of thing. I prefer something like this when peer sessions must coordinate their work. <br/> <br/>External code that requests work from a session can also pass in a reference where state will be stored. This could be a reference to some structure both the requester and the worker agree upon. I prefer to use objects for this, since the contract between requester and worker can be encoded and enforced in methods. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>&gt; On Nov 9, 2015, at 08:06, john &lt;john@tonebridge.com&gt; wrote: <br/>&gt; <br/>&gt; The POE::Kernel documentation indicates this for call(): <br/>&gt; <br/>&gt; call() returns the value returned by the EVENT_NAME handler. It can do this because the handler is invoked before call() returns. call() can therefore be used as an accessor, although there are better ways to accomplish simple accessor behavior. <br/>&gt; <br/>&gt; What are some of those ways? I tried a simple subroutine but don&#39;t seem to have access to things like the heap. I guess I could pass those in but than things don&#39;t seem as simple anymore. <br/>&gt; <br/>&gt; John <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2015/11/msg5090.html Mon, 09 Nov 2015 13:47:20 +0000 Better ways than call() by john The POE::Kernel documentation indicates this for call():<br/><br/>call() returns the value returned by the EVENT_NAME handler. It can do <br/>this because the handler is invoked before call() returns. call() can <br/>therefore be used as an accessor, although there are better ways to <br/>accomplish simple accessor behavior.<br/><br/>What are some of those ways? I tried a simple subroutine but don&#39;t seem <br/>to have access to things like the heap. I guess I could pass those in <br/>but than things don&#39;t seem as simple anymore.<br/><br/>John<br/> http://www.nntp.perl.org/group/perl.poe/2015/11/msg5089.html Mon, 09 Nov 2015 13:07:03 +0000 Re: POE::Component::Client::Keepalive crashes perl (5.16) on Windows by Rocco Caputo &gt; On Feb 15, 2015, at 06:59, Michael Lackhoff &lt;michael@lackhoff.de&gt; wrote: <br/>&gt; <br/>&gt; When it comes to the dependency mentioned <br/>&gt; in the Subject perl crashes several times during dmake test. It is not <br/>&gt; just a simple test failure but a Windows dialog box appears, saying that <br/>&gt; perl.exe has crashed. <br/> <br/>Hello, Michael. <br/> <br/>In these cases I usually use something like Devel::Trace to find out which line(s) of Perl were executing before the dialog pops up. Output will be super verbose, but it&#39;s the last ten lines (or so) that really matter. <br/> <br/>While it&#39;s possible to turn on crash dumps and examine them in a debugger, I&#39;ve found this to be generally unhelpful on Windows. The same goes for Windows system call traces. There&#39;s a tool for that, but Perl tends to crash in its own code. <br/> <br/>Please be sure you&#39;re using the latest available versions of POE, POE::Component::Resolver, and POE::Component::Client::Keepalive. The PPM build system is often stuck on some earlier version. <br/> <br/>It feels like the most problematic part of POE::Component::Client::Keepalive&#39;s stack would be POE::Component::Resolver. It&#39;s all &quot;pure Perl&quot;, but the resolver uses POE::Wheel::Run to move blocking DNS calls into subprocesses. <br/> <br/>POE::Wheel::Run uses Windows-specific modules to avoid problems with fork(). Many of these modules are bundled with Perl, but maybe PPM and/or CPAN contain newer versions. As a general recommendation, I suppose it wouldn&#39;t hurt to make sure these are up to date: Win32API::File, Win32::Console, Win32::Process, Win32::Job, and Win32. There may be unmet minimum version requirements for your particular setup. <br/> <br/>If you get Devel::Trace working, sending me the last output before the popup might help. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2015/02/msg5088.html Sun, 15 Feb 2015 18:36:06 +0000 POE::Component::Client::Keepalive crashes perl (5.16) on Windows by Michael Lackhoff Hi,<br/><br/>I am trying to install an application on a new PC that uses<br/>POE::Component::Client::HTTP to get web pages in parallel. But I am<br/>having problems installing it. When it comes to the dependency mentioned<br/>in the Subject perl crashes several times during dmake test. It is not<br/>just a simple test failure but a Windows dialog box appears, saying that<br/>perl.exe has crashed.<br/><br/>A previous installation from 2009 works without any problems but since<br/>it is still on XP I thought it is time for an update. As a possible<br/>workaround I even tried to install the old versions from 2009. With them<br/>I didn&#39;t get crashes but test failures and hangs during dmake test.<br/><br/>The current system I want to install it on is Windows 7 x64 with<br/>Strawberry Perl 5.16.3.1 32bit (but same result for 64 bit).<br/>It was much better with Perl 5.20.1 x64 (kept hanging in<br/>50_bisbee_timeout.t) but since there are no mod_perl binaries for 5.20<br/>yet, this is not an option for me. Because of other parts of my stack I<br/>am even bound to 32bit and for that 5.16 is the last one available (s.<br/>http://people.apache.org/~stevehay/)<br/><br/>Any ideas how to get it installed? Of course I am willing to do any<br/>debugging that might help fixing the problems.<br/><br/>Or are there any reliable alternatives I could use to load web pages in<br/>parallel within a cross platform application (Linux, Windows)?<br/><br/>-Michael<br/> http://www.nntp.perl.org/group/perl.poe/2015/02/msg5087.html Sun, 15 Feb 2015 11:59:28 +0000 POE::Kernel->stop() will trigger _stop in the next release by Rocco Caputo Hello, everyone. I hope you&#39;ve been well. <br/> <br/>It&#39;s come to my attention that POE::Kernel-&gt;stop() isn&#39;t triggering _stop handlers. This seems wrong, so I&#39;ve changed it. I hope it doesn&#39;t break anything, but I&#39;m mentioning it here in case people want to check in advance of a release. <br/> <br/>I&#39;ve already run it past irc.perl.org #poe, and nobody objected. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; http://www.nntp.perl.org/group/perl.poe/2014/10/msg5086.html Thu, 30 Oct 2014 21:01:03 +0000 Project opportunity by Shaun Dawson I have a part-time cool Perl project opportunity for the right person. It<br/>will be working in Perl using POE on embedded systems, like Raspberry PI<br/>and BeagleBone. It&#39;s in aviation, of all industries, so it&#39;s got that cool<br/>factor as well. The initial phases of the project are pure Perl, but later<br/>phases will involve some web development, and maybe even some Android/IOS<br/>app development, so knowledge of those technologies would help as well.<br/><br/>Location doesn&#39;t matter, but the client is in Southern California, so if<br/>you are near there, there will be opportunity for flight tests and that<br/>sort of thing. Not required, but can be an added bonus :).<br/><br/>It&#39;s one of those things that starts off with a pretty tight budget with<br/>some opportunity for more work at the back end, but it&#39;s still a paid<br/>engagement. It&#39;s the kind of thing that might be ideal for a good<br/>developer trying to learn Perl.<br/><br/>If you are interested, or know of someone who might be, contact me<br/>directly, and let&#39;s have a chat and see if there is a good fit.<br/><br/>Best regards,<br/><br/>Shaun http://www.nntp.perl.org/group/perl.poe/2014/07/msg5085.html Wed, 16 Jul 2014 16:36:17 +0000 POE::Component::Client::HTTP not reconnecting, why? by albertocurro Hi everyone,<br/><br/> I&#39;ve found this problem with POE::Component::Client::HTTP, as when the endpoint (HTTP Server) shuts down, POE is not reconnecting after a while, even if the server comes up again. <br/><br/> This is part of the initialization code:<br/><br/> POE::Session-&amp;gt;create(<br/> inline_states =&amp;gt; {<br/> _start =&amp;gt; sub {<br/> $_[KERNEL]-&amp;gt;alias_set(&quot;store_remote_$self-&amp;gt;{RIDX}&quot;);<br/> $self-&amp;gt;{SESSION} = $_[SESSION];<br/> $_[HEAP]{self} = $self; <br/> POE::Component::Client::HTTP-&amp;gt;spawn(<br/> Timeout =&amp;gt; $config-&amp;gt;get(&#39;remote_store&#39;)-&amp;gt;[$idx]-&amp;gt;{&#39;request_timeout&#39;},<br/> Alias =&amp;gt; $self-&amp;gt;{ALIAS},<br/> Proxy =&amp;gt; $config-&amp;gt;get(&#39;remote_store.proxy&#39;),<br/> Protocol =&amp;gt; &#39;HTTP/1.1&#39;,<br/> ConnectionManager =&amp;gt; POE::Component::Client::Keepalive-&amp;gt;new(<br/> keep_alive =&amp;gt; 1,<br/> max_open =&amp;gt; 100,<br/> max_per_host =&amp;gt; 100,<br/> timeout =&amp;gt; 10,<br/> resolve_cb =&amp;gt; sub { $self-&amp;gt;_resolve_cb(@_); },<br/> ),<br/> );<br/> },<br/> on_handle =&amp;gt; \&amp;amp;_handle,<br/> on_response =&amp;gt; \&amp;amp;_response,<br/> on_read_dir_response =&amp;gt; \&amp;amp;_read_dir_response,<br/> on_mkdir_response =&amp;gt; \&amp;amp;_mkdir_response,<br/> on_retry =&amp;gt; \&amp;amp;_retry,<br/> _monitoring_tick =&amp;gt; \&amp;amp;_monitoring_tick,<br/> }<br/> );<br/><br/> Looking for a possible similar issue in the mailing list database, I&#39;ve found this message @ http://www.mail-archive.com/poe@perl.org/msg04735.html, where Gabor suggested to increase the number of max connections in the KeepAlive instatiation; changing it to 1000 instead of 100, the issue is gone.<br/><br/>I&#39;d like to understand why this exactly happens. Maybe the client not freeing the connections when they can&#39;t be stablished? is this a known issue, or something designed this way? <br/><br/> I can see also that, from 1.357, the error shown in the logs is 408 Request timeout, while in previous versions was 111: connection refused. IMHO the previous one was more accurate than the one in 1.357, because the endpoint is down at this time.<br/><br/> Regards<br/> Alberto<br/><br/><br/><br/><br/><br/> http://www.nntp.perl.org/group/perl.poe/2014/06/msg5084.html Wed, 25 Jun 2014 17:12:48 +0000 A scheduler with Reflex::Wakeup by Giacomo Montagner http://www.nntp.perl.org/group/perl.poe/2014/04/msg5083.html Wed, 09 Apr 2014 14:48:25 +0000 Re: Asunto: Re: Slow fork bomb message in latest version of POE by Rocco Caputo Hi again. <br/> <br/>What I mean is that I don&#39;t think you know what sig_child() does exactly, or how to use it. I base this impression on two things: First, you&#39;re calling sig_child() from a place where it will never work and at a time that is obviously too late to do anything. Second, it needs at least two parameters to work, but you&#39;re passing it nothing. <br/> <br/>I recommend not using SIGDIE for common exception handling. Its scope is too broad, and your code will get ugly. It&#39;s probably cleaner to use eval{} or Try::Tiny to convert your unexpected exceptions into expected ones. If you catch them explicitly, then POE won&#39;t need to raise them, and there should be less strange behavior. <br/> <br/>The problem seems to be migrating. I recommend caution against further clouding the original issue until it&#39;s resolved. <br/> <br/>If you resolve your exceptions issue, and if you resolve your sig_child() usage issue, then your program should not be interrupted at inopportune times, and it should reap the nginx process before it exits. This should resolve all outstanding issues, as I currently understand them. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>On Mar 24, 2014, at 12:15, albertocurro &lt;albertocurro@zoho.com&gt; wrote: <br/> <br/>&gt; <br/>&gt; Hi, <br/>&gt; <br/>&gt; Sorry, but I don&#39;t catch what you exactly mean with &quot;not using sig_child() as intended&quot;. Do you mean calling it from the main session so each child process will be closed properly? <br/>&gt; <br/>&gt; The issue I have is how to handle unexpected exceptions. Seems they are thrown and raised without control, killing POE&#39;s kernel before in the way. I could be thinking in the timing in the wrong way, though... <br/>&gt; <br/>&gt; Alberto <br/>&gt; <br/>&gt; ---- Activado lun, 24 mar 2014 16:59:49 +0100 Rocco Caputo&lt;rcaputo@pobox.com&gt; escribi&oacute; ---- <br/>&gt; <br/>&gt;&gt; You are not using sig_child() as intended. When used as intended, sig_child() will prevent shutdown until the child process has exited and has been reaped. The timing issues you&#39;re worried about should not exist. <br/>&gt;&gt; <br/>&gt;&gt; -- <br/>&gt;&gt; Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/>&gt;&gt; <br/>&gt;&gt; On Mar 24, 2014, at 11:44, albertocurro &lt;albertocurro@zoho.com&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt;&gt; Hi Rocco, <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; many thanks for your quick answer! Unfortunately, the provided solution only works partially. I still have some cases where the &quot;fork bomb&quot; message is here with us :( <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; One of the cases is this one: under some configuration, an instance of nginx is started, so our product writes the configuration file and starts the Nginx instance pointing to that configuration file. BUT, if the configuration file could not be written (directory does not exist, etc), then the error raises, and I&#39;ve not found any way to handle it: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; DEBUG - Created nginx temporary directory /opt/tmp/pull/instance1 <br/>&gt;&gt;&gt; DEBUG - Created nginx configuration directory /opt/etc/pull/instance1 <br/>&gt;&gt;&gt; DEBUG - Created nginx log directory /opt/log/pull/instance1 <br/>&gt;&gt;&gt; DEBUG - creating nginx configfile for instance 1 in /opt/etc/pull/instance1 <br/>&gt;&gt;&gt; === 13991 === !!! Kernel has 1 child process(es). <br/>&gt;&gt;&gt; === 13991 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt; === 13991 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt;&gt;&gt; === 13991 === !!! In extreme cases, failure to reap child processes has <br/>&gt;&gt;&gt; === 13991 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt;&gt;&gt; Could not open file: No such file or directory <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; I&#39;ve added a DIE handler in the main session to try to handle this: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; $sig_session = POE::Session-&gt;create( <br/>&gt;&gt;&gt; inline_states =&gt; { <br/>&gt;&gt;&gt; _start =&gt; sub { <br/>&gt;&gt;&gt; $_[HEAP]{RELOADED} = 0; <br/>&gt;&gt;&gt; $_[KERNEL]-&gt;sig(TERM =&gt; &#39;_sigterm&#39;); <br/>&gt;&gt;&gt; $_[KERNEL]-&gt;sig(INT =&gt; &#39;_sigterm&#39;); <br/>&gt;&gt;&gt; $_[KERNEL]-&gt;sig(DIE =&gt; &#39;_sigterm&#39;); <br/>&gt;&gt;&gt; $_[KERNEL]-&gt;sig(nginx_reload =&gt; &#39;_sig_nginx_reload&#39;); <br/>&gt;&gt;&gt; $_[KERNEL]-&gt;alias_set(&#39;sighandler&#39;); <br/>&gt;&gt;&gt; }, <br/>&gt;&gt;&gt; _sigdie =&gt; sub { <br/>&gt;&gt;&gt; print &quot;Handling exception, calling stop&quot;; <br/>&gt;&gt;&gt; POE::Kernel-&gt;call($sig_session, &#39;_stop&#39;); <br/>&gt;&gt;&gt; }, <br/>&gt;&gt;&gt; _stop =&gt; sub { <br/>&gt;&gt;&gt; # Reap any existing pid (# 1825119) <br/>&gt;&gt;&gt; print &quot;Handling stop&quot;; <br/>&gt;&gt;&gt; POE::Kernel-&gt;sig_child(); <br/>&gt;&gt;&gt; use POSIX &quot;:sys_wait_h&quot;; <br/>&gt;&gt;&gt; 1 while waitpid(WNOHANG, -1) &gt; 0; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; # Clear signal handlers... <br/>&gt;&gt;&gt; $_[KERNEL]-&gt;sig(&#39;TERM&#39;); <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; But, as said above, it&#39;s not working. Checking POE&#39;s code, I can see the message lines are generated in Resources/Signals.pm, under _data_sig_finalize() method (where POE is already doing the same you recommended me, waiting for the pid). <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; But _data_sig_finalize() method is called in Kernel.pm just after unregistered all the signals (Kernel.pm =&gt; _finalize_kernel): <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; my $self = shift; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; # Disable signal watching since there&#39;s now no place for them to go. <br/>&gt;&gt;&gt; foreach ($self-&gt;_data_sig_get_safe_signals()) { <br/>&gt;&gt;&gt; $self-&gt;loop_ignore_signal($_); <br/>&gt;&gt;&gt; } <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; # Remove the kernel session&#39;s signal watcher. <br/>&gt;&gt;&gt; $self-&gt;_data_sig_remove($self-&gt;ID, &quot;IDLE&quot;); <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; # The main loop is done, no matter which event library ran it. <br/>&gt;&gt;&gt; # sig before loop so that it clears the signal_pipe file handler <br/>&gt;&gt;&gt; $self-&gt;_data_sig_finalize(); <br/>&gt;&gt;&gt; $self-&gt;loop_finalize(); <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Once here, none of my signal handlers in the main session instance would work, as the signals have been unregistered. On an exception (die) while POE::Kernel-&gt;run(), how could I handle it then?? <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Thanks a lot <br/>&gt;&gt;&gt; Alberto <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; ---- Activado lun, 24 mar 2014 13:45:45 +0100 Rocco Caputo escribi&oacute; ---- <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; Hi, Alberto. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; At program end time, POE runs a quick waitpid() check for child processes that may have leaked. This check was added after a bug report where POE locked up a server after several days of running. It turned out to be the reporter&#39;s application, but it was hard to debug. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; Your program seems to have created two processes that it didn&#39;t reap: PIDs 5373 and 5374. The ideal solution is to reap those processes before exiting. Your program can do this using POE::Kernel&#39;s sig_child() method. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; In some cases, a third-party library will create processes and not properly clean them up. It can be impossible to solve this case without modifying other people&#39;s code. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; If you just want to ignore the problem, this might do the trick. Put these lines in your last _stop handler. They should reap the processes you&#39;ve leaked before POE&#39;s check: <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; use POSIX &quot;:sys_wait_h&quot;; <br/>&gt;&gt;&gt;&gt; 1 while waitpid(WNOHANG, -1) &gt; 0; <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; It&#39;s a bit of a pain, but I think it&#39;s better to explicitly ignore the problem than for it to go unnoticed by default. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; Please let me know whether that resolves your problem. It may not. For example, the processes may still be open until an object is destroyed at global destruction time. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; -- <br/>&gt;&gt;&gt;&gt; Rocco Caputo <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; On Mar 24, 2014, at 05:46, albertocurro wrote: <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; Guys, <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; We have a product developed using POE as a base framework, with some other tool libraries as log4perl; basically is a forward proxy, composed of several modules, each one of them comprising a POE::Session; all of them share an internal queue of tasks to be performed. Each module performs several tasks on initialization, and if anything goes wrong, croak() is called to stop the service -&gt; this is considered ok, since croak() is only called during initialization, when validation is being performed. <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; The product is stable and works really fine, but recently I updated POE to the latest version, and since then we can see this message in the logs: <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; registering pdu failed: 263! <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === 5 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === 5 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === 9 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === 9 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Kernel has child processes. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt;&gt;&gt;&gt;&gt; mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147 <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; first lines and last line above are the errors itself, but this part is new since the upgrading: <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Kernel has child processes. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt;&gt;&gt;&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; I can see it everytime the service is stopped because of an unhandled condition, even when POE&#39;s event loop has been already running for ours. It was not visible before, and I can&#39;t get rid of it in any way. I&#39;ve tried different ways to avoid it with no luck. <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; Any advice or alternative approach on this? <br/>&gt;&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; Many thanks <br/>&gt;&gt;&gt;&gt;&gt; Alberto <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/03/msg5082.html Mon, 24 Mar 2014 17:30:55 +0000 Asunto: Re: Slow fork bomb message in latest version of POE by albertocurro <br/>Hi, <br/> <br/> Sorry, but I don&#39;t catch what you exactly mean with &quot;not using sig_child() as intended&quot;. Do you mean calling it from the main session so each child process will be closed properly? <br/> <br/> The issue I have is how to handle unexpected exceptions. Seems they are thrown and raised without control, killing POE&#39;s kernel before in the way. I could be thinking in the timing in the wrong way, though... <br/> <br/> Alberto <br/> <br/>---- Activado lun, 24 mar 2014 16:59:49 +0100 Rocco Caputo&lt;rcaputo@pobox.com&gt; escribi&Atilde;&sup3; ---- <br/> <br/> &gt; You are not using sig_child() as intended. When used as intended, sig_child() will prevent shutdown until the child process has exited and has been reaped. The timing issues you&#39;re worried about should not exist. <br/> &gt; <br/> &gt; -- <br/> &gt; Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> &gt; <br/> &gt; On Mar 24, 2014, at 11:44, albertocurro &lt;albertocurro@zoho.com&gt; wrote: <br/> &gt; <br/> &gt; &gt; Hi Rocco, <br/> &gt; &gt; <br/> &gt; &gt; many thanks for your quick answer! Unfortunately, the provided solution only works partially. I still have some cases where the &quot;fork bomb&quot; message is here with us :( <br/> &gt; &gt; <br/> &gt; &gt; One of the cases is this one: under some configuration, an instance of nginx is started, so our product writes the configuration file and starts the Nginx instance pointing to that configuration file. BUT, if the configuration file could not be written (directory does not exist, etc), then the error raises, and I&#39;ve not found any way to handle it: <br/> &gt; &gt; <br/> &gt; &gt; DEBUG - Created nginx temporary directory /opt/tmp/pull/instance1 <br/> &gt; &gt; DEBUG - Created nginx configuration directory /opt/etc/pull/instance1 <br/> &gt; &gt; DEBUG - Created nginx log directory /opt/log/pull/instance1 <br/> &gt; &gt; DEBUG - creating nginx configfile for instance 1 in /opt/etc/pull/instance1 <br/> &gt; &gt; === 13991 === !!! Kernel has 1 child process(es). <br/> &gt; &gt; === 13991 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt; === 13991 === !!! Be sure to use sig_child() to reap child processes. <br/> &gt; &gt; === 13991 === !!! In extreme cases, failure to reap child processes has <br/> &gt; &gt; === 13991 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/> &gt; &gt; Could not open file: No such file or directory <br/> &gt; &gt; <br/> &gt; &gt; I&#39;ve added a DIE handler in the main session to try to handle this: <br/> &gt; &gt; <br/> &gt; &gt; $sig_session = POE::Session-&gt;create( <br/> &gt; &gt; inline_states =&gt; { <br/> &gt; &gt; _start =&gt; sub { <br/> &gt; &gt; $_[HEAP]{RELOADED} = 0; <br/> &gt; &gt; $_[KERNEL]-&gt;sig(TERM =&gt; &#39;_sigterm&#39;); <br/> &gt; &gt; $_[KERNEL]-&gt;sig(INT =&gt; &#39;_sigterm&#39;); <br/> &gt; &gt; $_[KERNEL]-&gt;sig(DIE =&gt; &#39;_sigterm&#39;); <br/> &gt; &gt; $_[KERNEL]-&gt;sig(nginx_reload =&gt; &#39;_sig_nginx_reload&#39;); <br/> &gt; &gt; $_[KERNEL]-&gt;alias_set(&#39;sighandler&#39;); <br/> &gt; &gt; }, <br/> &gt; &gt; _sigdie =&gt; sub { <br/> &gt; &gt; print &quot;Handling exception, calling stop&quot;; <br/> &gt; &gt; POE::Kernel-&gt;call($sig_session, &#39;_stop&#39;); <br/> &gt; &gt; }, <br/> &gt; &gt; _stop =&gt; sub { <br/> &gt; &gt; # Reap any existing pid (# 1825119) <br/> &gt; &gt; print &quot;Handling stop&quot;; <br/> &gt; &gt; POE::Kernel-&gt;sig_child(); <br/> &gt; &gt; use POSIX &quot;:sys_wait_h&quot;; <br/> &gt; &gt; 1 while waitpid(WNOHANG, -1) &gt; 0; <br/> &gt; &gt; <br/> &gt; &gt; # Clear signal handlers... <br/> &gt; &gt; $_[KERNEL]-&gt;sig(&#39;TERM&#39;); <br/> &gt; &gt; <br/> &gt; &gt; But, as said above, it&#39;s not working. Checking POE&#39;s code, I can see the message lines are generated in Resources/Signals.pm, under _data_sig_finalize() method (where POE is already doing the same you recommended me, waiting for the pid). <br/> &gt; &gt; <br/> &gt; &gt; But _data_sig_finalize() method is called in Kernel.pm just after unregistered all the signals (Kernel.pm =&gt; _finalize_kernel): <br/> &gt; &gt; <br/> &gt; &gt; my $self = shift; <br/> &gt; &gt; <br/> &gt; &gt; # Disable signal watching since there&#39;s now no place for them to go. <br/> &gt; &gt; foreach ($self-&gt;_data_sig_get_safe_signals()) { <br/> &gt; &gt; $self-&gt;loop_ignore_signal($_); <br/> &gt; &gt; } <br/> &gt; &gt; <br/> &gt; &gt; # Remove the kernel session&#39;s signal watcher. <br/> &gt; &gt; $self-&gt;_data_sig_remove($self-&gt;ID, &quot;IDLE&quot;); <br/> &gt; &gt; <br/> &gt; &gt; # The main loop is done, no matter which event library ran it. <br/> &gt; &gt; # sig before loop so that it clears the signal_pipe file handler <br/> &gt; &gt; $self-&gt;_data_sig_finalize(); <br/> &gt; &gt; $self-&gt;loop_finalize(); <br/> &gt; &gt; <br/> &gt; &gt; Once here, none of my signal handlers in the main session instance would work, as the signals have been unregistered. On an exception (die) while POE::Kernel-&gt;run(), how could I handle it then?? <br/> &gt; &gt; <br/> &gt; &gt; Thanks a lot <br/> &gt; &gt; Alberto <br/> &gt; &gt; <br/> &gt; &gt; <br/> &gt; &gt; <br/> &gt; &gt; <br/> &gt; &gt; ---- Activado lun, 24 mar 2014 13:45:45 +0100 Rocco Caputo escribi&Atilde;&sup3; ---- <br/> &gt; &gt; <br/> &gt; &gt;&gt; Hi, Alberto. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; At program end time, POE runs a quick waitpid() check for child processes that may have leaked. This check was added after a bug report where POE locked up a server after several days of running. It turned out to be the reporter&#39;s application, but it was hard to debug. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; Your program seems to have created two processes that it didn&#39;t reap: PIDs 5373 and 5374. The ideal solution is to reap those processes before exiting. Your program can do this using POE::Kernel&#39;s sig_child() method. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; In some cases, a third-party library will create processes and not properly clean them up. It can be impossible to solve this case without modifying other people&#39;s code. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; If you just want to ignore the problem, this might do the trick. Put these lines in your last _stop handler. They should reap the processes you&#39;ve leaked before POE&#39;s check: <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; use POSIX &quot;:sys_wait_h&quot;; <br/> &gt; &gt;&gt; 1 while waitpid(WNOHANG, -1) &gt; 0; <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; It&#39;s a bit of a pain, but I think it&#39;s better to explicitly ignore the problem than for it to go unnoticed by default. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; Please let me know whether that resolves your problem. It may not. For example, the processes may still be open until an object is destroyed at global destruction time. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; -- <br/> &gt; &gt;&gt; Rocco Caputo <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; On Mar 24, 2014, at 05:46, albertocurro wrote: <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt;&gt; Guys, <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; We have a product developed using POE as a base framework, with some other tool libraries as log4perl; basically is a forward proxy, composed of several modules, each one of them comprising a POE::Session; all of them share an internal queue of tasks to be performed. Each module performs several tasks on initialization, and if anything goes wrong, croak() is called to stop the service -&gt; this is considered ok, since croak() is only called during initialization, when validation is being performed. <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; The product is stable and works really fine, but recently I updated POE to the latest version, and since then we can see this message in the logs: <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; registering pdu failed: 263! <br/> &gt; &gt;&gt;&gt; === 5267 === 5 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/> &gt; &gt;&gt;&gt; === 5267 === 5 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/> &gt; &gt;&gt;&gt; === 5267 === 9 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/> &gt; &gt;&gt;&gt; === 5267 === 9 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Kernel has child processes. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/> &gt; &gt;&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/> &gt; &gt;&gt;&gt; mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147 <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; first lines and last line above are the errors itself, but this part is new since the upgrading: <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Kernel has child processes. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/> &gt; &gt;&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/> &gt; &gt;&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; I can see it everytime the service is stopped because of an unhandled condition, even when POE&#39;s event loop has been already running for ours. It was not visible before, and I can&#39;t get rid of it in any way. I&#39;ve tried different ways to avoid it with no luck. <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; Any advice or alternative approach on this? <br/> &gt; &gt;&gt;&gt; <br/> &gt; &gt;&gt;&gt; Many thanks <br/> &gt; &gt;&gt;&gt; Alberto <br/> &gt; <br/> &gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/03/msg5081.html Mon, 24 Mar 2014 16:15:29 +0000 Re: Slow fork bomb message in latest version of POE by Rocco Caputo You are not using sig_child() as intended. When used as intended, sig_child() will prevent shutdown until the child process has exited and has been reaped. The timing issues you&#39;re worried about should not exist. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>On Mar 24, 2014, at 11:44, albertocurro &lt;albertocurro@zoho.com&gt; wrote: <br/> <br/>&gt; Hi Rocco, <br/>&gt; <br/>&gt; many thanks for your quick answer! Unfortunately, the provided solution only works partially. I still have some cases where the &quot;fork bomb&quot; message is here with us :( <br/>&gt; <br/>&gt; One of the cases is this one: under some configuration, an instance of nginx is started, so our product writes the configuration file and starts the Nginx instance pointing to that configuration file. BUT, if the configuration file could not be written (directory does not exist, etc), then the error raises, and I&#39;ve not found any way to handle it: <br/>&gt; <br/>&gt; DEBUG - Created nginx temporary directory /opt/tmp/pull/instance1 <br/>&gt; DEBUG - Created nginx configuration directory /opt/etc/pull/instance1 <br/>&gt; DEBUG - Created nginx log directory /opt/log/pull/instance1 <br/>&gt; DEBUG - creating nginx configfile for instance 1 in /opt/etc/pull/instance1 <br/>&gt; === 13991 === !!! Kernel has 1 child process(es). <br/>&gt; === 13991 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt; === 13991 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt; === 13991 === !!! In extreme cases, failure to reap child processes has <br/>&gt; === 13991 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt; Could not open file: No such file or directory <br/>&gt; <br/>&gt; I&#39;ve added a DIE handler in the main session to try to handle this: <br/>&gt; <br/>&gt; $sig_session = POE::Session-&gt;create( <br/>&gt; inline_states =&gt; { <br/>&gt; _start =&gt; sub { <br/>&gt; $_[HEAP]{RELOADED} = 0; <br/>&gt; $_[KERNEL]-&gt;sig(TERM =&gt; &#39;_sigterm&#39;); <br/>&gt; $_[KERNEL]-&gt;sig(INT =&gt; &#39;_sigterm&#39;); <br/>&gt; $_[KERNEL]-&gt;sig(DIE =&gt; &#39;_sigterm&#39;); <br/>&gt; $_[KERNEL]-&gt;sig(nginx_reload =&gt; &#39;_sig_nginx_reload&#39;); <br/>&gt; $_[KERNEL]-&gt;alias_set(&#39;sighandler&#39;); <br/>&gt; }, <br/>&gt; _sigdie =&gt; sub { <br/>&gt; print &quot;Handling exception, calling stop&quot;; <br/>&gt; POE::Kernel-&gt;call($sig_session, &#39;_stop&#39;); <br/>&gt; }, <br/>&gt; _stop =&gt; sub { <br/>&gt; # Reap any existing pid (# 1825119) <br/>&gt; print &quot;Handling stop&quot;; <br/>&gt; POE::Kernel-&gt;sig_child(); <br/>&gt; use POSIX &quot;:sys_wait_h&quot;; <br/>&gt; 1 while waitpid(WNOHANG, -1) &gt; 0; <br/>&gt; <br/>&gt; # Clear signal handlers... <br/>&gt; $_[KERNEL]-&gt;sig(&#39;TERM&#39;); <br/>&gt; <br/>&gt; But, as said above, it&#39;s not working. Checking POE&#39;s code, I can see the message lines are generated in Resources/Signals.pm, under _data_sig_finalize() method (where POE is already doing the same you recommended me, waiting for the pid). <br/>&gt; <br/>&gt; But _data_sig_finalize() method is called in Kernel.pm just after unregistered all the signals (Kernel.pm =&gt; _finalize_kernel): <br/>&gt; <br/>&gt; my $self = shift; <br/>&gt; <br/>&gt; # Disable signal watching since there&#39;s now no place for them to go. <br/>&gt; foreach ($self-&gt;_data_sig_get_safe_signals()) { <br/>&gt; $self-&gt;loop_ignore_signal($_); <br/>&gt; } <br/>&gt; <br/>&gt; # Remove the kernel session&#39;s signal watcher. <br/>&gt; $self-&gt;_data_sig_remove($self-&gt;ID, &quot;IDLE&quot;); <br/>&gt; <br/>&gt; # The main loop is done, no matter which event library ran it. <br/>&gt; # sig before loop so that it clears the signal_pipe file handler <br/>&gt; $self-&gt;_data_sig_finalize(); <br/>&gt; $self-&gt;loop_finalize(); <br/>&gt; <br/>&gt; Once here, none of my signal handlers in the main session instance would work, as the signals have been unregistered. On an exception (die) while POE::Kernel-&gt;run(), how could I handle it then?? <br/>&gt; <br/>&gt; Thanks a lot <br/>&gt; Alberto <br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; ---- Activado lun, 24 mar 2014 13:45:45 +0100 Rocco Caputo escribi&oacute; ---- <br/>&gt; <br/>&gt;&gt; Hi, Alberto. <br/>&gt;&gt; <br/>&gt;&gt; At program end time, POE runs a quick waitpid() check for child processes that may have leaked. This check was added after a bug report where POE locked up a server after several days of running. It turned out to be the reporter&#39;s application, but it was hard to debug. <br/>&gt;&gt; <br/>&gt;&gt; Your program seems to have created two processes that it didn&#39;t reap: PIDs 5373 and 5374. The ideal solution is to reap those processes before exiting. Your program can do this using POE::Kernel&#39;s sig_child() method. <br/>&gt;&gt; <br/>&gt;&gt; In some cases, a third-party library will create processes and not properly clean them up. It can be impossible to solve this case without modifying other people&#39;s code. <br/>&gt;&gt; <br/>&gt;&gt; If you just want to ignore the problem, this might do the trick. Put these lines in your last _stop handler. They should reap the processes you&#39;ve leaked before POE&#39;s check: <br/>&gt;&gt; <br/>&gt;&gt; use POSIX &quot;:sys_wait_h&quot;; <br/>&gt;&gt; 1 while waitpid(WNOHANG, -1) &gt; 0; <br/>&gt;&gt; <br/>&gt;&gt; It&#39;s a bit of a pain, but I think it&#39;s better to explicitly ignore the problem than for it to go unnoticed by default. <br/>&gt;&gt; <br/>&gt;&gt; Please let me know whether that resolves your problem. It may not. For example, the processes may still be open until an object is destroyed at global destruction time. <br/>&gt;&gt; <br/>&gt;&gt; -- <br/>&gt;&gt; Rocco Caputo <br/>&gt;&gt; <br/>&gt;&gt; On Mar 24, 2014, at 05:46, albertocurro wrote: <br/>&gt;&gt; <br/>&gt;&gt;&gt; Guys, <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; We have a product developed using POE as a base framework, with some other tool libraries as log4perl; basically is a forward proxy, composed of several modules, each one of them comprising a POE::Session; all of them share an internal queue of tasks to be performed. Each module performs several tasks on initialization, and if anything goes wrong, croak() is called to stop the service -&gt; this is considered ok, since croak() is only called during initialization, when validation is being performed. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; The product is stable and works really fine, but recently I updated POE to the latest version, and since then we can see this message in the logs: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; registering pdu failed: 263! <br/>&gt;&gt;&gt; === 5267 === 5 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt;&gt;&gt; === 5267 === 5 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt;&gt;&gt; === 5267 === 9 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt;&gt;&gt; === 5267 === 9 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt;&gt;&gt; === 5267 === !!! Kernel has child processes. <br/>&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt;&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt;&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt;&gt;&gt; mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147 <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; first lines and last line above are the errors itself, but this part is new since the upgrading: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; === 5267 === !!! Kernel has child processes. <br/>&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt;&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt;&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; I can see it everytime the service is stopped because of an unhandled condition, even when POE&#39;s event loop has been already running for ours. It was not visible before, and I can&#39;t get rid of it in any way. I&#39;ve tried different ways to avoid it with no luck. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Any advice or alternative approach on this? <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Many thanks <br/>&gt;&gt;&gt; Alberto <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/03/msg5080.html Mon, 24 Mar 2014 16:00:11 +0000 Asunto: Re: Slow fork bomb message in latest version of POE by albertocurro Hi again, <br/> <br/> sorry! from the code below, there&#39;s a mistake as DIE signal is linked to _sigterm, while is really pointing to _sigdie; just to clarify it before someone says &quot;it can&#39;t work, you are pointing to the wrong method!&quot; :D <br/> <br/> Alberto <br/> <br/> <br/>---- Activado lun, 24 mar 2014 16:44:36 +0100 albertocurro&lt;albertocurro@zoho.com&gt; escribi&Atilde;&sup3; ---- <br/> <br/> &gt; Hi Rocco, <br/> &gt; <br/> &gt; many thanks for your quick answer! Unfortunately, the provided solution only works partially. I still have some cases where the &quot;fork bomb&quot; message is here with us :( <br/> &gt; <br/> &gt; One of the cases is this one: under some configuration, an instance of nginx is started, so our product writes the configuration file and starts the Nginx instance pointing to that configuration file. BUT, if the configuration file could not be written (directory does not exist, etc), then the error raises, and I&#39;ve not found any way to handle it: <br/> &gt; <br/> &gt; DEBUG - Created nginx temporary directory /opt/tmp/pull/instance1 <br/> &gt; DEBUG - Created nginx configuration directory /opt/etc/pull/instance1 <br/> &gt; DEBUG - Created nginx log directory /opt/log/pull/instance1 <br/> &gt; DEBUG - creating nginx configfile for instance 1 in /opt/etc/pull/instance1 <br/> &gt; === 13991 === !!! Kernel has 1 child process(es). <br/> &gt; === 13991 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/> &gt; === 13991 === !!! Be sure to use sig_child() to reap child processes. <br/> &gt; === 13991 === !!! In extreme cases, failure to reap child processes has <br/> &gt; === 13991 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/> &gt; Could not open file: No such file or directory <br/> &gt; <br/> &gt; I&#39;ve added a DIE handler in the main session to try to handle this: <br/> &gt; <br/> &gt; $sig_session = POE::Session-&gt;create( <br/> &gt; inline_states =&gt; { <br/> &gt; _start =&gt; sub { <br/> &gt; $_[HEAP]{RELOADED} = 0; <br/> &gt; $_[KERNEL]-&gt;sig(TERM =&gt; &#39;_sigterm&#39;); <br/> &gt; $_[KERNEL]-&gt;sig(INT =&gt; &#39;_sigterm&#39;); <br/> &gt; $_[KERNEL]-&gt;sig(DIE =&gt; &#39;_sigterm&#39;); <br/> &gt; $_[KERNEL]-&gt;sig(nginx_reload =&gt; &#39;_sig_nginx_reload&#39;); <br/> &gt; $_[KERNEL]-&gt;alias_set(&#39;sighandler&#39;); <br/> &gt; }, <br/> &gt; _sigdie =&gt; sub { <br/> &gt; print &quot;Handling exception, calling stop&quot;; <br/> &gt; POE::Kernel-&gt;call($sig_session, &#39;_stop&#39;); <br/> &gt; }, <br/> &gt; _stop =&gt; sub { <br/> &gt; # Reap any existing pid (# 1825119) <br/> &gt; print &quot;Handling stop&quot;; <br/> &gt; POE::Kernel-&gt;sig_child(); <br/> &gt; use POSIX &quot;:sys_wait_h&quot;; <br/> &gt; 1 while waitpid(WNOHANG, -1) &gt; 0; <br/> &gt; <br/> &gt; # Clear signal handlers... <br/> &gt; $_[KERNEL]-&gt;sig(&#39;TERM&#39;); <br/> &gt; <br/> &gt; But, as said above, it&#39;s not working. Checking POE&#39;s code, I can see the message lines are generated in Resources/Signals.pm, under _data_sig_finalize() method (where POE is already doing the same you recommended me, waiting for the pid). <br/> &gt; <br/> &gt; But _data_sig_finalize() method is called in Kernel.pm just after unregistered all the signals (Kernel.pm =&gt; _finalize_kernel): <br/> &gt; <br/> &gt; my $self = shift; <br/> &gt; <br/> &gt; # Disable signal watching since there&#39;s now no place for them to go. <br/> &gt; foreach ($self-&gt;_data_sig_get_safe_signals()) { <br/> &gt; $self-&gt;loop_ignore_signal($_); <br/> &gt; } <br/> &gt; <br/> &gt; # Remove the kernel session&#39;s signal watcher. <br/> &gt; $self-&gt;_data_sig_remove($self-&gt;ID, &quot;IDLE&quot;); <br/> &gt; <br/> &gt; # The main loop is done, no matter which event library ran it. <br/> &gt; # sig before loop so that it clears the signal_pipe file handler <br/> &gt; $self-&gt;_data_sig_finalize(); <br/> &gt; $self-&gt;loop_finalize(); <br/> &gt; <br/> &gt; Once here, none of my signal handlers in the main session instance would work, as the signals have been unregistered. On an exception (die) while POE::Kernel-&gt;run(), how could I handle it then?? <br/> &gt; <br/> &gt; Thanks a lot <br/> &gt; Alberto <br/> &gt; <br/> &gt; <br/> &gt; <br/> &gt; <br/> &gt; ---- Activado lun, 24 mar 2014 13:45:45 +0100 Rocco Caputo escribi&Atilde;&sup3; ---- <br/> &gt; <br/> &gt; &gt;Hi, Alberto. <br/> &gt; &gt; <br/> &gt; &gt;At program end time, POE runs a quick waitpid() check for child processes that may have leaked. This check was added after a bug report where POE locked up a server after several days of running. It turned out to be the reporter&#39;s application, but it was hard to debug. <br/> &gt; &gt; <br/> &gt; &gt;Your program seems to have created two processes that it didn&#39;t reap: PIDs 5373 and 5374. The ideal solution is to reap those processes before exiting. Your program can do this using POE::Kernel&#39;s sig_child() method. <br/> &gt; &gt; <br/> &gt; &gt;In some cases, a third-party library will create processes and not properly clean them up. It can be impossible to solve this case without modifying other people&#39;s code. <br/> &gt; &gt; <br/> &gt; &gt;If you just want to ignore the problem, this might do the trick. Put these lines in your last _stop handler. They should reap the processes you&#39;ve leaked before POE&#39;s check: <br/> &gt; &gt; <br/> &gt; &gt;use POSIX &quot;:sys_wait_h&quot;; <br/> &gt; &gt;1 while waitpid(WNOHANG, -1) &gt; 0; <br/> &gt; &gt; <br/> &gt; &gt;It&#39;s a bit of a pain, but I think it&#39;s better to explicitly ignore the problem than for it to go unnoticed by default. <br/> &gt; &gt; <br/> &gt; &gt;Please let me know whether that resolves your problem. It may not. For example, the processes may still be open until an object is destroyed at global destruction time. <br/> &gt; &gt; <br/> &gt; &gt;-- <br/> &gt; &gt;Rocco Caputo <br/> &gt; &gt; <br/> &gt; &gt;On Mar 24, 2014, at 05:46, albertocurro wrote: <br/> &gt; &gt; <br/> &gt; &gt;&gt; Guys, <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; We have a product developed using POE as a base framework, with some other tool libraries as log4perl; basically is a forward proxy, composed of several modules, each one of them comprising a POE::Session; all of them share an internal queue of tasks to be performed. Each module performs several tasks on initialization, and if anything goes wrong, croak() is called to stop the service -&gt; this is considered ok, since croak() is only called during initialization, when validation is being performed. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; The product is stable and works really fine, but recently I updated POE to the latest version, and since then we can see this message in the logs: <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; registering pdu failed: 263! <br/> &gt; &gt;&gt; === 5267 === 5 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/> &gt; &gt;&gt; === 5267 === 5 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/> &gt; &gt;&gt; === 5267 === 9 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/> &gt; &gt;&gt; === 5267 === 9 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/> &gt; &gt;&gt; === 5267 === !!! Kernel has child processes. <br/> &gt; &gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/> &gt; &gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/> &gt; &gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/> &gt; &gt;&gt; mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147 <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; first lines and last line above are the errors itself, but this part is new since the upgrading: <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; === 5267 === !!! Kernel has child processes. <br/> &gt; &gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/> &gt; &gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/> &gt; &gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/> &gt; &gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; I can see it everytime the service is stopped because of an unhandled condition, even when POE&#39;s event loop has been already running for ours. It was not visible before, and I can&#39;t get rid of it in any way. I&#39;ve tried different ways to avoid it with no luck. <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; Any advice or alternative approach on this? <br/> &gt; &gt;&gt; <br/> &gt; &gt;&gt; Many thanks <br/> &gt; &gt;&gt; Alberto <br/> &gt; &gt;&gt; <br/> &gt; &gt; <br/> &gt; &gt; <br/> &gt; <br/> &gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/03/msg5079.html Mon, 24 Mar 2014 15:48:21 +0000 Re: Slow fork bomb message in latest version of POE by albertocurro Hi Rocco, <br/> <br/> many thanks for your quick answer! Unfortunately, the provided solution only works partially. I still have some cases where the &quot;fork bomb&quot; message is here with us :( <br/> <br/> One of the cases is this one: under some configuration, an instance of nginx is started, so our product writes the configuration file and starts the Nginx instance pointing to that configuration file. BUT, if the configuration file could not be written (directory does not exist, etc), then the error raises, and I&#39;ve not found any way to handle it: <br/> <br/>DEBUG - Created nginx temporary directory /opt/tmp/pull/instance1 <br/>DEBUG - Created nginx configuration directory /opt/etc/pull/instance1 <br/>DEBUG - Created nginx log directory /opt/log/pull/instance1 <br/>DEBUG - creating nginx configfile for instance 1 in /opt/etc/pull/instance1 <br/>=== 13991 === !!! Kernel has 1 child process(es). <br/>=== 13991 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>=== 13991 === !!! Be sure to use sig_child() to reap child processes. <br/>=== 13991 === !!! In extreme cases, failure to reap child processes has <br/>=== 13991 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>Could not open file: No such file or directory <br/> <br/> I&#39;ve added a DIE handler in the main session to try to handle this: <br/> <br/> $sig_session = POE::Session-&gt;create( <br/> inline_states =&gt; { <br/> _start =&gt; sub { <br/> $_[HEAP]{RELOADED} = 0; <br/> $_[KERNEL]-&gt;sig(TERM =&gt; &#39;_sigterm&#39;); <br/> $_[KERNEL]-&gt;sig(INT =&gt; &#39;_sigterm&#39;); <br/> $_[KERNEL]-&gt;sig(DIE =&gt; &#39;_sigterm&#39;); <br/> $_[KERNEL]-&gt;sig(nginx_reload =&gt; &#39;_sig_nginx_reload&#39;); <br/> $_[KERNEL]-&gt;alias_set(&#39;sighandler&#39;); <br/> }, <br/> _sigdie =&gt; sub { <br/> print &quot;Handling exception, calling stop&quot;; <br/> POE::Kernel-&gt;call($sig_session, &#39;_stop&#39;); <br/> }, <br/> _stop =&gt; sub { <br/> # Reap any existing pid (# 1825119) <br/> print &quot;Handling stop&quot;; <br/> POE::Kernel-&gt;sig_child(); <br/> use POSIX &quot;:sys_wait_h&quot;; <br/> 1 while waitpid(WNOHANG, -1) &gt; 0; <br/> <br/> # Clear signal handlers... <br/> $_[KERNEL]-&gt;sig(&#39;TERM&#39;); <br/> <br/>But, as said above, it&#39;s not working. Checking POE&#39;s code, I can see the message lines are generated in Resources/Signals.pm, under _data_sig_finalize() method (where POE is already doing the same you recommended me, waiting for the pid). <br/> <br/>But _data_sig_finalize() method is called in Kernel.pm just after unregistered all the signals (Kernel.pm =&gt; _finalize_kernel): <br/> <br/> my $self = shift; <br/> <br/> # Disable signal watching since there&#39;s now no place for them to go. <br/> foreach ($self-&gt;_data_sig_get_safe_signals()) { <br/> $self-&gt;loop_ignore_signal($_); <br/> } <br/> <br/> # Remove the kernel session&#39;s signal watcher. <br/> $self-&gt;_data_sig_remove($self-&gt;ID, &quot;IDLE&quot;); <br/> <br/> # The main loop is done, no matter which event library ran it. <br/> # sig before loop so that it clears the signal_pipe file handler <br/> $self-&gt;_data_sig_finalize(); <br/> $self-&gt;loop_finalize(); <br/> <br/> Once here, none of my signal handlers in the main session instance would work, as the signals have been unregistered. On an exception (die) while POE::Kernel-&gt;run(), how could I handle it then?? <br/> <br/> Thanks a lot <br/> Alberto <br/> <br/> <br/> <br/> <br/>---- Activado lun, 24 mar 2014 13:45:45 +0100 Rocco Caputo escribi&Atilde;&sup3; ---- <br/> <br/>&gt;Hi, Alberto. <br/>&gt; <br/>&gt;At program end time, POE runs a quick waitpid() check for child processes that may have leaked. This check was added after a bug report where POE locked up a server after several days of running. It turned out to be the reporter&#39;s application, but it was hard to debug. <br/>&gt; <br/>&gt;Your program seems to have created two processes that it didn&#39;t reap: PIDs 5373 and 5374. The ideal solution is to reap those processes before exiting. Your program can do this using POE::Kernel&#39;s sig_child() method. <br/>&gt; <br/>&gt;In some cases, a third-party library will create processes and not properly clean them up. It can be impossible to solve this case without modifying other people&#39;s code. <br/>&gt; <br/>&gt;If you just want to ignore the problem, this might do the trick. Put these lines in your last _stop handler. They should reap the processes you&#39;ve leaked before POE&#39;s check: <br/>&gt; <br/>&gt;use POSIX &quot;:sys_wait_h&quot;; <br/>&gt;1 while waitpid(WNOHANG, -1) &gt; 0; <br/>&gt; <br/>&gt;It&#39;s a bit of a pain, but I think it&#39;s better to explicitly ignore the problem than for it to go unnoticed by default. <br/>&gt; <br/>&gt;Please let me know whether that resolves your problem. It may not. For example, the processes may still be open until an object is destroyed at global destruction time. <br/>&gt; <br/>&gt;-- <br/>&gt;Rocco Caputo <br/>&gt; <br/>&gt;On Mar 24, 2014, at 05:46, albertocurro wrote: <br/>&gt; <br/>&gt;&gt; Guys, <br/>&gt;&gt; <br/>&gt;&gt; We have a product developed using POE as a base framework, with some other tool libraries as log4perl; basically is a forward proxy, composed of several modules, each one of them comprising a POE::Session; all of them share an internal queue of tasks to be performed. Each module performs several tasks on initialization, and if anything goes wrong, croak() is called to stop the service -&gt; this is considered ok, since croak() is only called during initialization, when validation is being performed. <br/>&gt;&gt; <br/>&gt;&gt; The product is stable and works really fine, but recently I updated POE to the latest version, and since then we can see this message in the logs: <br/>&gt;&gt; <br/>&gt;&gt; registering pdu failed: 263! <br/>&gt;&gt; === 5267 === 5 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt;&gt; === 5267 === 5 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt;&gt; === 5267 === 9 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt;&gt; === 5267 === 9 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt;&gt; === 5267 === !!! Kernel has child processes. <br/>&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt;&gt; mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147 <br/>&gt;&gt; <br/>&gt;&gt; first lines and last line above are the errors itself, but this part is new since the upgrading: <br/>&gt;&gt; <br/>&gt;&gt; === 5267 === !!! Kernel has child processes. <br/>&gt;&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt;&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt;&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt;&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt;&gt; <br/>&gt;&gt; I can see it everytime the service is stopped because of an unhandled condition, even when POE&#39;s event loop has been already running for ours. It was not visible before, and I can&#39;t get rid of it in any way. I&#39;ve tried different ways to avoid it with no luck. <br/>&gt;&gt; <br/>&gt;&gt; Any advice or alternative approach on this? <br/>&gt;&gt; <br/>&gt;&gt; Many thanks <br/>&gt;&gt; Alberto <br/>&gt;&gt; <br/>&gt; <br/>&gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/03/msg5078.html Mon, 24 Mar 2014 15:45:56 +0000 Re: Slow fork bomb message in latest version of POE by Rocco Caputo Hi, Alberto. <br/> <br/>At program end time, POE runs a quick waitpid() check for child processes that may have leaked. This check was added after a bug report where POE locked up a server after several days of running. It turned out to be the reporter&#39;s application, but it was hard to debug. <br/> <br/>Your program seems to have created two processes that it didn&#39;t reap: PIDs 5373 and 5374. The ideal solution is to reap those processes before exiting. Your program can do this using POE::Kernel&#39;s sig_child() method. <br/> <br/>In some cases, a third-party library will create processes and not properly clean them up. It can be impossible to solve this case without modifying other people&#39;s code. <br/> <br/>If you just want to ignore the problem, this might do the trick. Put these lines in your last _stop handler. They should reap the processes you&#39;ve leaked before POE&#39;s check: <br/> <br/>use POSIX &quot;:sys_wait_h&quot;; <br/>1 while waitpid(WNOHANG, -1) &gt; 0; <br/> <br/>It&#39;s a bit of a pain, but I think it&#39;s better to explicitly ignore the problem than for it to go unnoticed by default. <br/> <br/>Please let me know whether that resolves your problem. It may not. For example, the processes may still be open until an object is destroyed at global destruction time. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>On Mar 24, 2014, at 05:46, albertocurro &lt;albertocurro@zoho.com&gt; wrote: <br/> <br/>&gt; Guys, <br/>&gt; <br/>&gt; We have a product developed using POE as a base framework, with some other tool libraries as log4perl; basically is a forward proxy, composed of several modules, each one of them comprising a POE::Session; all of them share an internal queue of tasks to be performed. Each module performs several tasks on initialization, and if anything goes wrong, croak() is called to stop the service -&gt; this is considered ok, since croak() is only called during initialization, when validation is being performed. <br/>&gt; <br/>&gt; The product is stable and works really fine, but recently I updated POE to the latest version, and since then we can see this message in the logs: <br/>&gt; <br/>&gt; registering pdu failed: 263! <br/>&gt; === 5267 === 5 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt; === 5267 === 5 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt; === 5267 === 9 -&gt; on_handle (from Handler/StoreRemote.pm at 87) <br/>&gt; === 5267 === 9 -&gt; on_retry (from Handler/StoreRemote.pm at 141) <br/>&gt; === 5267 === !!! Kernel has child processes. <br/>&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt; mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147 <br/>&gt; <br/>&gt; first lines and last line above are the errors itself, but this part is new since the upgrading: <br/>&gt; <br/>&gt; === 5267 === !!! Kernel has child processes. <br/>&gt; === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt; === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return. <br/>&gt; === 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return. <br/>&gt; === 5267 === !!! Be sure to use sig_child() to reap child processes. <br/>&gt; === 5267 === !!! In extreme cases, failure to reap child processes has <br/>&gt; === 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems. <br/>&gt; <br/>&gt; I can see it everytime the service is stopped because of an unhandled condition, even when POE&#39;s event loop has been already running for ours. It was not visible before, and I can&#39;t get rid of it in any way. I&#39;ve tried different ways to avoid it with no luck. <br/>&gt; <br/>&gt; Any advice or alternative approach on this? <br/>&gt; <br/>&gt; Many thanks <br/>&gt; Alberto <br/>&gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/03/msg5077.html Mon, 24 Mar 2014 12:46:13 +0000 Slow fork bomb message in latest version of POE by albertocurro Guys,<br/><br/> We have a product developed using POE as a base framework, with some other tool libraries as log4perl; basically is a forward proxy, composed of several modules, each one of them comprising a POE::Session; all of them share an internal queue of tasks to be performed. Each module performs several tasks on initialization, and if anything goes wrong, croak() is called to stop the service -&gt; this is considered ok, since croak() is only called during initialization, when validation is being performed.<br/><br/> The product is stable and works really fine, but recently I updated POE to the latest version, and since then we can see this message in the logs:<br/><br/>registering pdu failed: 263!<br/>=== 5267 === 5 -&gt; on_handle (from Handler/StoreRemote.pm at 87)<br/>=== 5267 === 5 -&gt; on_retry (from Handler/StoreRemote.pm at 141)<br/>=== 5267 === 9 -&gt; on_handle (from Handler/StoreRemote.pm at 87)<br/>=== 5267 === 9 -&gt; on_retry (from Handler/StoreRemote.pm at 141)<br/>=== 5267 === !!! Kernel has child processes.<br/>=== 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return.<br/>=== 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return.<br/>=== 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return.<br/>=== 5267 === !!! Be sure to use sig_child() to reap child processes.<br/>=== 5267 === !!! In extreme cases, failure to reap child processes has<br/>=== 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems.<br/>mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147<br/><br/>first lines and last line above are the errors itself, but this part is new since the upgrading:<br/><br/>=== 5267 === !!! Kernel has child processes.<br/>=== 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-&gt;run() is ready to return.<br/>=== 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-&gt;run() is ready to return.<br/>=== 5267 === !!! At least one child process is still running when POE::Kernel-&gt;run() is ready to return.<br/>=== 5267 === !!! Be sure to use sig_child() to reap child processes.<br/>=== 5267 === !!! In extreme cases, failure to reap child processes has<br/>=== 5267 === !!! resulted in a slow &#39;fork bomb&#39; that has halted systems.<br/><br/>I can see it everytime the service is stopped because of an unhandled condition, even when POE&#39;s event loop has been already running for ours. It was not visible before, and I can&#39;t get rid of it in any way. I&#39;ve tried different ways to avoid it with no luck.<br/><br/>Any advice or alternative approach on this?<br/><br/>Many thanks<br/>Alberto<br/><br/> http://www.nntp.perl.org/group/perl.poe/2014/03/msg5076.html Mon, 24 Mar 2014 09:46:33 +0000 Custom ClientInputFilter for POE::Component::Server::TCP by Michael R. Davis POE Folks, <br/>I&#39;d like to use POE::Component::Server::TCP to read data from&nbsp;active network sensors but they have a&nbsp;proprietary protocol buffer like format.&nbsp; Is there a&nbsp;way to build a ClientInputFilter with multiple fixed length reads building on each other. <br/>&nbsp; <br/>byte-type, byte-payload-length, payload-of-specified-length <br/>&nbsp; <br/>An&nbsp;example <br/>&nbsp; <br/>&quot;\123\005ABCDE&quot; <br/>&quot;\124\000&quot; <br/>&quot;\125\001A&quot; <br/>&quot;\126\007ABCDEFG&quot; <br/>&nbsp; <br/>There is no &quot;line&quot; separator in the protocol. <br/>&nbsp; <br/>I currently already have a deserializer for each type that I&#39;d like to be able to plug into ClientInput $_[ARG0] somehow; <br/>&nbsp; <br/>In non-POE I just <br/>&nbsp; <br/>my $type=read_byte; <br/>my $length=unpack(&quot;C&quot;, read_byte); <br/>my $payload=read_bytes($length); <br/>my $object=My::Object::Factory-&gt;new(type=&gt;$type, data=&gt;$payload); <br/>&nbsp; <br/>Any pointers and help would be appreciated on how to get from here to there. <br/>Thanks, <br/>Mike http://www.nntp.perl.org/group/perl.poe/2014/02/msg5075.html Mon, 24 Feb 2014 15:39:27 +0000 Re: Need help for passing data back and forth data over apersistent SSL TCP socket by kai Thanks for this, works perfectly. And since I had so much trouble <br/>finding examples of working code with SSL authentication and a <br/>persistent connection to pass data over I figured I would post the <br/>working code back so it&#39;s in the archive for others to poke at and <br/>steal. This is mostly just a combo of examples from CPAN and the perl <br/>POE cookbook but it seems to work as I wanted and allows multiple <br/>persistent clients etc. With this sever I am authenticating every <br/>command sent by the client against it&#39;s SSL cert. Probably un-needed <br/>beyond the SSLifying of the initial connection but colour me paranoid.<br/><br/>Server code :<br/><br/>#!/usr/bin/perl<br/><br/> use strict;<br/> use warnings;<br/> use Socket;<br/> use POE qw(<br/> Wheel::SocketFactory<br/> Wheel::ReadWrite<br/> Driver::SysRW<br/> Filter::SSL<br/> Filter::Stackable<br/> Filter::Stream<br/> );<br/><br/><br/>my $serverport = 2001;<br/>my $debug = 1;<br/><br/>POE::Session-&gt;create(<br/> inline_states =&gt; {<br/> _start =&gt; \&amp;parent_start,<br/> _stop =&gt; \&amp;parent_stop,<br/><br/> socket_birth =&gt; \&amp;socket_birth,<br/> socket_death =&gt; \&amp;socket_death,<br/> }<br/>);<br/><br/>sub parent_start {<br/> my $heap = $_[HEAP];<br/> $heap-&gt;{debug} = 1;<br/> if ($heap-&gt;{debug}) { print &quot;= I = Starting POE session and <br/>initialising socket\n&quot;};<br/><br/> $heap-&gt;{listener} = POE::Wheel::SocketFactory-&gt;new(<br/> BindAddress =&gt; &#39;127.0.0.1&#39;,<br/> BindPort =&gt; $serverport,<br/> Reuse =&gt; &#39;yes&#39;,<br/> SuccessEvent =&gt; &#39;socket_birth&#39;,<br/> FailureEvent =&gt; &#39;socket_death&#39;,<br/> );<br/> if ($heap-&gt;{debug}) { print &quot;= I = Socket initialised Waiting for <br/>connections\n&quot;};<br/>}<br/><br/># clean up if we shut down the server<br/>sub parent_stop {<br/> my $heap = $_[HEAP];<br/> delete $heap-&gt;{listener};<br/> delete $heap-&gt;{session};<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= I = Listener Death!\n&quot;};<br/>}<br/><br/># open the socket for the remote session.<br/>sub socket_birth {<br/> my ($socket, $address, $port) = @_[ARG0, ARG1, ARG2];<br/> $address = inet_ntoa($address);<br/><br/> print &quot;\n= S = Socket birth client connecting\n&quot; if $debug;<br/><br/> POE::Session-&gt;create(<br/> inline_states =&gt; {<br/> _start =&gt; \&amp;socket_success,<br/> _stop =&gt; \&amp;socket_death,<br/><br/> socket_input =&gt; \&amp;socket_input,<br/> socket_death =&gt; \&amp;socket_death,<br/> },<br/> args =&gt; [$socket, $address, $port],<br/> );<br/><br/>}<br/><br/># close the socket session when the user exits.<br/>sub socket_death {<br/> my $heap = $_[HEAP];<br/> if ($heap-&gt;{socket_wheel}) {<br/> print &quot;= S = Socket death, client disconnected\n&quot; if $debug;<br/> delete $heap-&gt;{socket_wheel};<br/> }<br/>}<br/><br/># yay! we sucessfully opened a socket. Set up the session.<br/>sub socket_success {<br/> my ($heap, $kernel, $connected_socket, $address, $port) = <br/>@_[HEAP, KERNEL, ARG0, ARG1, ARG2];<br/><br/><br/> $heap-&gt;{debug} = 1;<br/> print &quot;= I = CONNECTION from $address : $port \n&quot; if <br/>$heap-&gt;{debug};<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= SSL = Creating SSL Object\n&quot;};<br/> ## make your own certificates to use here. Standard Cert <br/>creation. I used easy-rsa which is part of the openvpn package. Makes it <br/>really easy. As defined here: <br/>http://www.hermann-uwe.de/blog/howto-using-openvpn-on-debian-gnu-linux <br/>to the point of building client1 then you can stop.<br/> $heap-&gt;{sslfilter} = POE::Filter::SSL-&gt;new(<br/> crt =&gt; &#39;keys/server.crt&#39;,<br/> key =&gt; &#39;keys/server.key&#39;,<br/> cacrt =&gt; &#39;keys/ca.crt&#39;,<br/> cipher =&gt; &#39;DHE-RSA-AES256-GCM-SHA384:AES256-SHA&#39;,<br/> debug =&gt; 1,<br/> clientcert =&gt; 1<br/> );<br/> );<br/> $heap-&gt;{socket_wheel} = POE::Wheel::ReadWrite-&gt;new(<br/> Handle =&gt; $connected_socket,<br/> Driver =&gt; POE::Driver::SysRW-&gt;new(),<br/> Filter =&gt; POE::Filter::Stackable-&gt;new(Filters =&gt; [<br/> $heap-&gt;{sslfilter},<br/> POE::Filter::Stream-&gt;new(),<br/> ]),<br/> InputEvent =&gt; &#39;socket_input&#39;,<br/> ErrorEvent =&gt; &#39;socket_death&#39;,<br/> );<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= SSL = SSL connection <br/>established!\n&quot;};<br/>}<br/><br/>sub socket_input {<br/><br/> my ($heap, $kernel, $buf) = @_[HEAP, KERNEL, ARG0];<br/> my $response;<br/> my $sub;<br/> my (@certid) = ($heap-&gt;{sslfilter}-&gt;clientCertIds());<br/> my $content = &#39;&#39;;<br/> $heap-&gt;{debug} = 1;<br/> chomp($buf);<br/> if ($_[HEAP]-&gt;{debug}) {print &quot;= I = Clint command received : <br/>$buf\n&quot;};<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= SSL = Authing Client <br/>Command\n&quot;};<br/> if ($heap-&gt;{sslfilter}-&gt;clientCertValid()) {<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= SSL = Client <br/>Certificate Valid, Authorised\n&quot;};<br/> # this is where you take your input from the client, do <br/>something with it and send something back. I am getting temperature <br/>values and sending them to the client. YMMV<br/> if ($buf eq &quot;temp&quot;) {<br/> $content = `/home/pi/c0de/sht15/temp-munin.py`;<br/> } else {<br/> $content = &quot;Unknown request\n&quot;;<br/> }<br/> my $response = $content;<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= I = Sending Client <br/>Result: $content\n&quot;};<br/> $heap-&gt;{socket_wheel}-&gt;put($response);<br/> } else {<br/> # User is a bad bad person. No cookie!<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= SSL = Client <br/>Certificate Invalid! Rejecting command and disconnecting!\n&quot;};<br/> $content = &quot;INVALID CERT! Connection rejected!\n&quot;;<br/> my $response = $content;<br/> $heap-&gt;{socket_wheel}-&gt;put($response);<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;= I = Sending Client <br/>Result: $content\n&quot;};<br/> $kernel-&gt;delay(socket_death =&gt; 1);<br/> }<br/>}<br/><br/>$poe_kernel-&gt;run();<br/>## END OF LINE<br/><br/>Client code:<br/><br/>#!/usr/bin/perl<br/><br/> use warnings;<br/> use strict;<br/><br/> use POE qw(Component::Client::TCP Filter::SSL);<br/><br/> POE::Component::Client::TCP-&gt;new(<br/> RemoteAddress =&gt; &quot;localhost&quot;,<br/> RemotePort =&gt; 2001,<br/> ## make your own certificates to use here. Standard Cert creation. I <br/>used easy-rsa which is part of the openvpn package. Makes it really <br/>easy. As defined here: <br/>http://www.hermann-uwe.de/blog/howto-using-openvpn-on-debian-gnu-linux <br/>to the point of building client1 then you can stop.<br/> Filter =&gt; [ &quot;POE::Filter::SSL&quot;, crt =&gt; &#39;keys/client1.crt&#39;, <br/>key =&gt; &#39;keys/client1.key&#39;, client =&gt; 1 ],<br/> Connected =&gt; sub {<br/> $_[HEAP]-&gt;{next_alarm_time} = int(time()); # Immediately <br/>trigger an alarm<br/> $_[KERNEL]-&gt;alarm(tick =&gt; $_[HEAP]-&gt;{next_alarm_time});<br/><br/> },<br/> ServerInput =&gt; sub {<br/> print &quot;from server: &quot;.$_[ARG0].&quot;\n&quot;;<br/> },<br/> InlineStates =&gt; {<br/> tick =&gt; sub {<br/> #send the server a command server input will <br/>then capture the response while this bit waits 10 seconds and then does <br/>it all again. Thanks to Gunnar on the POE mailing list for help with <br/>this.<br/> my $command = &quot;temp&quot;;<br/> print &quot;Sending to server : $command\n&quot;;<br/> $_[HEAP]{server}-&gt;put($command);<br/> $_[HEAP]-&gt;{next_alarm_time}+=10;<br/> $_[KERNEL]-&gt;alarm(tick =&gt; <br/>$_[HEAP]-&gt;{next_alarm_time});<br/> },<br/> }<br/> );<br/><br/>POE::Kernel-&gt;run();<br/>## END OF LINE<br/><br/>Thanks for the help and I hope this helps someone in the future.<br/><br/>Kai<br/><br/>On 2014-02-21 18:14, Gunnar Strand wrote:<br/>&gt; Hi,<br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; 2014-02-21 1:48 GMT+01:00 &lt;kai@angry-monk.com&gt;:<br/>&gt;&gt; Hi there,<br/>&gt;&gt; <br/>&gt;&gt; I&#39;m trying to write a POE based server/client combo that uses SSL <br/>&gt;&gt; authed<br/>&gt;&gt; persistent connections for comunication between a client and server.<br/>&gt;&gt; <br/>&gt;&gt; Basically I have a server running that listens on port 2001. A client<br/>&gt;&gt; connects to the server. Sets up an SSL connection with client <br/>&gt;&gt; certificate<br/>&gt;&gt; auth and then what I _want_ to happen is that the client then (every <br/>&gt;&gt; 10<br/>&gt;&gt; seconds) asks for new temperature data from the server and is served <br/>&gt;&gt; the<br/>&gt;&gt; current value. I have the client asking in a loop every 10 seconds but <br/>&gt;&gt; the<br/>&gt;&gt; server isn&#39;t triggering and responding past the first connection <br/>&gt;&gt; event. I&#39;m<br/>&gt;&gt; not sure I&#39;m doing this right (tm) can anyone help me? I have some <br/>&gt;&gt; inline<br/>&gt;&gt; comments in the code.<br/>&gt; <br/>&gt; You need to have a look at timers for POE:<br/>&gt; <br/>&gt; http://poe.perl.org/?POE_Cookbook/Recurring_Alarms<br/>&gt; <br/>&gt;&gt; <br/>&gt;&gt; client :<br/>&gt;&gt; <br/>&gt;&gt; #!/usr/bin/perl<br/>&gt;&gt; <br/>&gt;&gt; ### very simple connect to server with auth certs and when connected <br/>&gt;&gt; sends<br/>&gt;&gt; the &quot;temp&quot; command.<br/>&gt;&gt; ### then when it receives input it fires off Server input and wait 10 <br/>&gt;&gt; then<br/>&gt;&gt; sends again. But<br/>&gt;&gt; ### should it trigger a input event again? I think I&#39;m looping in POE<br/>&gt;&gt; incorrectly.<br/>&gt;&gt; <br/>&gt;&gt; ServerInput =&gt; sub {<br/>&gt;&gt; my $command = &quot;temp&quot;;<br/>&gt;&gt; while(1) {<br/>&gt;&gt; print &quot;from server: &quot;.$_[ARG0].&quot;\n&quot;;<br/>&gt;&gt; sleep (10);<br/>&gt;&gt; print &quot;Sending to server : $command\n&quot;;<br/>&gt;&gt; $_[HEAP]{server}-&gt;put($command);<br/>&gt;&gt; }<br/>&gt; <br/>&gt; You are correct that you are &quot;looping&quot; incorrectly. POE is<br/>&gt; event-driven and uses run-to-completion scheduling<br/>&gt; which means that each subroutine must exit before the POE Kernel can<br/>&gt; schedule the next event.<br/>&gt; <br/>&gt; You need to 1) set up a recurring alarm and corresponding event<br/>&gt; handler which sends &quot;$command&quot; to the server,<br/>&gt; and 2) handle data from the server in &quot;ServerInput&quot; and then return<br/>&gt; from the subroutine.<br/>&gt; <br/>&gt; Add an alarm to &quot;Connected&quot;:<br/>&gt; <br/>&gt; $_[HEAP]-&gt;{next_alarm_time} = int(time()); # Immediately<br/>&gt; trigger an alarm<br/>&gt; $_[KERNEL]-&gt;alarm(tick =&gt; $_[HEAP]-&gt;{next_alarm_time});<br/>&gt; <br/>&gt; Add an inline state &quot;tick&quot; event:<br/>&gt; <br/>&gt; tick =&gt; sub {<br/>&gt; my $command = &quot;temp&quot;;<br/>&gt; print &quot;Sending to server : $command\n&quot;;<br/>&gt; $_[HEAP]{server}-&gt;put($command);<br/>&gt; $_[HEAP]-&gt;{next_alarm_time}+=10;<br/>&gt; $_[KERNEL]-&gt;alarm(tick =&gt; $_[HEAP]-&gt;{next_alarm_time});<br/>&gt; },<br/>&gt; <br/>&gt; See <br/>&gt; http://search.cpan.org/dist/POE/lib/POE/Component/Client/TCP.pm#InlineStates<br/>&gt; <br/>&gt; Remove *everything* from the &quot;while&quot; loop except the &quot;print&quot;.<br/>&gt; <br/>&gt; I have never dabbled in SSL, so I can&#39;t verify the server function, but <br/>&gt; perhaps<br/>&gt; POE::Component::Server::TCP could relieve you of some of the socket <br/>&gt; handling<br/>&gt; in the server part.<br/>&gt; <br/>&gt; http://search.cpan.org/~rcaputo/POE/lib/POE/Component/Server/TCP.pm<br/>&gt; <br/>&gt; BR<br/>&gt; Gunnar<br/> http://www.nntp.perl.org/group/perl.poe/2014/02/msg5074.html Mon, 24 Feb 2014 12:39:32 +0000 Re: POCO IRC Proxy plugin by Celso Barriga OK thanks for the explanation. I think I got, but I have to play around with it, I guess. it sounds very interesting though!!! <br/> <br/> <br/>On Feb 22, 2014, at 7:42 PM, Rocco Caputo &lt;rcaputo@pobox.com&gt; wrote: <br/> <br/>&gt; The docs say it&#39;s a simple bouncer that lets you hide many bots and/or clients behind a single IRC connection. Benefits? <br/>&gt; <br/>&gt; If you&#39;re developing bots that crash a lot, you can hide them behind a stable proxy that doesn&#39;t annoy everyone with frequent reconnections. <br/>&gt; <br/>&gt; If you develop a lot of bots, you can put them all behind one IRC connection. This may keep you from being banned by servers that have low connection limits. <br/>&gt; <br/>&gt; If a channel lets you only have one bot, you can cheat. :) <br/>&gt; <br/>&gt; Other things, only limited by the intersection of the implemented features and your imagination! <br/>&gt; <br/>&gt; -- <br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/>&gt; <br/>&gt; On Feb 22, 2014, at 15:49, Celso Barriga &lt;cbarriga@gmail.com&gt; wrote: <br/>&gt; <br/>&gt;&gt; Can somebody please tell me what this plugin actually do? I&#39;ve read the docs, and if I understand it correctly, by default, it opens up a random port on localhost (if no bindaddress and binport are specified) where the POCO IRC would then connect to. What&#39;s the advantage of doing this and what does this give me? <br/>&gt;&gt; <br/>&gt;&gt; Thanks in advance. <br/>&gt;&gt; <br/>&gt;&gt; Best regards, <br/>&gt;&gt; Celso <br/>&gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/02/msg5073.html Sun, 23 Feb 2014 23:13:26 +0000 Re: POCO IRC Proxy plugin by =?UTF-8?B?6rmA7Jyg66+8?= L<br/><br/>On Saturday, February 22, 2014, Rocco Caputo &lt;rcaputo@pobox.com&gt; wrote:<br/><br/>&gt; The docs say it&#39;s a simple bouncer that lets you hide many bots and/or<br/>&gt; clients behind a single IRC connection. Benefits?<br/>&gt;<br/>&gt; If you&#39;re developing bots that crash a lot, you can hide them behind a<br/>&gt; stable proxy that doesn&#39;t annoy everyone with frequent reconnections.<br/>&gt;<br/>&gt; If you develop a lot of bots, you can put them all behind one IRC<br/>&gt; connection. This may keep you from being banned by servers that have low<br/>&gt; connection limits.<br/>&gt;<br/>&gt; If a channel lets you only have one bot, you can cheat. :)<br/>&gt;<br/>&gt; Other things, only limited by the intersection of the implemented features<br/>&gt; and your imagination!<br/>&gt;<br/>&gt; --<br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com &lt;javascript:;&gt;&gt;<br/>&gt;<br/>&gt; On Feb 22, 2014, at 15:49, Celso Barriga &lt;cbarriga@gmail.com&lt;javascript:;&gt;&gt;<br/>&gt; wrote:<br/>&gt;<br/>&gt; &gt; Can somebody please tell me what this plugin actually do? I&#39;ve read the<br/>&gt; docs, and if I understand it correctly, by default, it opens up a random<br/>&gt; port on localhost (if no bindaddress and binport are specified) where the<br/>&gt; POCO IRC would then connect to. What&#39;s the advantage of doing this and what<br/>&gt; does this give me?<br/>&gt; &gt;<br/>&gt; &gt; Thanks in advance.<br/>&gt; &gt;<br/>&gt; &gt; Best regards,<br/>&gt; &gt; Celso<br/>&gt;<br/>&gt; http://www.nntp.perl.org/group/perl.poe/2014/02/msg5072.html Sun, 23 Feb 2014 00:46:54 +0000 Re: POCO IRC Proxy plugin by Rocco Caputo The docs say it&#39;s a simple bouncer that lets you hide many bots and/or clients behind a single IRC connection. Benefits? <br/> <br/>If you&#39;re developing bots that crash a lot, you can hide them behind a stable proxy that doesn&#39;t annoy everyone with frequent reconnections. <br/> <br/>If you develop a lot of bots, you can put them all behind one IRC connection. This may keep you from being banned by servers that have low connection limits. <br/> <br/>If a channel lets you only have one bot, you can cheat. :) <br/> <br/>Other things, only limited by the intersection of the implemented features and your imagination! <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>On Feb 22, 2014, at 15:49, Celso Barriga &lt;cbarriga@gmail.com&gt; wrote: <br/> <br/>&gt; Can somebody please tell me what this plugin actually do? I&#39;ve read the docs, and if I understand it correctly, by default, it opens up a random port on localhost (if no bindaddress and binport are specified) where the POCO IRC would then connect to. What&#39;s the advantage of doing this and what does this give me? <br/>&gt; <br/>&gt; Thanks in advance. <br/>&gt; <br/>&gt; Best regards, <br/>&gt; Celso <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/02/msg5071.html Sun, 23 Feb 2014 00:42:50 +0000 POCO IRC Proxy plugin by Celso Barriga Can somebody please tell me what this plugin actually do? I&#39;ve read the<br/>docs, and if I understand it correctly, by default, it opens up a random<br/>port on localhost (if no bindaddress and binport are specified) where the<br/>POCO IRC would then connect to. What&#39;s the advantage of doing this and what<br/>does this give me?<br/><br/>Thanks in advance.<br/><br/>Best regards,<br/>Celso http://www.nntp.perl.org/group/perl.poe/2014/02/msg5070.html Sat, 22 Feb 2014 20:49:33 +0000 Re: Need help for passing data back and forth data over a persistentSSL TCP socket by Gunnar Strand Hi,<br/><br/><br/><br/>2014-02-21 1:48 GMT+01:00 &lt;kai@angry-monk.com&gt;:<br/>&gt; Hi there,<br/>&gt;<br/>&gt; I&#39;m trying to write a POE based server/client combo that uses SSL authed<br/>&gt; persistent connections for comunication between a client and server.<br/>&gt;<br/>&gt; Basically I have a server running that listens on port 2001. A client<br/>&gt; connects to the server. Sets up an SSL connection with client certificate<br/>&gt; auth and then what I _want_ to happen is that the client then (every 10<br/>&gt; seconds) asks for new temperature data from the server and is served the<br/>&gt; current value. I have the client asking in a loop every 10 seconds but the<br/>&gt; server isn&#39;t triggering and responding past the first connection event. I&#39;m<br/>&gt; not sure I&#39;m doing this right (tm) can anyone help me? I have some inline<br/>&gt; comments in the code.<br/><br/>You need to have a look at timers for POE:<br/><br/>http://poe.perl.org/?POE_Cookbook/Recurring_Alarms<br/><br/>&gt;<br/>&gt; client :<br/>&gt;<br/>&gt; #!/usr/bin/perl<br/>&gt;<br/>&gt; ### very simple connect to server with auth certs and when connected sends<br/>&gt; the &quot;temp&quot; command.<br/>&gt; ### then when it receives input it fires off Server input and wait 10 then<br/>&gt; sends again. But<br/>&gt; ### should it trigger a input event again? I think I&#39;m looping in POE<br/>&gt; incorrectly.<br/>&gt;<br/>&gt; ServerInput =&gt; sub {<br/>&gt; my $command = &quot;temp&quot;;<br/>&gt; while(1) {<br/>&gt; print &quot;from server: &quot;.$_[ARG0].&quot;\n&quot;;<br/>&gt; sleep (10);<br/>&gt; print &quot;Sending to server : $command\n&quot;;<br/>&gt; $_[HEAP]{server}-&gt;put($command);<br/>&gt; }<br/><br/>You are correct that you are &quot;looping&quot; incorrectly. POE is<br/>event-driven and uses run-to-completion scheduling<br/>which means that each subroutine must exit before the POE Kernel can<br/>schedule the next event.<br/><br/>You need to 1) set up a recurring alarm and corresponding event<br/>handler which sends &quot;$command&quot; to the server,<br/>and 2) handle data from the server in &quot;ServerInput&quot; and then return<br/>from the subroutine.<br/><br/>Add an alarm to &quot;Connected&quot;:<br/><br/> $_[HEAP]-&gt;{next_alarm_time} = int(time()); # Immediately<br/>trigger an alarm<br/> $_[KERNEL]-&gt;alarm(tick =&gt; $_[HEAP]-&gt;{next_alarm_time});<br/><br/>Add an inline state &quot;tick&quot; event:<br/><br/> tick =&gt; sub {<br/> my $command = &quot;temp&quot;;<br/> print &quot;Sending to server : $command\n&quot;;<br/> $_[HEAP]{server}-&gt;put($command);<br/> $_[HEAP]-&gt;{next_alarm_time}+=10;<br/> $_[KERNEL]-&gt;alarm(tick =&gt; $_[HEAP]-&gt;{next_alarm_time});<br/> },<br/><br/>See http://search.cpan.org/dist/POE/lib/POE/Component/Client/TCP.pm#InlineStates<br/><br/>Remove *everything* from the &quot;while&quot; loop except the &quot;print&quot;.<br/><br/>I have never dabbled in SSL, so I can&#39;t verify the server function, but perhaps<br/>POE::Component::Server::TCP could relieve you of some of the socket handling<br/>in the server part.<br/><br/>http://search.cpan.org/~rcaputo/POE/lib/POE/Component/Server/TCP.pm<br/><br/>BR<br/>Gunnar<br/> http://www.nntp.perl.org/group/perl.poe/2014/02/msg5069.html Fri, 21 Feb 2014 10:14:07 +0000 Need help for passing data back and forth data over a persistentSSL TCP socket by kai Hi there,<br/><br/>I&#39;m trying to write a POE based server/client combo that uses SSL authed <br/>persistent connections for comunication between a client and server.<br/><br/>Basically I have a server running that listens on port 2001. A client <br/>connects to the server. Sets up an SSL connection with client <br/>certificate auth and then what I _want_ to happen is that the client <br/>then (every 10 seconds) asks for new temperature data from the server <br/>and is served the current value. I have the client asking in a loop <br/>every 10 seconds but the server isn&#39;t triggering and responding past the <br/>first connection event. I&#39;m not sure I&#39;m doing this right (tm) can <br/>anyone help me? I have some inline comments in the code.<br/><br/>client :<br/><br/>#!/usr/bin/perl<br/><br/>### very simple connect to server with auth certs and when connected <br/>sends the &quot;temp&quot; command.<br/>### then when it receives input it fires off Server input and wait 10 <br/>then sends again. But<br/>### should it trigger a input event again? I think I&#39;m looping in POE <br/>incorrectly.<br/><br/> use warnings;<br/> use strict;<br/><br/> use POE qw(Component::Client::TCP Filter::SSL);<br/><br/> POE::Component::Client::TCP-&gt;new(<br/> RemoteAddress =&gt; &quot;localhost&quot;,<br/> RemotePort =&gt; 2001,<br/> Filter =&gt; [ &quot;POE::Filter::SSL&quot;, crt =&gt; &#39;keys/client1.crt&#39;, <br/>key =&gt; &#39;keys/client1.key&#39;, client =&gt; 1 ],<br/> Connected =&gt; sub {<br/> $_[HEAP]{server}-&gt;put(&quot;temp&quot;);<br/><br/> },<br/> ServerInput =&gt; sub {<br/> my $command = &quot;temp&quot;;<br/> while(1) {<br/> print &quot;from server: &quot;.$_[ARG0].&quot;\n&quot;;<br/> sleep (10);<br/> print &quot;Sending to server : $command\n&quot;;<br/> $_[HEAP]{server}-&gt;put($command);<br/> }<br/><br/> },<br/> );<br/><br/> POE::Kernel-&gt;run();<br/> exit;<br/><br/><br/>Server code :<br/><br/>#!/usr/bin/perl<br/><br/> use strict;<br/> use warnings;<br/> use Socket;<br/> use POE qw(<br/> Wheel::SocketFactory<br/> Wheel::ReadWrite<br/> Driver::SysRW<br/> Filter::SSL<br/> Filter::Stackable<br/> Filter::HTTPD<br/> );<br/><br/><br/> POE::Session-&gt;create(<br/> inline_states =&gt; {<br/> _start =&gt; sub {<br/> my $heap = $_[HEAP];<br/> $heap-&gt;{debug} = 1;<br/> if ($heap-&gt;{debug}) { print &quot;Stating POE session and <br/>initialising socket\n&quot;};<br/> $heap-&gt;{listener} = POE::Wheel::SocketFactory-&gt;new(<br/> BindAddress =&gt; &#39;localhost&#39;,<br/> BindPort =&gt; 2001,<br/> Reuse =&gt; &#39;yes&#39;,<br/> SuccessEvent =&gt; &#39;socket_birth&#39;,<br/> FailureEvent =&gt; &#39;_stop&#39;,<br/> );<br/> if ($heap-&gt;{debug}) { print &quot;Socket initialised Waiting for <br/>connections\n&quot;};<br/> },<br/> _stop =&gt; sub {<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Socket Binding Failed!\n&quot;};<br/> delete $_[HEAP]-&gt;{listener};<br/> },<br/> socket_birth =&gt; sub {<br/> my ($socket) = $_[ARG0];<br/> POE::Session-&gt;create(<br/> inline_states =&gt; {<br/> _start =&gt; sub {<br/> my ($heap, $kernel, $connected_socket, $address, $port) = <br/>@_[HEAP, KERNEL, ARG0, ARG1, ARG2];<br/> $heap-&gt;{debug} = 1;<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Creating SSL Object\n&quot;};<br/> $heap-&gt;{sslfilter} = POE::Filter::SSL-&gt;new(<br/> crt =&gt; &#39;keys/server.crt&#39;,<br/> key =&gt; &#39;keys/server.key&#39;,<br/> cacrt =&gt; &#39;keys/ca.crt&#39;,<br/> cipher =&gt; &#39;DHE-RSA-AES256-GCM-SHA384:AES256-SHA&#39;,<br/> debug =&gt; 1,<br/> clientcert =&gt; 1<br/> );<br/> $heap-&gt;{socket_wheel} = POE::Wheel::ReadWrite-&gt;new(<br/> Handle =&gt; $connected_socket,<br/> Driver =&gt; POE::Driver::SysRW-&gt;new(),<br/> Filter =&gt; $heap-&gt;{sslfilter},<br/> InputEvent =&gt; &#39;socket_input&#39;,<br/> ErrorEvent =&gt; &#39;_stop&#39;,<br/> );<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Connection made!\n&quot;};<br/> },<br/> socket_input =&gt; sub {<br/> my ($kernel, $heap, $buf) = @_[KERNEL, HEAP, ARG0];<br/> print &quot;RECEIVE : $buf\n&quot;;<br/> my (@certid) = ($heap-&gt;{sslfilter}-&gt;clientCertIds());<br/> my $content = &#39;&#39;;<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Authing Client\n&quot;};<br/> if ($heap-&gt;{sslfilter}-&gt;clientCertValid()) {<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Client Certificate <br/>Valid, Authorised\n&quot;};<br/> if ($buf eq &quot;temp&quot;) {<br/> $content = <br/>`/home/pi/c0de/sht15/temp-munin.py`;<br/> } else {<br/> $content = &quot;Unknown request\n&quot;;<br/> }<br/> my $response = $content;<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Sending Client <br/>$content\n&quot;};<br/> $heap-&gt;{socket_wheel}-&gt;put($response);<br/> return (1);<br/> #$kernel-&gt;delay(_stop =&gt; 1);<br/> } else {<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Client Certificate <br/>Invalid, Rejecting connection\n&quot;};<br/> $content .= &quot;INVALID CERT! Connection rejected!\n&quot;;<br/> my $response = $content;<br/> $heap-&gt;{socket_wheel}-&gt;put($response);<br/> $kernel-&gt;delay(_stop =&gt; 1);<br/> }<br/> },<br/> _stop =&gt; sub {<br/> if ($_[HEAP]-&gt;{debug}) { print &quot;Client Disconnected\n&quot;};<br/> delete $_[HEAP]-&gt;{socket_wheel};<br/> }<br/> },<br/> args =&gt; [$socket],<br/> );<br/> }<br/> }<br/> );<br/><br/> $poe_kernel-&gt;run();<br/><br/>Any help anyone can provide would be awesome. I want to avoid <br/>disconnecting and reconnecting ever time I want to get a reading. So <br/>once the connection is made I want to be able to just send a request and <br/>get an answer in an endless loop. I think this should work but can&#39;t <br/>figure out why.<br/><br/>Thanks!<br/> http://www.nntp.perl.org/group/perl.poe/2014/02/msg5068.html Fri, 21 Feb 2014 00:48:32 +0000 Re: Saving application state by Celso Barriga Thanks guys.<br/><br/>I think I&#39;ll go with Rocco&#39;s suggestion. Since I&#39;ll be reading and writing<br/>probably only 7 to 10 characters, should be no worries about call being<br/>blocked. Besides, I probably want the previous data already in the file<br/>before the next iteration, now that I think about it. And I also like your<br/>suggestion about using File::AtomicWrite.<br/><br/><br/>On Thu, Feb 13, 2014 at 1:37 PM, Rocco Caputo &lt;rcaputo@pobox.com&gt; wrote:<br/><br/>&gt; Hi, Celso.<br/>&gt;<br/>&gt; This isn&#39;t a job for POE.<br/>&gt;<br/>&gt; Use File::AtomicWrite, or something like it, to safely write the time<br/>&gt; stamp as frequently as necessary. It&#39;s a trivial amount of data, so you<br/>&gt; probably don&#39;t need it written asynchronously.<br/>&gt;<br/>&gt; Reload the time stamp when the program restarts.<br/>&gt;<br/>&gt; --<br/>&gt; Rocco Caputo &lt;rcaputo@pobox.com&gt;<br/>&gt;<br/>&gt; On Feb 13, 2014, at 13:21, Celso Barriga &lt;cbarriga@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; &gt; Hello, it&#39;s me again :)<br/>&gt; &gt;<br/>&gt; &gt; I have a POE-based application that queries a web app for some data<br/>&gt; filtered on some time range, say, &quot;send me any changes from time x to now&quot;.<br/>&gt; &gt;<br/>&gt; &gt; The application will be running 24/7, and will query for more changes<br/>&gt; since the last time it asked for changes. I have a tick handler that keeps<br/>&gt; the heartbeat going every second so I can do the query repeatedly.<br/>&gt; &gt;<br/>&gt; &gt; I need to save the last time it made the query in some persistent<br/>&gt; fashion so I can pass it in my next query. I can&#39;t just save it to my heap<br/>&gt; in case the application quits, I need to be able to resume the query since<br/>&gt; the last successful query.<br/>&gt; &gt;<br/>&gt; &gt; What is the best way of doing this, the &quot;POE way&quot;. Can I just save it to<br/>&gt; a file and read it back every tick count, which is 1 sec, using a regular<br/>&gt; file handle?<br/>&gt; &gt;<br/>&gt; &gt; Thanks in advance!<br/>&gt; &gt;<br/>&gt; &gt; Celso<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt;<br/>&gt; http://www.nntp.perl.org/group/perl.poe/2014/02/msg5067.html Thu, 13 Feb 2014 18:52:42 +0000 Re: Saving application state by Rocco Caputo Hi, Celso. <br/> <br/>This isn&#39;t a job for POE. <br/> <br/>Use File::AtomicWrite, or something like it, to safely write the time stamp as frequently as necessary. It&#39;s a trivial amount of data, so you probably don&#39;t need it written asynchronously. <br/> <br/>Reload the time stamp when the program restarts. <br/> <br/>-- <br/>Rocco Caputo &lt;rcaputo@pobox.com&gt; <br/> <br/>On Feb 13, 2014, at 13:21, Celso Barriga &lt;cbarriga@gmail.com&gt; wrote: <br/> <br/>&gt; Hello, it&#39;s me again :) <br/>&gt; <br/>&gt; I have a POE-based application that queries a web app for some data filtered on some time range, say, &quot;send me any changes from time x to now&quot;. <br/>&gt; <br/>&gt; The application will be running 24/7, and will query for more changes since the last time it asked for changes. I have a tick handler that keeps the heartbeat going every second so I can do the query repeatedly. <br/>&gt; <br/>&gt; I need to save the last time it made the query in some persistent fashion so I can pass it in my next query. I can&#39;t just save it to my heap in case the application quits, I need to be able to resume the query since the last successful query. <br/>&gt; <br/>&gt; What is the best way of doing this, the &quot;POE way&quot;. Can I just save it to a file and read it back every tick count, which is 1 sec, using a regular file handle? <br/>&gt; <br/>&gt; Thanks in advance! <br/>&gt; <br/>&gt; Celso <br/>&gt; <br/>&gt; <br/> <br/> http://www.nntp.perl.org/group/perl.poe/2014/02/msg5066.html Thu, 13 Feb 2014 18:39:09 +0000 Saving application state by Celso Barriga Hello, it&#39;s me again :)<br/><br/>I have a POE-based application that queries a web app for some data<br/>filtered on some time range, say, &quot;send me any changes from time x to now&quot;.<br/><br/>The application will be running 24/7, and will query for more changes since<br/>the last time it asked for changes. I have a tick handler that keeps the<br/>heartbeat going every second so I can do the query repeatedly.<br/><br/>I need to save the last time it made the query in some persistent fashion<br/>so I can pass it in my next query. I can&#39;t just save it to my heap in case<br/>the application quits, I need to be able to resume the query since the last<br/>successful query.<br/><br/>What is the best way of doing this, the &quot;POE way&quot;. Can I just save it to a<br/>file and read it back every tick count, which is 1 sec, using a regular<br/>file handle?<br/><br/>Thanks in advance!<br/><br/>Celso http://www.nntp.perl.org/group/perl.poe/2014/02/msg5065.html Thu, 13 Feb 2014 18:21:11 +0000 Re: Need advice on a new POE project by Celso Barriga Thank you!<br/><br/>I&#39;m using PoCo::IRC and the basic gut of my app is currently working. It&#39;s<br/>already very feature rich with just about 300 lines of code.<br/><br/>POE Rocks!<br/><br/><br/>On Wed, Feb 12, 2014 at 1:50 AM, Evan Carroll &lt;me@evancarroll.com&gt; wrote:<br/><br/>&gt; Download and install Buubot,<br/>&gt;<br/>&gt; https://github.com/simcop2387/buubot<br/>&gt;<br/>&gt; review the code base and add the plugin that does what you want.<br/>&gt;<br/>&gt; --<br/>&gt; Evan Carroll - me@evancarroll.com<br/>&gt; System Lord of the Internets<br/>&gt; web: http://www.evancarroll.com<br/>&gt; ph: 281.901.0011<br/>&gt; http://www.nntp.perl.org/group/perl.poe/2014/02/msg5064.html Wed, 12 Feb 2014 21:34:51 +0000 Re: Need advice on a new POE project by Evan Carroll Download and install Buubot,<br/><br/>https://github.com/simcop2387/buubot<br/><br/>review the code base and add the plugin that does what you want.<br/><br/>-- <br/>Evan Carroll - me@evancarroll.com<br/>System Lord of the Internets<br/>web: http://www.evancarroll.com<br/>ph: 281.901.0011<br/> http://www.nntp.perl.org/group/perl.poe/2014/02/msg5063.html Wed, 12 Feb 2014 06:51:28 +0000