Re: Trigger an event from outside an event handler
POE::Kernel->post( $destination, "event", @optional_args ); -- Rocco Caputo <rcap...@pobox.com> > On Mar 29, 2016, at 10:25, pablo baez <pab_...@hotmail.com> wrote: > > Hi, > > I'm a POE newbie and looking at the documentation, I don'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? > > Thanks in advance.
Re: [COMMERCIAL] POE and Activestate perlapp fail on MacOSX
Hi, Craig.
According to http://code.activestate.com/lists/perl-tk/13841/ the error seems
to be coming from within Tk, so it's understandable the tests without Tk would
pass.
That URL suggests calling Tk::exit() or $poe_main_window->destroy() after
POE::Kernel->run() returns may solve the problem. I'm inclined to believe it
since the "during global destruction" 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.
Since your test program isn't calling POE::Kernel->run(), just invoking
$poe_main_window->destroy() or Tk::exit() at the end should be enough to see if
it's going to help.
The "-e syntax OK" suggests that the error is happening as a result of a "perl
-c" check within PerlApp. Can you reproduce the error with just "perl -c
mactst.pl"?
--
Rocco Caputo <rcap...@pobox.com>
> On Jan 5, 2016, at 08:42, Craig Votava <craig.vot...@alcatel-lucent.com>
> wrote:
>
> Hi Rocco-
>
> The PerlMonks solution seems to be for a different problem on a different
> platform, but this is a good suggestion that yielded interesting results:
>
> Needed to comment out POE::Resource:Statistics (when did that go away?)
> The perlapp fails when “use Tk;” is uncommented
> The perlapp succeeds when “use Tk;” is commented out
> The perlapp succeeds when all the POE lines are commented out and the “use
> Tk” is uncommented.
>
> So maybe the PerlMonks solution isn’t as far off as I thought. It looks like
> we have a perlapp-Tk-POE issue.
>
> What would be a good next step?
>
> Thanks
> -Craig
>
> #!/usr/local/ActivePerl-5.20/bin/perl
> use warnings;
> use strict;
>
> use Tk;
>
> use POE qw (Loop::TkActiveState);
> use POE::Loop::TkActiveState;
> use POE::Kernel;
> use POE::Session;
> use POE::Resource::Aliases;
> use POE::Resource::Events;
> use POE::Resource::Extrefs;
> use POE::Resource::FileHandles;
> use POE::Resource::Sessions;
> use POE::Resource::SIDs;
> use POE::Resource::Signals;
> #use POE::Resource::Statistics;
>
> if(! defined($poe_main_window)) { die "\$poe_main_window not defined" };
>
> $ perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean
> --force --lib lib --exe mca mactst.pl
> PerlApp 9.4.0 build 298593 (perl 5.14.0)
> Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved.
> Commercial license S2EB72B1777B for Craig Votava
> <craig.vot...@alcatel-lucent.com <mailto:craig.vot...@alcatel-lucent.com>>
>
> -e syntax OK
> Free non-Callback 1032e2a88 RV=0 during global destruction.
> . (1):
> 0 0x103801558 IV f=0001 undef(1)
> SV = IV(0x103801548) at 0x103801558
> REFCNT = 1
> FLAGS = ()
> IV = 0
> 'mactst.pl' had compilation errors.
>
>
>> On Jan 4, 2016, at 10:48 PM, Rocco Caputo <rcap...@pobox.com
>> <mailto:rcap...@pobox.com>> wrote:
>>
>> Hi, Craig.
>>
>> The PerlMonks thread you quoted ends with a solution to the OP's problem.
>> The mactst.pl you quoted doesn't seem to implement that solution, so my
>> first recommendation would be to try that.
>>
>> --
>> Rocco Caputo <rcap...@pobox.com <mailto:rcap...@pobox.com>>
>>
>>> On Jan 4, 2016, at 13:34, Craig Votava <craig.vot...@alcatel-lucent.com
>>> <mailto:craig.vot...@alcatel-lucent.com>> wrote:
>>>
>>> Folks-
>>>
>>> I’m running Yosemite (MacOSX 10.10.5) on a MacPro (Mid 2010) and am trying
>>> to use ActiveState’s perlapp to create an executable perl script.
>>>
>>> I have been successful in creating some perl scripts that don’t use POE,
>>> however when I try a script using POE, I get the following error:
>>>
>>> perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean
>>> --force --lib lib --exe mca mactst.pl
>>> PerlApp 9.4.0 build 298593 (perl 5.14.0)
>>> Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved.
>>> Commercial license S2EB72B1777B for Craig Votava
>>> <craig.vot...@alcatel-lucent.com <mailto:craig.vot...@alcatel-lucent.com>>
>>>
>>> -e syntax OK
>>> Free non-Callback 101ea3e08 RV=0 during global destruction.
>>> . (1):
>>> 0 0x104012158 IV f=0001 undef(1)
>>> SV = IV(0x104012148) at 0x104012158
>>> REFCNT = 1
>>> FLAGS = ()
>>> IV = 0
>>> 'mactst.pl' had compilation errors.
>>>
>>> The contents of mactst.pl is as follows:
>>>
>>> #!/usr/local/ActivePerl-5.20/bin/perl
>>> use warnings;
>>> use strict;
>>> use Tk;
>>> use POE;
>>>
>>> if(! defined($poe_main_window)) { die "\$poe_main_window not defined" };
>>>
>>> This *MAY* have something to do with an issue about the POE::Loop that gets
>>> selected (read about it here <http://www.perlmonks.org/?node_id=758312>),
>>> but I’m not sure.
>>>
>>> How can I debug this?
>>>
>>> Any help is much appreciated!
>>>
>>> Thanks
>>>
>>> -Craig
>>>
>>
>
Re: POE and Activestate perlapp fail on MacOSX
Hi, Craig.
The PerlMonks thread you quoted ends with a solution to the OP's problem. The
mactst.pl you quoted doesn't seem to implement that solution, so my first
recommendation would be to try that.
--
Rocco Caputo <rcap...@pobox.com>
> On Jan 4, 2016, at 13:34, Craig Votava <craig.vot...@alcatel-lucent.com>
> wrote:
>
> Folks-
>
> I’m running Yosemite (MacOSX 10.10.5) on a MacPro (Mid 2010) and am trying to
> use ActiveState’s perlapp to create an executable perl script.
>
> I have been successful in creating some perl scripts that don’t use POE,
> however when I try a script using POE, I get the following error:
>
> perlapp --perl /usr/local/ActivePerl-5.20/bin/perl --verbose --clean --force
> --lib lib --exe mca mactst.pl
> PerlApp 9.4.0 build 298593 (perl 5.14.0)
> Copyright (C) 1998-2014 ActiveState Software Inc. All rights reserved.
> Commercial license S2EB72B1777B for Craig Votava
> <craig.vot...@alcatel-lucent.com <mailto:craig.vot...@alcatel-lucent.com>>
>
> -e syntax OK
> Free non-Callback 101ea3e08 RV=0 during global destruction.
> . (1):
> 0 0x104012158 IV f=0001 undef(1)
> SV = IV(0x104012148) at 0x104012158
> REFCNT = 1
> FLAGS = ()
> IV = 0
> 'mactst.pl' had compilation errors.
>
> The contents of mactst.pl is as follows:
>
> #!/usr/local/ActivePerl-5.20/bin/perl
> use warnings;
> use strict;
> use Tk;
> use POE;
>
> if(! defined($poe_main_window)) { die "\$poe_main_window not defined" };
>
> This *MAY* have something to do with an issue about the POE::Loop that gets
> selected (read about it here <http://www.perlmonks.org/?node_id=758312>), but
> I’m not sure.
>
> How can I debug this?
>
> Any help is much appreciated!
>
> Thanks
>
> -Craig
>
Re: POE::Kernel->stop() will trigger _stop in the next release
Hi. With the limited information I have, I'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't limit my investigation to that scope, but I would start there.
--
Rocco Caputo <rcap...@pobox.com>
> On Nov 11, 2015, at 19:31, Deven Parekh <parekh.de...@gmail.com> wrote:
>
> Hello,
>
> Thank you for the quick response.
>
> I will try to generate a test case for the above.
>
> In the mean time if this helps, I did a hand edit to the stop subroutine in
> POE::Kernel and replaced
>
> $self->_data_ses_stop($session->ID);
>
> (which appears in the latest version )
>
> with
>
> $self->_data_ses_free($session->ID);
>
> (which was how it was in previous version)
>
> and the program is working as expected now.
>
>
> I will try to generate a test case and send it for debugging.
>
> Thanks in advance,
>
> Best Regards.
>
> On Tue, Nov 10, 2015 at 2:53 PM, Rocco Caputo <rcap...@pobox.com
> <mailto:rcap...@pobox.com>> wrote:
> I don't expect the change to cause the behavior you've reported.
>
> 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.
>
> --
> Rocco Caputo <rcap...@pobox.com <mailto:rcap...@pobox.com>>
>
>> On Nov 10, 2015, at 15:12, Deven Parekh <parekh.de...@gmail.com
>> <mailto:parekh.de...@gmail.com>> wrote:
>>
>> Hello,
>>
>> Is it possible that it breaks the following capability of POE::Wheel::Run
>> Running POE::Kernel in the Child <>
>> Calling POE::Kernel->run() in the child process effectively resumes the copy
>> of the parent process. This is rarely (if ever) desired.
>>
>> 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:
>>
>> Program => sub {
>> # Wipe the existing POE::Kernel clean.
>> $poe_kernel->stop();
>>
>> # Start a new session, or more.
>> POE::Session->create(
>> ...
>> );
>>
>> # Run the new sessions.
>> POE::Kernel->run();
>> }
>>
>> I had a program that used the above construct which works fine with
>> POE => $VERSION = '1.354';
>> POE::Wheel::Run => $VERSION = '1.354';
>>
>>
>> However with
>> POE => $VERSION = '1.367';
>> POE::Wheel::Run => $VERSION = '1.367';
>>
>> It seems calling POE::Kernel->stop(); it stops the POE::Kernel instance in
>> parent as well.
>>
>> Just wondering if the above change could be causing this behaviour (?)
>>
>> Thanks in advance.
>> Best Regards
>>
>>
>>
>> On Thu, Oct 30, 2014 at 4:00 PM, Rocco Caputo <rcap...@pobox.com
>> <mailto:rcap...@pobox.com>> wrote:
>> Hello, everyone. I hope you've been well.
>>
>> It's come to my attention that POE::Kernel->stop() isn't triggering _stop
>> handlers. This seems wrong, so I've changed it. I hope it doesn't break
>> anything, but I'm mentioning it here in case people want to check in advance
>> of a release.
>>
>> I've already run it past irc.perl.org <http://irc.perl.org/> #poe, and
>> nobody objected.
>>
>> --
>> Rocco Caputo <rcap...@pobox.com <mailto:rcap...@pobox.com>>
>>
>
>
Re: Better ways than call()
Hi, John. There's no requirement to store everything in $_[HEAP]. Data that must be accessible outside a session can be stored somewhere else. For example, if you'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't do the simpler thing you need. 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. 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. -- Rocco Caputo <rcap...@pobox.com> > On Nov 9, 2015, at 08:06, john <j...@tonebridge.com> wrote: > > The POE::Kernel documentation indicates this for call(): > > 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. > > What are some of those ways? I tried a simple subroutine but don't seem to > have access to things like the heap. I guess I could pass those in but than > things don't seem as simple anymore. > > John
Re: POE::Component::Client::Keepalive crashes perl (5.16) on Windows
On Feb 15, 2015, at 06:59, Michael Lackhoff mich...@lackhoff.de wrote: When it comes to the dependency mentioned in the Subject perl crashes several times during dmake test. It is not just a simple test failure but a Windows dialog box appears, saying that perl.exe has crashed. Hello, Michael. 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's the last ten lines (or so) that really matter. While it's possible to turn on crash dumps and examine them in a debugger, I've found this to be generally unhelpful on Windows. The same goes for Windows system call traces. There's a tool for that, but Perl tends to crash in its own code. Please be sure you'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. It feels like the most problematic part of POE::Component::Client::Keepalive's stack would be POE::Component::Resolver. It's all pure Perl, but the resolver uses POE::Wheel::Run to move blocking DNS calls into subprocesses. 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'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. If you get Devel::Trace working, sending me the last output before the popup might help. -- Rocco Caputo rcap...@pobox.com
POE::Kernel-stop() will trigger _stop in the next release
Hello, everyone. I hope you've been well. It's come to my attention that POE::Kernel-stop() isn't triggering _stop handlers. This seems wrong, so I've changed it. I hope it doesn't break anything, but I'm mentioning it here in case people want to check in advance of a release. I've already run it past irc.perl.org #poe, and nobody objected. -- Rocco Caputo rcap...@pobox.com
Re: Slow fork bomb message in latest version of POE
Hi, Alberto. 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's application, but it was hard to debug. Your program seems to have created two processes that it didn't reap: PIDs 5373 and 5374. The ideal solution is to reap those processes before exiting. Your program can do this using POE::Kernel's sig_child() method. 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's code. 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've leaked before POE's check: use POSIX :sys_wait_h; 1 while waitpid(WNOHANG, -1) 0; It's a bit of a pain, but I think it's better to explicitly ignore the problem than for it to go unnoticed by default. 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. -- Rocco Caputo rcap...@pobox.com On Mar 24, 2014, at 05:46, albertocurro albertocu...@zoho.com wrote: Guys, 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 - this is considered ok, since croak() is only called during initialization, when validation is being performed. 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: registering pdu failed: 263! === 5267 === 5 - on_handle (from Handler/StoreRemote.pm at 87) === 5267 === 5 - on_retry (from Handler/StoreRemote.pm at 141) === 5267 === 9 - on_handle (from Handler/StoreRemote.pm at 87) === 5267 === 9 - on_retry (from Handler/StoreRemote.pm at 141) === 5267 === !!! Kernel has child processes. === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-run() is ready to return. === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-run() is ready to return. === 5267 === !!! At least one child process is still running when POE::Kernel-run() is ready to return. === 5267 === !!! Be sure to use sig_child() to reap child processes. === 5267 === !!! In extreme cases, failure to reap child processes has === 5267 === !!! resulted in a slow 'fork bomb' that has halted systems. mkdir /mnt/nfs99: Permission denied at Handler/Store.pm line 147 first lines and last line above are the errors itself, but this part is new since the upgrading: === 5267 === !!! Kernel has child processes. === 5267 === !!! Stopped child process (PID 5373) reaped when POE::Kernel-run() is ready to return. === 5267 === !!! Stopped child process (PID 5374) reaped when POE::Kernel-run() is ready to return. === 5267 === !!! At least one child process is still running when POE::Kernel-run() is ready to return. === 5267 === !!! Be sure to use sig_child() to reap child processes. === 5267 === !!! In extreme cases, failure to reap child processes has === 5267 === !!! resulted in a slow 'fork bomb' that has halted systems. I can see it everytime the service is stopped because of an unhandled condition, even when POE's event loop has been already running for ours. It was not visible before, and I can't get rid of it in any way. I've tried different ways to avoid it with no luck. Any advice or alternative approach on this? Many thanks Alberto
Re: Slow fork bomb message in latest version of POE
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're worried about should not exist.
--
Rocco Caputo rcap...@pobox.com
On Mar 24, 2014, at 11:44, albertocurro albertocu...@zoho.com wrote:
Hi Rocco,
many thanks for your quick answer! Unfortunately, the provided solution only
works partially. I still have some cases where the fork bomb message is
here with us :(
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've not found any way to handle it:
DEBUG - Created nginx temporary directory /opt/tmp/pull/instance1
DEBUG - Created nginx configuration directory /opt/etc/pull/instance1
DEBUG - Created nginx log directory /opt/log/pull/instance1
DEBUG - creating nginx configfile for instance 1 in /opt/etc/pull/instance1
=== 13991 === !!! Kernel has 1 child process(es).
=== 13991 === !!! At least one child process is still running when
POE::Kernel-run() is ready to return.
=== 13991 === !!! Be sure to use sig_child() to reap child processes.
=== 13991 === !!! In extreme cases, failure to reap child processes has
=== 13991 === !!! resulted in a slow 'fork bomb' that has halted systems.
Could not open file: No such file or directory
I've added a DIE handler in the main session to try to handle this:
$sig_session = POE::Session-create(
inline_states = {
_start = sub {
$_[HEAP]{RELOADED} = 0;
$_[KERNEL]-sig(TERM = '_sigterm');
$_[KERNEL]-sig(INT = '_sigterm');
$_[KERNEL]-sig(DIE = '_sigterm');
$_[KERNEL]-sig(nginx_reload = '_sig_nginx_reload');
$_[KERNEL]-alias_set('sighandler');
},
_sigdie = sub {
print Handling exception, calling stop;
POE::Kernel-call($sig_session, '_stop');
},
_stop = sub {
# Reap any existing pid (# 1825119)
print Handling stop;
POE::Kernel-sig_child();
use POSIX :sys_wait_h;
1 while waitpid(WNOHANG, -1) 0;
# Clear signal handlers...
$_[KERNEL]-sig('TERM');
But, as said above, it's not working. Checking POE'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).
But _data_sig_finalize() method is called in Kernel.pm just after
unregistered all the signals (Kernel.pm = _finalize_kernel):
my $self = shift;
# Disable signal watching since there's now no place for them to go.
foreach ($self-_data_sig_get_safe_signals()) {
$self-loop_ignore_signal($_);
}
# Remove the kernel session's signal watcher.
$self-_data_sig_remove($self-ID, IDLE);
# The main loop is done, no matter which event library ran it.
# sig before loop so that it clears the signal_pipe file handler
$self-_data_sig_finalize();
$self-loop_finalize();
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-run(), how could I handle it then??
Thanks a lot
Alberto
Activado lun, 24 mar 2014 13:45:45 +0100 Rocco Caputo escribió
Hi, Alberto.
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's application, but it was hard to debug.
Your program seems to have created two processes that it didn't reap: PIDs
5373 and 5374. The ideal solution is to reap those processes before exiting.
Your program can do this using POE::Kernel's sig_child() method.
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's code.
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've
leaked before POE's check:
use POSIX :sys_wait_h;
1 while waitpid(WNOHANG, -1) 0;
It's a bit of a pain, but I think it's better to explicitly ignore the
problem than for it to go unnoticed by default.
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.
--
Rocco Caputo
On Mar 24, 2014, at 05:46, albertocurro wrote:
Guys,
We have a product developed using POE as a base
Re: Asunto: Re: Slow fork bomb message in latest version of POE
Hi again.
What I mean is that I don't think you know what sig_child() does exactly, or
how to use it. I base this impression on two things: First, you'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're passing it nothing.
I recommend not using SIGDIE for common exception handling. Its scope is too
broad, and your code will get ugly. It'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't need to raise them, and there should be
less strange behavior.
The problem seems to be migrating. I recommend caution against further
clouding the original issue until it's resolved.
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.
--
Rocco Caputo rcap...@pobox.com
On Mar 24, 2014, at 12:15, albertocurro albertocu...@zoho.com wrote:
Hi,
Sorry, but I don't catch what you exactly mean with not using sig_child() as
intended. Do you mean calling it from the main session so each child process
will be closed properly?
The issue I have is how to handle unexpected exceptions. Seems they are
thrown and raised without control, killing POE's kernel before in the way. I
could be thinking in the timing in the wrong way, though...
Alberto
Activado lun, 24 mar 2014 16:59:49 +0100 Rocco Caputorcap...@pobox.com
escribió
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're worried about should not exist.
--
Rocco Caputo rcap...@pobox.com
On Mar 24, 2014, at 11:44, albertocurro albertocu...@zoho.com wrote:
Hi Rocco,
many thanks for your quick answer! Unfortunately, the provided solution
only works partially. I still have some cases where the fork bomb message
is here with us :(
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've not found any way to handle it:
DEBUG - Created nginx temporary directory /opt/tmp/pull/instance1
DEBUG - Created nginx configuration directory /opt/etc/pull/instance1
DEBUG - Created nginx log directory /opt/log/pull/instance1
DEBUG - creating nginx configfile for instance 1 in /opt/etc/pull/instance1
=== 13991 === !!! Kernel has 1 child process(es).
=== 13991 === !!! At least one child process is still running when
POE::Kernel-run() is ready to return.
=== 13991 === !!! Be sure to use sig_child() to reap child processes.
=== 13991 === !!! In extreme cases, failure to reap child processes has
=== 13991 === !!! resulted in a slow 'fork bomb' that has halted systems.
Could not open file: No such file or directory
I've added a DIE handler in the main session to try to handle this:
$sig_session = POE::Session-create(
inline_states = {
_start = sub {
$_[HEAP]{RELOADED} = 0;
$_[KERNEL]-sig(TERM = '_sigterm');
$_[KERNEL]-sig(INT = '_sigterm');
$_[KERNEL]-sig(DIE = '_sigterm');
$_[KERNEL]-sig(nginx_reload = '_sig_nginx_reload');
$_[KERNEL]-alias_set('sighandler');
},
_sigdie = sub {
print Handling exception, calling stop;
POE::Kernel-call($sig_session, '_stop');
},
_stop = sub {
# Reap any existing pid (# 1825119)
print Handling stop;
POE::Kernel-sig_child();
use POSIX :sys_wait_h;
1 while waitpid(WNOHANG, -1) 0;
# Clear signal handlers...
$_[KERNEL]-sig('TERM');
But, as said above, it's not working. Checking POE'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).
But _data_sig_finalize() method is called in Kernel.pm just after
unregistered all the signals (Kernel.pm = _finalize_kernel):
my $self = shift;
# Disable signal watching since there's now no place for them to go.
foreach ($self-_data_sig_get_safe_signals()) {
$self-loop_ignore_signal($_);
}
# Remove the kernel session's signal watcher.
$self-_data_sig_remove($self-ID, IDLE);
# The main loop is done, no matter which event library ran it.
# sig before loop so that it clears the signal_pipe
Re: POCO IRC Proxy plugin
The docs say it's a simple bouncer that lets you hide many bots and/or clients behind a single IRC connection. Benefits? If you're developing bots that crash a lot, you can hide them behind a stable proxy that doesn't annoy everyone with frequent reconnections. 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. If a channel lets you only have one bot, you can cheat. :) Other things, only limited by the intersection of the implemented features and your imagination! -- Rocco Caputo rcap...@pobox.com On Feb 22, 2014, at 15:49, Celso Barriga cbarr...@gmail.com wrote: Can somebody please tell me what this plugin actually do? I'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's the advantage of doing this and what does this give me? Thanks in advance. Best regards, Celso
Re: Saving application state
Hi, Celso. This isn't a job for POE. Use File::AtomicWrite, or something like it, to safely write the time stamp as frequently as necessary. It's a trivial amount of data, so you probably don't need it written asynchronously. Reload the time stamp when the program restarts. -- Rocco Caputo rcap...@pobox.com On Feb 13, 2014, at 13:21, Celso Barriga cbarr...@gmail.com wrote: Hello, it's me again :) I have a POE-based application that queries a web app for some data filtered on some time range, say, send me any changes from time x to now. 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. 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'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. What is the best way of doing this, the POE way. Can I just save it to a file and read it back every tick count, which is 1 sec, using a regular file handle? Thanks in advance! Celso
Re: [SOLVEDish] Problem with MPD client but probably POE user error
On Feb 5, 2014, at 16:27, John j...@tonebridge.com wrote: I added some print statements in POE's Aliases.pm in the sub _data_alias_resolve to see what aliases POE thought existed at any point in time. It turns out that at the time _start is executed the mpd alias was not registered yet! I figure it is timing and not location. Anyway, for debugging purposes I added a delayed event and that worked! I will work with it to get a better understanding if it is timing or just having it in _start but it seems I should be good not rushing things. I didn't notice this problem because I expected POE::Component::MPD to set its own alias in its own _start routine. _start is called before POE::Session-create() returns. The predictable timing can be used to avoid problems like this. -- Rocco Caputo rcap...@pobox.com
Re: Problem with MPD client but probably POE user error
Hi, John. I don't see anything obviously wrong in the code you provided. I don't have MPD, and I'm not familiar with the module you're using, but I can offer some general POE advice. POE has some debugging switches, documented in POE::Kernel. I recommend at least enabling: ASSERT_EVENTS, ASSERT_USAGE, and ASSERT_RETVALS. You can do this in your shell: export POE_ASSERT_EVENTS=1 export POE_ASSERT_USAGE=1 export POE_ASSERT_RETVALS=1 Or to turn them all on (and a bit more) in one fell swoop: export POE_ASSERT_DEFAULT=1 Then run your program. Hopefully POE will warn you about something relevant. -- Rocco Caputo rcap...@pobox.com On Feb 4, 2014, at 07:56, John j...@tonebridge.com wrote: none of the events I send get to the daemon (also running on localhost with default port). maybe this is not a problem with MPD.pm but my usage of POE. I can use the command line client that comes with MPD to interact with the daemon and that works as expected as well as it generates logging information.
Subtle change to SIGCHLD polling
If you're using POE for process management, then I may have made a change that affects you. It's especially relevant to people using _signal to handle SIGCHLD, people using SIGCHLD polling (legacy Perl users who don't trust safe signals), and people using a MSWin32 Perl like ActiveState or Strawberry. Please review the change in the repository and give it a spin before it ends up on CPAN. The build you save may be your own. https://github.com/rcaputo/poe/commit/d3cb2fbfb53799ab22754b900fc47af703758910 commit d3cb2fbfb53799ab22754b900fc47af703758910 Author: Rocco Caputo rcap...@cpan.org Date: Sun Oct 6 16:58:28 2013 -0400 Fix a Kernel has child processes warning even when it doesn't. Michel Schrameck reported that the above warning was coming from a very simple, obviously not fork()ing test program. I was able to reproduce the problem with the test case when USE_SIGCHLD was turned off. This fix changes the way first polling of SIGCHLD happens. It passes all known tests, but it may negatively affect older programs. Please report any problems. -- Rocco Caputo rcap...@pobox.com
Re: POE server and perl client on diferent OS
On Sep 19, 2013, at 20:29, Zhu, Julie wrote: May I use POE server on linux machine and using perl 5.6 write client using= socket module on windows client? Can they communicate? Yes. -- Rocco Caputo rcap...@pobox.com
Attn: Backwards-incompatible change to CATCH_EXCEPTIONS
I've changed the way CATCH_EXCEPTIONS works with $SIG{__DIE__}.
I broke (and then fixed) one regression test in the process.
If this is a feature you use, please try out the change before
it's released.
Thanks!
https://github.com/rcaputo/poe/commit/52487325a316b2bcc945f0a1f344556b58760ef3
commit 52487325a316b2bcc945f0a1f344556b58760ef3
Author: Rocco Caputo rcap...@cpan.org
Date: Thu Sep 5 18:52:13 2013 -0400
!!! CATCH_EXCEPTIONS revamp.
May be slightly backwards incompatible. I expect more good to come
from it than harm.
POE should hide error messages less often. Its usage of eval() and
propagation of exceptions have been simplified somewhat.
!!! This change reverses POE's stance on user-defined $SIG{__DIE__}
handlers. Now they are honored inside event handlers. Code that does
this is expected to know what it's doing. Perl's global special
variables, including %SIG, have spooky action at a distance.
Modifying $SIG{__DIE__} locally shouldn't cause any problems. The
original value will be restored at the end of the local scope.
I changed this because reasons:
1. Silent side effects suck. Previously, POE would silently overrule
global changes to $SIG{__DIE__}. This change makes things a little
more comprehensible.
2. $SIG{__DIE__} handlers are very useful for logging and debugging.
Setting them should be permissible.
3. If CATCH_EXCEPTIONS is on, and $SIG{__DIE__} is redefined in an
event handler, the programmer is told about the potential side
effects. This is an experimental warning and is subject to change
more than most things.
4. Error messages were being hidden at work, and it was confounding
development.
--
Rocco Caputo rcap...@pobox.com
Re: Localizing %SIG in Safe.pm 2.{35,36,37} crashes POE::Wheel::Run ...
Thank you for the alert. Is there any reasonable way to work around this?
--
Rocco Caputo rcap...@pobox.com
On Jul 16, 2013, at 12:00, Markus Jansen wrote:
Hi,
FYI ... hope none of you wastes time with this really nasty trap ...
Best regards,
Markus
-Original Message-
From: Markus Jansen
Sent: Tuesday, July 16, 2013 5:57 PM
To: perl...@perl.org
Cc: Markus Jansen
Subject: Localizing %SIG in Safe.pm 2.{35,36,37} crashes POE::Wheel::Run ...
This is a bug report for perl from markus.jan...@ericsson.com, generated with
the help of perlbug 1.39 running under perl 5.18.0.
-
[Please describe your issue here]
Dear Perl5 Porters,
localizing %SIG in Safe.pm 2.35 (on CPAN, 2.{35,36,37} in Perl core) may be a
great step for security, but it unfortunatately spoils POE::Wheel::Run
(basically POE and all other asynchronous frameworks dealing with external
processes).
The symptom experienced is that your application might sooner or later crash
(reliably when using POE::Component::Resolver upon exiting a Sidecar
subprocess) with the following famous last words:
Signal SIGCHLD received, but no signal handler set.
Please consider a version (also on CPAN) of Safe.pm which has e.g. the
localization of %SIG as a switchable feature.
Best regards,
Markus
[Please do not change anything below this line]
-
---
Flags:
category=library
severity=critical
module=Safe
---
Site configuration information for perl 5.18.0:
Configured by ericsson at Fri Jul 12 19:17:48 CEST 2013.
Summary of my perl5 (revision 5 version 18 subversion 0) configuration:
Platform:
osname=linux, osvers=2.6.16.60-0.42.10-smp,
archname=x86_64-linux-thread-multi
uname='linux sekix562 2.6.16.60-0.42.10-smp #1 smp tue apr 27 05:11:27 utc
2010 x86_64 x86_64 x86_64 gnulinux '
config_args='-d -e -O -D cc=gcc -D
prefix=/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/prod
-D usemultiplicity -U use5005threads -D usedl -D useshrplib -D
libperl=libcmacperl.so -U usemymalloc -D cf_by=ericsson -D
cf_email=scm...@clearcase.ericsson.se -D
perladmin=scm...@clearcase.ericsson.se -D uselargefiles -D usethreads -D
useithreads -D use64bitall -D ldcc=CC -D optimize=-O3 -D
locincpth=/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/include
/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/apache/include
-D
loclibpth=/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/lib
/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/apache/lib
-D lddlflags=-shared -lpthread
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/prod/lib/5.18.0/x86_64-linux-thread-multi/CORE
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/prod/lib/5.18.0
/x86_64-linux-thread-multi/CORE
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/lib
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/lib
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/apache/lib
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/apache/lib
-Wl,--enable-new-dtags -D ldflags=-lpthread
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/prod/lib/5.18.0/x86_64-linux-thread-multi/CORE
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/prod/lib/5.18.0/x86_64-linux-thread-multi/CORE
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/lib
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/lib
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/apache/lib
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/
plib/apache/lib -Wl,--enable-new-dtags -D ccdlflags=-Bdynamic
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/prod/lib/5.18.0/x86_64-linux-thread-multi/CORE
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/prod/lib/5.18.0/x86_64-linux-thread-multi/CORE
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/lib
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/lib
-Wl,-L/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/apache/lib
-Wl,-rpath,/vobs/cc/CCA-perl01/perl5_Linux_x64__sixtyfive_char_path/plib/apache/lib
-D ldlibpthname=LD_LIBRARY_PATH -D cccdlflags=-fPIC -D dlsrc=dl_dlopen.xs -D
ccflags=-O2 -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -pthread
-DPERL_IMPLICIT_CONTEXT -DPERL_USE_SAFE_PUTENV -m64 -pipe -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fPIC -D so=so
Re: Combining services.
Don't use an asynchronous client if you don't need one. The cookbook includes
examples using POE::Filter::Reference by itself.
--
Rocco Caputo rcap...@pobox.com
On Jan 31, 2013, at 09:41, Antti Linno wrote:
Hm, as my needs for application server are very simple, I feel that POE TCP
client is too heavy, compared to IO::Socket for example.
Slim client=
use IO::Socket;
use JSON qw( encode_json );
my $sock = new IO::Socket::INET (
PeerAddr = 'localhost',
PeerPort = '11211',
Proto = 'tcp'
);
print $sock ( encode_json( { event = position, phone = 12345 } ) .
'[EOM]' );
close $sock;
exit;
In server I parse messages with=
POE::Component::Server::TCP-new(
Alias= emt_server,
Address = localhost,
Port = 11211,
ClientFilter = [ POE::Filter::Line, Literal = [EOM] ],
ClientConnected = sub {
say Client connected;
},
# Handle client requests here.
ClientInput = sub {
my ( $heap, $params_json ) = @_[ HEAP, ARG0 ];
print $params_json;
Wrapper::emt_event( decode_json $params_json );
},
This works. But I somehow feel that this is not elegant solution. How do I
use POE::Filter::Reference instead of Line? Tried to freeze and send, but
the server did not enter ClientInput event. Is there a slim and elegant
solution? :) Or should I use cookbook client and just kill client after
every request with $kernel-yield(shutdown)? Cookbook client works fine.
If I use ClientFilter = [ POE::Filter::Reference, YAML ], I cannot
trigger ClientConnected subroutine with IO::Socket :) Tried to use
standalone Filter::Reference-put and send it over socket, but still no
luck.
Thank you all.
On Wed, Jan 30, 2013 at 7:29 PM, Antti Linno antti.li...@gmail.com wrote:
Thank you. You saved me from fourth standalone daemon :D
On Wed, Jan 30, 2013 at 5:09 PM, Rocco Caputo rcap...@pobox.com wrote:
On Jan 30, 2013, at 09:49, Antti Linno wrote:
Or I need advice, how to merge several sungo's(
http://poe.perl.org/?POE_Cookbook/TCP_Servers) daemons into one
package, if
someone would be so kind. Adding UDP should be fairly similar then.
Any hints, second opinion(maybe not to merge TCP and UDP), or code
examples
are welcome :)
I've attached a working version of your sample code. It starts two TCP
servers and a UDP service, and lets them all run at once in the same
process.
--
Rocco Caputo rcap...@pobox.com
Re: Combining services.
On Jan 30, 2013, at 09:49, Antti Linno wrote:
Or I need advice, how to merge several sungo's(
http://poe.perl.org/?POE_Cookbook/TCP_Servers) daemons into one package, if
someone would be so kind. Adding UDP should be fairly similar then.
Any hints, second opinion(maybe not to merge TCP and UDP), or code examples
are welcome :)
I've attached a working version of your sample code. It starts two TCP servers
and a UDP service, and lets them all run at once in the same process.
--
Rocco Caputo rcap...@pobox.com
#!/usr/bin/env perl
use warnings;
use strict;
use Socket qw(unpack_sockaddr_in inet_ntoa);
use POE qw(Component::Server::TCP);
sub setup_tcp_server {
my ($port, $alias) = @_;
POE::Component::Server::TCP-new(
Alias = $alias,
Port= $port,
ClientInput = sub {
my ($session, $heap, $input) = @_[SESSION, HEAP, ARG0];
print Server [$alias] Session , $session-ID(), got input: $input\n;
$heap-{client}-put($input);
}
);
}
sub setup_udp_service {
my ($port, $alias) = @_;
POE::Session-create(
inline_states = {
_start = sub {
my $socket = IO::Socket::INET-new(
Proto = 'udp',
LocalPort = $port,
);
die Couldn't create server socket: $! unless $socket;
$_[KERNEL]-select_read($socket, get_datagram);
$_[KERNEL]-alias_set($alias);
},
get_datagram = sub {
my ($kernel, $socket) = @_[KERNEL, ARG0];
my $remote_address = recv($socket, my $message = , 65536, 0);
return unless defined $remote_address;
my ($peer_port, $peer_addr) = unpack_sockaddr_in($remote_address);
my $human_addr = inet_ntoa($peer_addr);
print (server) $human_addr : $peer_port sent us $message\n;
$message =~ tr[a-zA-Z][n-za-mN-ZA-M];
send($socket, $message, 0, $remote_address) == length($message)
or warn Trouble sending response: $!;
},
}
);
}
setup_tcp_server(11211, tcp_server_one);
setup_tcp_server(11212, tcp_server_two);
setup_udp_service(8675, udp_service_three);
# The imporant part is not to start things until they are set up.
# run() will run the event loop until all work is done. In this case,
# until all previously setup services shut down---forever in the
# example.
POE::Kernel-run();
exit;
Re: POE, log4perl and sqlite
Every module seems to be re-initializing your logger. I don't know if it's harmful in your situation, but it's not recommended. Wherever you call Log::Log4perl::init($log_conf) try Log::Log4perl-init_once($log_conf) instead. See: http://search.cpan.org/~mschilli/Log-Log4perl-1.38/lib/Log/Log4perl.pm#Initialize_once_and_only_once Offhand I don't see anything else that would lock your log database. Maybe another program is locking it in SELECT? If that's true, the queries are taking too long for the bot to wait. Maybe you could optimize the table indexes so the queries complete in time. -- Rocco Caputo rcap...@pobox.com On Oct 19, 2012, at 07:04, Antti Linno wrote: Thank you for your kind interest. The pastebins: log4perl.conf http://pastebin.com/nY4twgjS main file http://pastebin.com/ruYsu2qt application logic http://pastebin.com/hMyyBJ0U database interaction http://pastebin.com/Cq7d4geK As you can see, all the perl files are logging, main and application import database functions. I have snipped the application and database somewhat, but you could see the main structure and how I am doing the logging. Greetings. On Thu, Oct 18, 2012 at 4:19 PM, Rocco Caputo rcap...@pobox.com wrote: On Oct 18, 2012, at 07:58, Antti Linno wrote: First of all, I have to apologise. Still no pastebin. We have to apologize, too. You're asking questions about code we cannot see. This impairs our ability to provide satisfying answers. But a general tree would be something like that. Main POE module, imported submodule1, imported submodule2. All 3 modules open the same logger conf and use the same sqlite file to append the log. Theoretically the log file could be locked, if all 3 or even 2 modules try to write at the same time. No. As others have said, POE doesn't pre-empt. Under ordinary circumstances, we expect all three modules to call Log::Log4perl sequentially rather than concurrently. We don't expect Log::Log4perl suffer from lock contention. It's very likely that something extraordinary is happening as a result of code we cannot see. Others have already outlined the most likely reasons for the symptoms you described. I hope you understand that's the best we can do without your cooperation. What would be the nice and tidy thing to do? Initialize logger in main POE module and pass it to submodules? That's such a good question that Log::Log4perl already answers it: Why Log::Log4perl-get_logger and not Log::Log4perl-new? We don't want to create a new object every time. Usually in OO-Programming, you create an object once and use the reference to it to call its methods. However, this requires that you pass around the object to all functions and the last thing we want is pollute each and every function/method we're using with a handle to the Logger: [example omitted] Instead, if a function/method wants a reference to the logger, it just calls the Logger's static get_logger($category) method to obtain a reference to the one and only possible logger object of a certain category. That's called a singleton if you're a Gamma fan. That quote is from http://search.cpan.org/~mschilli/Log-Log4perl-1.38/lib/Log/Log4perl.pm#Initialize_via_a_configuration_file -- Rocco Caputo rcap...@pobox.com
Re: POE, log4perl and sqlite
On Oct 18, 2012, at 07:58, Antti Linno wrote: First of all, I have to apologise. Still no pastebin. We have to apologize, too. You're asking questions about code we cannot see. This impairs our ability to provide satisfying answers. But a general tree would be something like that. Main POE module, imported submodule1, imported submodule2. All 3 modules open the same logger conf and use the same sqlite file to append the log. Theoretically the log file could be locked, if all 3 or even 2 modules try to write at the same time. No. As others have said, POE doesn't pre-empt. Under ordinary circumstances, we expect all three modules to call Log::Log4perl sequentially rather than concurrently. We don't expect Log::Log4perl suffer from lock contention. It's very likely that something extraordinary is happening as a result of code we cannot see. Others have already outlined the most likely reasons for the symptoms you described. I hope you understand that's the best we can do without your cooperation. What would be the nice and tidy thing to do? Initialize logger in main POE module and pass it to submodules? That's such a good question that Log::Log4perl already answers it: Why Log::Log4perl-get_logger and not Log::Log4perl-new? We don't want to create a new object every time. Usually in OO-Programming, you create an object once and use the reference to it to call its methods. However, this requires that you pass around the object to all functions and the last thing we want is pollute each and every function/method we're using with a handle to the Logger: [example omitted] Instead, if a function/method wants a reference to the logger, it just calls the Logger's static get_logger($category) method to obtain a reference to the one and only possible logger object of a certain category. That's called a singleton if you're a Gamma fan. That quote is from http://search.cpan.org/~mschilli/Log-Log4perl-1.38/lib/Log/Log4perl.pm#Initialize_via_a_configuration_file -- Rocco Caputo rcap...@pobox.com
Re: SocketFactory Server communication between sessions
On Oct 12, 2012, at 09:16, Ty Roden wrote: The server code, once modified seems to be doing most of what I need, as clients can connect, and I can properly respond to events coming down the line from clients. In place of the 'echo back anything the client sends you' I am examining the data, and responding to it with what I need and all seems to be well. The problem is that I have one client that connects that sends me data that I need to make sure reaches the other clients so that they can process the data arriving. I can accept and process the data from this master client, but I cannot find how I might send the data to each running process to in turn have their sessions react to the data arriving. Since it is a client session just like any other that is receiving the data, even saving down the session IDs into a hash I am having an issue sending data across to the other sessions. Perhaps this just means that I am going about this wrong. http://poe.perl.org/?POE_Cookbook/Chat_Server seems to do what you want. Whenever one client sends data, it's broadcast to all others. It uses a shared hash to register clients and a global helper function to iterate the hash and broadcast messages. Of course your version of broadcast() can do more complex calculations and determine which other clients will receive the results. Your shared hash can also contain a lot more information for each client. And since it's shared, any client can inspect it at will... without pesky message passing among clients. If a shared hash and accessor functions doesn't feel right, consider abstracting it into a singleton class or object, and give every client the package name or instance to the object. I think this covers all your other questions. Please let us know if it doesn't. Thanks! -- Rocco Caputo rcap...@pobox.com
Re: patch for SIG{__DIE__} behaviour
I redirected it to POE's request queue at bug-...@rt.cpan.org. It's tracked at
https://rt.cpan.org/Public/Bug/Display.html?id=79886 now.
--
Rocco Caputo rcap...@pobox.com
On Sep 26, 2012, at 10:46, Philip Gwyn wrote:
Hello,
This is a patch that fixes $SIG{__DIE__} handling for perl 5.8.8. While
__DIE__ starts out as undef, if you assign undef to __DIE__ in 5.8.8, it
becomes an empty string ().
This patch includes a regression test.
-Philip
Philip_Gwyn-POE-SIG-DIE01.patch
Re: alarm function under while loop
Hi, Gokul.
POE::Kernel-alarm() enqueues an alarm, but it is not like the built-in
alarm(). POE's alarms are dispatched by POE::Kernel in between callbacks.
Your while() loop pre-empts the dispatcher, so the enqueued alarms never occur.
If your program must delay there, you can use POE::Kernel-run_while() to run
POE's dispatcher while a variable is true. Set the variable false from the
callback you are waiting for.
--
Rocco Caputo rcap...@pobox.com
On Aug 22, 2012, at 05:54, Gokul Prasad wrote:
Hi,
Am setting alarm in calling a function to check if particular task
has executed properly or what.
when i place the below code under while loop this alarm function is
not being called, but when i comment while loop, it is just works fine
correctly.
while(end_time = current_time){
$heap-{next_alarm_time} = int(time())+30;
print STDERR $heap-{next_alarm_time} why ti is printing\n;
$kernel-alarm(next_task =
$heap-{next_alarm_time});#$heap-{RESULT}-{event});
}
Not sure why it is happening? any suggestion.please
Regards,
gokul
Re: POE process getting too busy
Since this problem is platform-specific, the best I can manage without access
to the machine is advice.
Web searches imply that Solaris may be broken, the program may have run out of
file descriptors, an OS upgrade may have broken compatibility with an older
build of Perl, or some other issue:
https://community.emc.com/thread/111914
http://dbaspot.com/solaris/242660-high-cpu-utilization-solaris-10-a.html
http://www.mail-archive.com/dovecot@dovecot.org/msg04283.html
http://developerweb.net/viewtopic.php?id=5481
http://www.symantec.com/business/support/index?page=contentpmv=printimpressions=viewlocale=id=TECH163245
http://wesunsolve.net/bugid/id/6404383
--
Rocco Caputo rcap...@pobox.com
On Aug 21, 2012, at 06:09, Markus Jansen wrote:
Hi,
thanks a lot for the immediate answer, I also changed the code immediately,
and started another long-term test run.
Just found the process 99% busy again - the good news is that the signal pipe
does not seem to be the culprit :-).
Any other suggestions are highly welcome ...
Thanks best regards,
Markus
-Original Message-
From: Tod McQuillin [mailto:de...@spamcop.net]
Sent: den 16 augusti 2012 02:46
To: Markus Jansen
Cc: poe@perl.org
Subject: Re: POE process getting too busy
On Wed, 15 Aug 2012, Markus Jansen wrote:
I have discovered an annoying phenomenon, where after some while
(days, weeks) a process (which is part of a multi-server POE network) all of
a sudden goes berzerk by using all resources of its CPU.
The good news is that the process itself remains fully functional, but from
a system usage/load perspective, the situation is quite intolerable.
This sounds very familiar to me.
I encountered a similar problem on solaris and was able to make it stop by
putting the following line of code at the beginning of my POE program:
BEGIN { eval sub POE::Kernel::USE_SIGNAL_PIPE () { 0 } }
There seems to be a problem with the signal pipe on some platforms, but I
haven't yet done more research to track down what's going wrong.
--
Tod
Re: Contemplating POE for a multi-platform project rewrite
On Aug 14, 2012, at 04:41, Derek Mead wrote: So now for the questions: - Is POE a sensible choice for me to re-implement this server, particularly if it will have to run reliably under Windows? The main interactions with the OS will be handling TCP sockets: I don't anticipate having to have to do any explicit threading, process-forking or signal handling, which should reduce the risks associated with possible flakiness under Windows. Yes. My workplace uses POE on Windows. Win32::Process and sockets have been a more reliable alternative to dynamic iThreads. It may also help work around handle-count limitations we've seen in select(), if you're using TCP sockets. UDP is another alternative. Without connections, a server can multiplex an arbitrary number of clients on a single socket handle. You'd need to build reliability into the application-level protocol, which complicates things in other ways. - What forum would you recommend me to use when I have to seek help or advice on the POE-specific aspects of the code? This mailing list is good for long-form questions and answers. It's also a good way to work around time zone differences. irc.perl.org #poe is good for shorter, less formal, more real-time interaction. -- Rocco Caputo rcap...@pobox.com
Re: wheel_run.pm test errors (Was: POE Upgrade error)
On Jul 13, 2012, at 11:26, Philip Gwyn wrote: On 10-Jul-2012 Rocco Caputo wrote: Good morning. I could use some help with this problem. After a look at wheel_run.pm, seems to me this is a buffering issue. The child does print; ; print; print; but the parent does print; sysread(); Included is a double patch: In the first patch, the parent will accumulate the input until it find a terminator. The second patch is a clean up of the first (the terminator is a param) but I don't know how to get git to show them combined. Thanks! I've applied this, and I'll release the changes after sweeping through POE's bug queues. -- Rocco Caputo rcap...@pobox.com
Re: Do events due to yield have higher precedence than those due to delay for kernel dispatch?
Hi, Deven.
It appears that you expect event handlers to run concurrently, which they
don't. Event handlers are run sequentially, in order of dispatch due time. In
other words, each is allowed to finish before the next is dispatched.
post() and yield() events are dispatched as soon as possible. To keep things
fair, they are given the dispatch time of Time::HiRes::time(), which enqueues
them ahead of future timers, or behind timers that are overdue.
For example, you may have a queue of events scheduled for absolute times 10,
20, and 30 seconds from some epoch boundary. We'll call the events e_10, e_20,
and e_30, respectively.
At dispatch time, all events due prior or equal to Now are dispatched. If
none are due, the event loop POE is using will be asked to wait until the next
one is due.
For example, POE's default event loop uses select(). If the current time is 5,
the select() call will time out in 10-5 seconds, give or take processing time.
If there is no I/O for 5 seconds, select() returns, and e_10 is dispatched on
schedule.
Event handlers take some measurable time to execute. The faster, the better,
but many use cases can handle substantial processing delays.
Let's assume the handler for e_10 takes 15 seconds to run. The next event
(e_20) won't be dispatched until about 25 seconds past the start of the epoch.
That's 5 seconds later than it was scheduled.
In your test case, the 1/4-second processing time for each event handler means
that only 3-5 of them can be dispatched every second. You will need to make
the time-consuming tasks asynchronous or distribute the work across more cores.
--
Rocco Caputo rcap...@pobox.com
On Jul 12, 2012, at 01:13, Deven Parekh wrote:
Hello POE team,
I am trying to understand if the POE kernel dispatching algorithm has any
precedence when it comes to events from yield Vs events from delay. Please
read through the email to see if you can help me figure out what is the
mistake i am doing here.
Following is the code snipett that demonstrates my issue.
code
#!/usr/bin/perl
use strict;
use warnings;
use Algorithm::TokenBucket;
use Time::HiRes;
use POE;
use POE::Component::Schedule ;
my $so_many_task = 10;
my $so_many_seconds = 1;
my $burst_size = 1;
my $stop = 0;
my $bucket = new Algorithm::TokenBucket $so_many_task / $so_many_seconds,
$burst_size;
my $time = Time::HiRes::time;
my $master_session = POE::Session-create(
inline_states = {
_start = \master_start,
put_one_on_queue = \put_one_on_queue,
generate_tick= \generate_tick,
next_task= \next_task,
stop_scheduling = \stop_scheduling,
_stop= sub { },
dummy= sub { },
}
);
POE::Kernel-run();
exit(0);
sub master_start {
my $kernel = $_[KERNEL];
$_[KERNEL]-alias_set(Enqueuer);
$_[KERNEL]-yield(generate_tick);
$_[KERNEL]-delay( stop_scheduling = 1 );
}
sub generate_tick {
my $kernel = $_[KERNEL];
if ( $stop == 0 ) {
my $after_sec = $bucket-until($burst_size);
print Next one after $after_sec\n;
$_[KERNEL]-delay_add( put_one_on_queue = $after_sec );
}
}
sub stop_scheduling {
print Stopped \n;
}
sub put_one_on_queue {
my $kernel = $_[KERNEL];
if ( $bucket-conform($burst_size) ) {
print Time::HiRes::time -$time, - Processed $burst_size more \n;
$bucket-count($burst_size);
$_[KERNEL]-yield(generate_tick);
$_[KERNEL]-yield(next_task);
}
}
sub next_task {
#--- some operation that is taking about 0.2 sec
#--- using select to show it here.
#print Started next task\n;
select( undef, undef, undef, 0.25 );
#print Done with next task\n;
}
/code
p
With the above code and the select statement, which i amusing to simulate
some operation taking about .25 seconds, the output is as follows
[lss@ctsauto1 misc]$ ./atbkt_2.pl
Next one after 0.0995830059051514
0.100232124328613 - Processed 1 more
Next one after 0.0998860359191895
0.350847959518433 - Processed 1 more
Next one after 0.0998910427093506
0.60145115852356 - Processed 1 more
Next one after 0.0998910427093506
0.852055072784424 - Processed 1 more
Next one after 0.0998538494110107
1.10269498825073 - Processed 1 more
Stopped
*Well i was expecting 10 items to be processed in 1 second not just 5.*
Now if i comment the select statement in the next_task routine then I get
following output.
Next one after 0.0997329711914063
0.100254058837891 - Processed 1 more
Next one after 0.0999299049377441
0.200562953948975 - Processed 1 more
Next one after 0.0999120235443115
0.300816059112549 - Processed 1 more
Next one after 0.0999170303344727
0.401067018508911 - Processed 1 more
Next one after 0.0999160766601563
0.501316070556641 - Processed 1 more
Next one after 0.0999160766601563
0.601574897766113 - Processed 1 more
Next one
Deprecation notice: POE::Pipe utilities becoming IO::Pipely
I've decoupled POE::Pipe classes from POE, and I'll release them as IO::Pipely soon. I've created a new project repository for IO::Pipely here: https://github.com/rcaputo/io-pipely This begins a long-term deprecation of the POE::Pipe classes. The plan so far: 0. Tell everyone about the upcoming POE::Pipe deprecation. You're reading it now. 1. Solicit feedback on IO::Pipely before the release. Please take a look and suggest refinements? Check. 2. Release IO::Pipely. 3. Tell everyone they should migrate their POE::Pipe use to IO::Pipely ASAP. 4. Time passes. 5. Document POE::Pipe deprecation. 6. Make IO::Pipely a POE dependency. 7. Replace POE::Pipe guts with IO::Pipely calls. 8. Time passes. 9. Replace POE::Pipe usage in POE's core and tests with direct IO::Pipely usage. A. Remind people POE::Pipe is deprecated. B. Time passes. C. Remove POE::Pipe from POE's repository and distribution. D. Profit? Generally time passes is one or two POE releases. This can represent several months of real time depending on the frequency of bug reports (very low right now). Sorry in advance for breaking things. Hopefully it's far enough in the future so everyone can avoid problems. -- Rocco Caputo rcap...@pobox.com
Re: Q: add and remove wheels dynamically
Can you reduce the program to something I can run locally to see what's going
on? The parts you've quoted aren't enough context for me to answer your
question.
What you want to do should work fine. So the best answer I have (with the
information you've given) is you're doing... something... wrong.
--
Rocco Caputo rcap...@pobox.com
On Jun 12, 2012, at 16:10, Alex wrote:
Hi!
I have written a small Tk GUI that follows some log files. I would like to
add the possibility to add and remove files on-the-fly.
To do this, I added a menu where a user is provided with two menu items for
this:
[snip]
my $logfiles = [ ... ]; # my personal list of files
my $log_file_types = [
['Log Files', ['.log', '.txt']],
['All Files','*', ],
];
my $menuitems = [
[Cascade = ~Datei, -menuitems =
[
[Button = ~Add file, -command = sub{
my $file = $poe_main_window-getOpenFile(-filetypes =
$log_file_types);
if( $file ) {
# A file has been selected to be followed
push @{$logfiles}, $file;
add_file_to_watchlist( $heap, $file );
}
return 1;
}],
[Button = ~Remove file, -command = sub{
my $ident = magic_way_to_get_this();
delete $heap-{wheel}-{$ident};
}
return 1;
}],
[Separator = ],
[Button = ~Exit program, -command = sub{ exit(0); return
1; }],
],
],
];
my $menu = $poe_main_window-Menu(-menuitems = $menuitems);
$poe_main_window-configure(-menu = $menu);
sub add_file_to_watchlist {
my ($heap, $logfile) = @_;
# this ethod is called during the initial set-up, too.
# some stuff here...
# -- create new wheel
$heap-{wheel}-{$logdatei} = POE::Wheel::FollowTail-new(
Filename = $ logfile,
InputEvent = 'got_line',
ErrorEvent = 'got_error',
SeekBack = 1024,
);
return;
} # /add_file_to_watchlist
[/snip]
However, when I remove a file and add it again, it's not followed. If I add
another file, it's not followed either.
How do I do this? Is it possible?
The code (the uncut version) works fine when the program starts up. Only
adding files after the event loop has started doesn't work. Why?
What is the proper way of saying: hey Perl, stop following that file and
hey Perl, start following this file while the POE event loop is running?
Best regards,
Alex
POE 1.350 released
Already on PAUSE. It might even be on your favorite CPAN mirror by now. You can read the CHANGES at https://metacpan.org/module/POE As cautioned, it includes internals changes surrounding SIGCHLD handling. Session lifespans have also been subtly redefined where SIGCHLD is concerned. These changes may be user-facing to people who aren't using sig_child(). I've advanced the revision more than normal for that reason. -- Rocco Caputo rcap...@pobox.com
Re: I want to build a tunnel system in POE
POE doesn't do anything special regarding sockets. Well, okay, it binmode()s them and makes them non-blocking. Otherwise, they're just plain sockets. So any SOCK_RAW chicanery you might need to spoof source addresses will be standard. -- Rocco Caputo rcap...@pobox.com On Dec 12, 2011, at 17:09, Cary Lewis wrote: This tunnel will act as a front end to a SMTP server, where I can monitor connections, etc. This is fairly easy to do in POE, but I have to spoof the connection that the POE server will make to the actual SMTP server so that the whitelist and blacklist functions work correctly. I.e. if I just connect to the smtp server from my POE server (when the actual smtp client connects) then the IP address will always be localhost or one of the physical IP addresses. Is there a way I can make the connection to the actual SMTP server (which would be on the same physical box as where the POE solution will be running) look like it's coming from the actual smtp client's IP address? Thanks for any help.
Warning: Is anyone still using $kernel-sig(CHLD = $event)?
If you're using sig(CHLD = $event) to catch SIGCHLD, you should totally be using sig_child(PID = $event) instead. sig(CHLD = $event) has problems that are going to be exacerbated by the next POE release. Currently POE::Kernel-run() won't return until all child processes have exited. I added that after a developer reported their production machines were crashing because of POE. It turned out they had a slow process leak that didn't cause problems in testing but would kill machines after long production runs. Ideally the warning aims developers' guns away from their feet, but in practice there are more people gunning for developers' feet than just themselves. I discovered this when Log::Log4perl::Appender::File shot me in the foot recently. Or maybe I shot my own foot through a level of indirection. I'm using its pipe mode to send logs through Apache's rotatelogs(8) utility. The rotatelogs subprocess was deadlocking POE at exit. This is POE's fault for being too cautious. I've modified POE::Resource::Signals' finalization code to warn about running processes but not wait forever for them. This broke a few tests that relied on POE::Kernel reaping processes for them. I'm pretty sure other people will run into this new warning when they upgrade. $kernel-sig(CHLD = $event) is a big part of the problem. It can't tell the difference between processes you want to reap, and ones encapsulated by a library that may never shut them down. Which is why I added sig_child() five years ago. commit e8a11d981f111afe92e56d6ade8ba08a3d5a077b Author: Rocco Caputo rcap...@cpan.org Date: Sat Sep 16 05:33:53 2006 -0400 Added sig_chlid(), test case, and documentation. Resolves rt.cpan.org 18392. Collateral damage: POE::Loop::Event's signal handler callbacks have been replaced by POE::Loop::PerlSignals. sig_child() can tell the difference. It can keep a program running until all interesting processes are reaped, and it can release the program when they're all done. You should totally be using that already. If you aren't, consider this your warning to begin. -- Rocco Caputo ro...@plixer.com -- Rocco Caputo rcap...@pobox.com
Re: Generating constant RPS load for Data cloud
I see two problems.
max_open = 1000, but it appears you've left max_per_host to the default of 4.
You're enqueuing 800 requests all at once. POE's message dispatch queue is
FIFO, so all the requests must occur before the first response arrives. With a
low max_per_host, it's quite likely that many of the requests are timing out.
Increase max_per_host to 1000.
Consider a more sophisticated throttling algorithm that fire off 800+ requests
all at once.
--
Rocco Caputo rcap...@pobox.com
On Oct 4, 2011, at 01:47, Anil Thyagarajan wrote:
Hi,
We have a data-cloud setup for caching (memory+persistent). Clients talk to
cloud via REST API for key/value storage and retrieval
I have a requirement to load the data-cloud with different RPS(request per
sec) under different infrastructure and system profiles, to finally build a
matrix on performance(response-time).
The approach I have taken to load the system with n-rps in x-duration(secs):
- For each second yield to an event that again creates a new event for every
(time + 1/n-rps) interval within each second interval.
#pool - max_open=1000
POE::Component::Client::HTTP-spawn(Alias = 'ua', ConnectionManager =
$pool);
sub _start {
my ($k,$h) = @_[KERNEL,HEAP];
$h-{'payload'} = substr('CLOUD-TEST' x 26, 0, 256);
$h-{'payload_size'} = 256;
$k-yield('schedule_work');
}
sub schedule_work {
my ($k,$s,$h) = @_[KERNEL,SESSION,HEAP];
my $time = Time::HiRes::time();
for(my $i=1;$i=$h-{x-duration'};$i++) {
$k-alarm_set('gen_work', $time + $i);
}
}
sub gen_work {
my ($k,$s,$h) = @_[KERNEL,SESSION,HEAP];
my $ival = 1/$h-{'rps'};
my $time = Time::HiRes::time();
my $_ival = 0;
for(my $i=0;$i$h-{'rps'};$i++) {
$k-alarm_set('some_work', $time + $_ival, $_ival, $time, 'PUT');
$_ival += $ival;
}
}
sub some_work {
my ($k,$s,$h) = @_[KERNEL,SESSION,HEAP];
my ($frac, $t_ref, $method) = @_[ARG0,ARG1,ARG2];
if ($method eq 'PUT') {
$h-{'id_ival'}-{$h-{'id'}} = $frac;
my $data = gen_header_url('PUT', $h-{'id'}++, $h-{'payload_size'});
my $req = new HTTP::Request 'PUT' = $data-{'url'};
$req-header(%{$data-{'header'}});
$req-content($h-{'payload'});
$k-post(ua = request, got_response, $req);
}
}
The above gives perfect response time for loads of 200 RPS and 180 sec
duration. But when the RPS is increased to 1000 with the same duration, the
script takes a long time and 90% of the values do not have the response data
collected. So, this is a limitation as I need to load the system with ~
2RPS for 5 mins duration with a payload of at-least 100KB (key-value).
Can the group suggest if this is the correct approach or I need to fine tune
my code. I haven't see specfic examples for such need. Any suggestions will
be helpful,
Thanks,
Anil
Re: Cannot receive data with POE tcp connection
Hi, Andhi.
Many Internet protocols are line-based and use the RFC network newline
(CR+LF). POE::Component::Server::TCP defaults to this, but you can change it.
See:
http://search.cpan.org/~rcaputo/POE-1.312/lib/POE/Component/Server/TCP.pm#ClientFilter
--
Rocco Caputo rcap...@pobox.com
On Oct 3, 2011, at 22:49, Andhi Noerdianto wrote:
Hi,
I'm build simple application using POE for receiving data from gps tracker
with tcp connection. But i can't receive the data. And then I try write the
code into python, and I get the data from tracker. This is my simple code
with Perl :
#!/usr/bin/perl -w
use warnings;
use strict;
use POE qw(Component::Server::TCP);
POE::Component::Server::TCP-new(
Port = 37773,
ClientConnected = sub {
print I got a connection from $_[HEAP]{remote_ip}\n;
},
ClientInput = sub {
print doing something..\n;
my ($sender, $heap, $input) = @_[SESSION, HEAP, ARG0];
print RECIEVED: . $input . \n;
},
);
POE::Kernel-run;
exit;
And in simple python code :
import socket
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind((,37773))
server_socket.listen(5)
print TCPServer Waiting for client on port 37773
while 1:
client_socket, address = server_socket.accept()
print I got a connection from , address
while 1:
data = client_socket.recv(512)
print RECIEVED: , data
In the POE code when I run it, just accept that there is a connection from
the tracker, but the data does not exist.
poe.jpg
With python :
python.jpg
Can you help me about this guys, how I can receive data using POE? Sorry if
my english bad.
Thanks.
Andhi
Re: Force all PoCo::Server::TCP clients to disconnect
You need to keep track of all the TCP connections. http://poe.perl.org/?POE_Cookbook/Chat_Server shows how to do it. Instead of broadcasting messages to all attached clients, though, you would be broadcasting a shutdown event. -- Rocco Caputo rcap...@pobox.com On Sep 5, 2011, at 13:47, Gunnar Strand wrote: Hi, I have a TCP server with persistent client connections which are not expected to disconnect. I want to be able to bring down the PoCo::Server::TCP, but sending shutdown makes a graceful client shutdown, waiting for persistent connections to close. I've not found any way to tell the TCP server PoCo to perform the disonnect on the server side, and the client sessions My application does not keep track of connected client sessions. According to POE::Kernel, doing: $_[KERNEL]-signal( $_[KERNEL], 'shutdown' ); should broadcast the shutdown event to all sessions, but it doesn't seem to close the client sessions. Do I need to keep track of all client sessions myself? I want to restart the server occasionally and want it to exit on INT or TERM signals - perhaps I am attacking this in the wrong way? BR Gunnar
Re: POE::Component::Server::TCP - accessing listener heap entries
Hi, Krishna.
Sorry that the docs aren't clear. It's all Perl, so you could say:
my $server_heap;
POE::Component::Server::TCP-new(
...,
Started = sub { $server_heap = $_[HEAP] },
);
... and then access the server's heap from $server_heap via closure. Be
careful to avoid circular references when you work like this, and you should be
fine.
--
Rocco Caputo rcap...@pobox.com
On Aug 29, 2011, at 21:20, Krishna K wrote:
Hi,
I am trying to debug an issue with POE::Component::Server::TCP where the
client sessions do not get closed correctly when using
POE::Component::Client::TCP (1.311/1.312) but work as expected when using
1.294.
I am maintaining global variables to manage information on number of
clients that are connected/disconnected by updating them in ClientConnected()
and ClientDisconnected() methods, which I would like to avoid and use the
main listener session's heap entry (connections) as presented in the
documentation.
http://search.cpan.org/~rcaputo/POE/lib/POE/Component/Server/TCP.pm#HEAP_Members_for_Master_Listening_Sessions
Portion of code
==
my $client_count = 0;
POE::Component::Server::TCP-new(
Alias = job_server,
Port = 32080,
# Send the client a list of available commands when it connects.
ClientConnected = sub {
$client_count++; },
# Make sure the job is destroyed when the client exits.
ClientDisconnected = sub {
$client_count--; },};
I understand that I cannot access the master listener's heap by adding of
the inline state handlers are added to the client sessions. Can you please
show me some examples on how I can access connections entry from listener's
heap.
Thanks,
Krishna
Re: killing a session
Attached. Sample output:
1) macbookpoe:~/projects/misc/support% perl shutdown-another.pl
Fri Aug 19 08:47:39 2011 - Controller started. Press Ctrl+C to exit.
Fri Aug 19 08:47:40 2011 - Ticker is working.
Fri Aug 19 08:47:41 2011 - Ticker is working.
Fri Aug 19 08:47:42 2011 - Ticker is working.
^CFri Aug 19 08:47:42 2011 - Controller caught sigint. Shutting down...
Fri Aug 19 08:47:42 2011 - Ticker is shutting down. Please be patient...
Fri Aug 19 08:47:43 2011 - Ticker has finished shutting down.
Fri Aug 19 08:47:43 2011 - Controller is being garbage collected.
Fri Aug 19 08:47:43 2011 - Ticker session is being destroyed.
1) macbookpoe:~/projects/misc/support%
--
Rocco Caputo rcap...@pobox.com
On Aug 19, 2011, at 04:02, Rizwan Hisham wrote:
Dear List,
How do I kill a running session from inside another session. There is no
parent child relation between the two session, they totally independent from
each other. Cant seem to find anyway to do it.
If its possible then kindly provide a small sample code as well :)
Thanks
--
Best Ragards
Rizwan Qureshi
VoIP/Asterisk Engineer
Axvoice Inc.
V: +92 (0) 6767 26
E: rizwanhas...@gmail.com
W: www.axvoice.com
#!/usr/bin/env perl
use POE;
POE::Session-create(
inline_states = {
_start = sub {
$_[KERNEL]-alias_set(ticker);
$_[KERNEL]-delay(tick = 1);
},
tick = sub {
_log(Ticker is working.);
$_[KERNEL]-delay(tick = 1);
},
shutdown = sub {
# Clean up our resources so we can exit cleanly.
_log(Ticker is shutting down. Please be patient...);
$_[KERNEL]-delay(tick = undef);
# Pretend shutdown takes some time.
$_[KERNEL]-delay(faux_shutdown = 1);
},
faux_shutdown = sub {
_log(Ticker has finished shutting down.);
},
_stop = sub {
_log(Ticker session is being destroyed.);
},
},
);
POE::Session-create(
inline_states = {
_start = sub {
$_[KERNEL]-alias_set(controller);
$_[KERNEL]-sig(INT = got_sigint);
_log(Controller started. Press Ctrl+C to exit.);
},
got_sigint = sub {
_log(Controller caught sigint. Shutting down...);
$_[KERNEL]-post( ticker = shutdown );
$_[KERNEL]-sig_handled();
},
_stop = sub {
_log(Controller is being destroyed.);
},
},
);
POE::Kernel-run();
exit;
sub _log {
my $message = join , @_;
print scalar(localtime), - $message\n;
}
Re: Client crash making server crash
Hi, Eric. Can you attach the confess() stack trace? It confesses because of an internal error somewhere. Release 1.312 adds a message to the confess() asking for the stack trace. If possible, could you also check against the development version in git? I found and fixed one cause for that confess() this week, but it's not released yet. I'll expedite the 1.313 release if it fixes your problem. -- Rocco Caputo rcap...@pobox.com On Aug 19, 2011, at 14:43, Eric Martel wrote: Hi folks, I'm quite new to POE. I wrote a server using POE::Wheel::SocketFactory and handling clients with POE::Wheel::ReadWrite, and everything works fine but for one thing: there are moments when a client and the server will cross-exchange much data (that is, the client sends data to the server, which replies with other data, an this multiple times until they are finished), and I happened to notice that if the client is killed before the end, the server will die, which is not what I want... The server crashes in Kernel.pm, at the line confess unless defined $session; (line 1012 as of v1.311) within _dispatch_event(). What I guess is happening (but I may be wrong) is that a '$client_wheel-put($data)' is made before the client is killed, and when POE tries to actually handle the put(), the client wheel session is already no longer accessible, before any ErrorEvent handler could be called. Am I right on this? I could not find any way I could prevent this, but surely there must be...? I wonder if replacing the confess line by a simple warn + return (or the like) could do the trick? Any help would be greatly appreciated. -- Eric Martel Québec (Québec) Canada Ce courriel est signé numériquement avec la clef suivante: This e-mail is digitally signed with the following key: ED3F191C (key://pgp.mit.edu, http://key.ericmartel.net/) Pour plus d'information: http://gpg.ericmartel.net/ For more info: http://www.gnupg.org/ eric.vcf
Re: Client crash making server crash
The _data_ses_stop() suggests that a POE::Kernel instance is stopping. The
_dispatch_event()'s second parameter is undefined, suggesting that the
POE::Kernel instance that is stopping already doesn't exist.
You've used POE::Wheel::Run to fork off a new process, and I see you've called
POE::Kernel-run() in the child process. Did you call POE::Kernel-stop()
first, to clear out the copies of the parent process' sessions? Or at the very
least, POE::Kernel-has_forked()?
See perldoc POE::Kernel for more about its stop() and has_forked() methods.
I'll try to reproduce the conditions in your stack trace after work.
--
Rocco Caputo rcap...@pobox.com
On Aug 19, 2011, at 15:47, Eric Martel wrote:
Still no luck with a snapshot taken from
http://poe.git.sourceforge.net/git/gitweb.cgi?p=poe/poe;a=snapshot;h=5b9429832974363f7b0d37590cd5a5b7fd941360;sf=tgz;
a few minutes ago:
-- BEGIN TRACE --
Server error: 'please report this stacktrace to bug-...@rt.cpan.org at
/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm line 1013'
Server error: ' POE::Kernel::_dispatch_event('POE::Kernel=ARRAY(0x95377d0)',
undef, 'POE::Kernel=ARRAY(0x95377d0)', '_stop', 8, 'ARRAY(0x95c19f8)',
'/usr/lib/perl5/site_perl/5.10.1/POE/Resource/Sessions.pm', 571, undef, ...)
called at /usr/lib/perl5/site_perl/5.10.1/POE/Resource/Sessions.pm line
568'
Server error: ' POE::Kernel::_data_ses_stop('POE::Kernel=ARRAY(0x95377d0)',
'poste161-186-4e4ebc84-41d6-0002') called at
/usr/lib/perl5/site_perl/5.10.1/POE/Resource/Signals.pm line 507'
Server error: '
POE::Kernel::_data_sig_free_terminated_sessions('POE::Kernel=ARRAY(0x95377d0)')
called at /usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm line 974'
Server error: ' POE::Kernel::_dispatch_event('POE::Kernel=ARRAY(0x95377d0)',
'POE::Kernel=ARRAY(0x95377d0)', 'POE::Kernel=ARRAY(0x95377d0)', '_signal', 16,
'ARRAY(0x9e35f48)', '/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm', 635,
undef,
...) called at /usr/lib/perl5/site_perl/5.10.1/POE/Resource/Events.pm line
315'
Server error: '
POE::Kernel::_data_ev_dispatch_due('POE::Kernel=ARRAY(0x95377d0)') called at
/usr/lib/perl5/site_perl/5.10.1/POE/Loop/Select.pm line 306'
Server error: ' POE::Kernel::loop_do_timeslice('POE::Kernel=ARRAY(0x95377d0)')
called at /usr/lib/perl5/site_perl/5.10.1/POE/Loop/Select.pm line 314'
Server error: ' POE::Kernel::loop_run('POE::Kernel=ARRAY(0x95377d0)') called
at
/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm line 1235'
Server error: ' POE::Kernel::run('POE::Kernel') called at
/usr/lib/perl5/site_perl/5.10.1/YASC/yascs.pm line 48'
Server error: ' YASC::yascs::yascs(7895) called at
/usr/lib/perl5/site_perl/5.10.1/POE/Wheel/Run.pm line 472'
Server error: ' eval {...} called at
/usr/lib/perl5/site_perl/5.10.1/POE/Wheel/Run.pm line 472'
Server error: ' POE::Wheel::Run::new('POE::Wheel::Run', 'Program',
'CODE(0x9ccf030)', 'ProgramArgs', 'ARRAY(0x9e2cd38)', 'StdoutEvent',
'server_input', 'StderrEvent', 'server_stderr', ...) called at bin/yascm.pl
line
125'
Server error: ' main::start(undef, 'POE::Session=ARRAY(0x9df8260)',
'POE::Kernel=ARRAY(0x95377d0)', 'HASH(0x9df8200)', '_start',
'POE::Kernel=ARRAY(0x95377d0)', undef,
'/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm', 1437, ...) called at
/usr/lib/perl5/site_perl/5.10.1/POE/Session.pm line 464'
Server error: ' POE::Session::_invoke_state('POE::Session=ARRAY(0x9df8260)',
'POE::Kernel=ARRAY(0x95377d0)', '_start', 'ARRAY(0x95739d0)',
'/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm', 1437, undef) called at
/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm line 1023'
Server error: ' eval {...} called at
/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm line 1022'
Server error: ' POE::Kernel::_dispatch_event('POE::Kernel=ARRAY(0x95377d0)',
'POE::Session=ARRAY(0x9df8260)', undef, '_start', 4, 'ARRAY(0x95739d0)',
'/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm', 1437, undef, ...) called at
/usr/lib/perl5/site_perl/5.10.1/POE/Kernel.pm line 1434'
Server error: ' POE::Kernel::session_alloc('POE::Kernel=ARRAY(0x95377d0)',
'POE::Session=ARRAY(0x9df8260)') called at
/usr/lib/perl5/site_perl/5.10.1/POE/Session.pm line 192'
Server error: ' POE::Session::try_alloc('POE::Session=ARRAY(0x9df8260)')
called
at /usr/lib/perl5/site_perl/5.10.1/POE/Session.pm line 373'
Server error: ' POE::Session::create('POE::Session', 'inline_states',
'HASH(0x9df8050)') called at bin/yascm.pl line 82'
Server error: ' main::yasc() called at bin/yascm.pl line 72'
-- END TRACE --
Le 2011-08-19 14:51, Rocco Caputo a écrit :
Hi, Eric. Can you attach the confess() stack trace? It confesses because
of an internal error somewhere. Release 1.312 adds a message to the
confess() asking for the stack trace.
If possible, could you also check against the development version
Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
Thanks for the clarification, Markus. I've applied a modified version of your patch as change 82af41c8ab2dd061acd7deb9979fa6cb5c4725ae. You can review it online at https://github.com/rcaputo/poe-component-resolver -- Rocco Caputo rcap...@pobox.com On Jul 29, 2011, at 05:01, Markus Jansen wrote: ... tiny correction of ^$X listed below, sorry for the typo ... /Markus -Original Message- From: Markus Jansen [mailto:markus.jan...@ericsson.com] Sent: Friday, July 29, 2011 10:40 AM To: Rocco Caputo; POE Mailing List Subject: RE: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi Rocco, thanks for coming back on this issue. Using the POE::Component::Resolver::Sidecar module is a good idea, though IMHO Module::ScanDeps should know that the module is needed via the use of \POE::Component::Resolver::Sidecar::main for Windows. The main problem is that while the [suboptimal] Windows solution would work for PAR, the standard [preferred] Unix solution does not for a number of reasons: - within PAR, $^X is set to perl @INC is set to [ par_unpack_path/inc/lib, par_unpack_path/inc/, CODE(..), CODE(..) ] - a perl executable does not exist inside the packed code (that is, at runtime under par_unpack_path) - instead, there is a limited Perl interpreter - one of the limits is that this interpreter cannot execute perl scripts via -e Each of the above effectively spoils the intended $^X -I @INC -M...Sidecar -e '...Sidecar-main()', i.e. the Sidecar execution via exec(). Due to the lack of -e support, one has to put use POE::Component::Resolver::Sidecar; POE::Component::Resolver::Sidecar-main(); into some ...Sidecar.pl file, and get that called. In the meantime, I have found that there are at least two ways to pack the above mini-script into a PAR executable (whether using the experimental --reuse switch or not is one of the details) and to get it called; hence, I would not like to dictate PAR users which of those ways to take, nor any naming conventions regarding the intermediate Sidecar.pl perl script. As a result, supplying the possibility to specify $sidecar_program seems to me the only general and lightweight way forward. Perhaps the change should come with a comment that the intended use is for PAR and similar modules, and should be used by experts who think they know what they are doing :-). Anyhow, my patch works great in production with the latest/greatest 2 PAR versions. Best regards, Markus -Original Message- From: Rocco Caputo [mailto:rcap...@pobox.com] Sent: Friday, July 29, 2011 6:54 AM To: POE Mailing List Cc: Markus Jansen Subject: Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi, Markus. It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it. Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects use statements in the source. Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here. commit 638cd9e616a5b4ffbf413672784f41896de97430 Author: Rocco Caputo rcap...@cpan.org Date: Fri Jul 29 00:44:00 2011 -0400 Load the POE::Component::Resolver::Sidecar class. The presence of this module is requested on MSWin32. Resolves rt.cpan.org ticket 69172, reported by Gabor Szabo. diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644 --- a/lib/POE/Component/Resolver.pm +++ b/lib/POE/Component/Resolver.pm @@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV); +use POE::Component::Resolver::Sidecar; + use Exporter; use base 'Exporter'; our (@EXPORT_OK) = qw(AF_INET AF_INET6); -- Rocco Caputo rcap...@pobox.com On Jul 15, 2011, at 06:17, Markus Jansen wrote: Hi Rocco, based on the excellent input I got so far from you and Steffen, I have now found a simple solution on the POE side without any assumptions towards PAR (or whatever special system used, even with PAR there is more than one way to do it :-). The idea is simply to make $sidecar_program configurable, and leave the solution details to the application if special ones are needed. Find a possible [tested] patch below, and please consider it for integration in POE::Component::Resolver 0.913. Best regards, Markus
Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
Hi, Markus. It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it. Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects use statements in the source. Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here. commit 638cd9e616a5b4ffbf413672784f41896de97430 Author: Rocco Caputo rcap...@cpan.org Date: Fri Jul 29 00:44:00 2011 -0400 Load the POE::Component::Resolver::Sidecar class. The presence of this module is requested on MSWin32. Resolves rt.cpan.org ticket 69172, reported by Gabor Szabo. diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644 --- a/lib/POE/Component/Resolver.pm +++ b/lib/POE/Component/Resolver.pm @@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV); +use POE::Component::Resolver::Sidecar; + use Exporter; use base 'Exporter'; our (@EXPORT_OK) = qw(AF_INET AF_INET6); -- Rocco Caputo rcap...@pobox.com On Jul 15, 2011, at 06:17, Markus Jansen wrote: Hi Rocco, based on the excellent input I got so far from you and Steffen, I have now found a simple solution on the POE side without any assumptions towards PAR (or whatever special system used, even with PAR there is more than one way to do it :-). The idea is simply to make $sidecar_program configurable, and leave the solution details to the application if special ones are needed. Find a possible [tested] patch below, and please consider it for integration in POE::Component::Resolver 0.913. Best regards, Markus
Re: PoCo::Client::HTTP 0.943 + run_one_timeslice = block
It may have something to do with the new POE::Component::Resolver dependency via POE::Component::Client::Keepalive. You're trying to trigger a shutdown by destroying a LWP::UserAgent::POE object. However, you don't have a DESTROY method that shutdowns PoCo::Client::HTTP. Without an explicit shutdown, I think KeepAlive is keeping sockets alive. -- Rocco Caputo rcap...@pobox.com On Jun 18, 2011, at 14:17, p...@perlmeister.com wrote: Something must have changed in PoCo::Client::HTTP 0.943 leaving the kernel blocking even if all requests have been processed. It occurs with a component using the (evil, I know!) run_one_timeslice() method, namely http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/POE.pm which then hangs in the test at http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/t/001Basic.t What I'm seeing is that even when the only HTTP request has been processed, the kernel reports === 18510 === rc +- GC test for session 1- rc | total refcnt : 2 rc | event count : 0 rc | post count: 0 rc | child sessions: 2 rc | handles in use: 0 rc | aliases in use: 0 rc | extra refs: 0 rc | pid count : 0 rc +--- and then blocks on the main CORE::select() with a timeout of roughly 3600 seconds instead of terminating the main loop. Any ideas on what might have changed recently? -- Mike Mike Schilli p...@perlmeister.com
Re: Creating and shutting down POE::Sessions
On May 19, 2011, at 03:18, Gabor Szabo wrote:
On Thu, May 19, 2011 at 5:28 AM, Rocco Caputo rcap...@pobox.com wrote:
On May 18, 2011, at 09:30, Gabor Szabo wrote:
I have tried to setup a small application that would listen on a TCP
port and get commands 'start' and 'stop',
When receiving start it should create a new POE::Session to count.
When receiving stop it should stop the counting and destroy that
POE::Session. It seems I managed to do it but I'd be glad to receive
comments about the code:
[code removed]
Hi, Gabor. Please see the revised code below. The major change was to
eliminate the counting session. They didn't seem necessary, and their
presence just complicated things.
thanks for your reply. That looks indeed more simple. Reading again
the documentation,
do I understand correctly that already the ClientConnected and
ClientInput are callbacks of
the individual, connection related POE::Session?
Yes, all the /^Client/ callbacks are for individual connection related
POE::Session instances.
Further working on the application I am writing, I'll need to have
several counters
and keep the counters work even after the original requester disconnected.
Trying with one, in my example it worked as the counter Session was not
related
to the connection.
I wonder if in your solution, can I tell the session to remain active
even after
the user disconnected? Can I also remove it from the concurrency counter?
Would in this case the separate POE::Session work better?
Yes. I assume your independent counters have names. I've attached a revised
design to account for multiple named timers. Since the code's getting larger,
I modularized it a bit, making it even larger still. Sample output:
1) macbookpoe:~% nc localhost 12345
Type 'start', 'stop', or 'list':
list
No known counters.
start aaa
Starting counter aaa...
start bbb
Starting counter bbb...
start ccc
Starting counter ccc...
list
Known counters at Sun May 22 01:56:51 2011: aaa:30152, bbb:13406, ccc:3525
stop bbb
Stopping counter bbb...
list
Known counters at Sun May 22 01:56:54 2011: aaa:50326, ccc:23699
^C
1) macbookpoe:~% nc localhost 12345
Type 'start', 'stop', or 'list':
list
Known counters at Sun May 22 01:56:57 2011: aaa:70739, ccc:44112
^C
--
Rocco Caputo rcap...@pobox.com
#!/usr/bin/perl
use warnings;
use strict;
use 5.010;
use POE qw(Component::Server::TCP);
{
package Counter;
use warnings;
use strict;
use POE; # For KERNEL, HEAP, ARG0, etc.
my %counter;
# Spawn the Counter session.
# There may be only one due to the scoping of %counter.
#
# A design incorporating multiple Counter sessions would imply each
# had its own counter namespace. I'd use $_[HEAP]{counter} in that
# case.
#
# But for now I'm using %counter in closures to simplify the code.
sub spawn {
POE::Session-create(
inline_states = {
_start = sub {
# The alias is sufficient to keep this session
# around as long as other sessions exist.
$_[KERNEL]-alias_set(counter);
},
count = sub {
my ($kernel, $counter_name) = @_[KERNEL, ARG0];
# The counter was deleted in stop_counter?
# By returning here, we stop perpetuating the recursive
# yield() that drives this counter.
return unless exists $counter{$counter_name};
print Counter $counter_name = , ++$counter{$counter_name}, \n;
# The yield() here perpetuates the counter.
$kernel-yield( count = $counter_name );
},
start_counter = sub {
my ($kernel, $counter_name) = @_[KERNEL, ARG0];
# Don't start a counter that's already running.
return if exists $counter{$counter_name};
$counter{$counter_name} = 0;
$kernel-yield( count = $counter_name );
},
stop_counter = sub {
my ($kernel, $counter_name) = @_[KERNEL, ARG0];
# Don't stop a counter that's not running.
return unless exists $counter{$counter_name};
# Deleting the counter stops it.
delete $counter{$counter_name};
},
},
);
}
# These subs that follow are plain class methods.
#
# I've put the POE callbacks into anonymous coderefs above to keep
# them visually distinct from plain methods. I often also use
# prefixes like _poe_foo() to indicate private POE callbacks.
sub start {
my ($class, $counter_name) = @_;
# start() passes a message from the client connection session to
# the counter session. The counters run in a dedicated session
# separate from each connection, so connections can come and go
# independently from counters.
$poe_kernel-post( counter = start_counter = $counter_name );
}
sub stop {
my ($class, $counter_name) = @_;
delete $counter{$counter_name};
}
sub list {
return %counter;
}
}
### Abstract the server into its own package
Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver with PAR
On May 17, 2011, at 11:48, Markus Jansen wrote: Another but smaller problem is that I have not seen an easy way to tell POE::Component::Resolver all the way down from POE::Compoent::Client::HTTP that I would like to see less than 8 subprocesses for the resolver job. Hi, Markus. The entire POE::Component::Client::HTTP stack is customizable by configuring your own objects and passing them in, but it looks like I've forgotten to document everything. Something like this should work: POE::Component::Client::HTTP-spawn( ConnectionManager = POE::Component::Client::Keepalive-new( resolver = POE::Component::Resolver-new( max_resolvers = 2, ) ) ); -- Rocco Caputo rcap...@pobox.com
Re: PoCo::JobQueue no longer on CPAN?
On May 15, 2011, at 13:47, Rhesa Rozendaal wrote: Did PoCo::JobQueue disappear from CPAN for a reason? I don't recall seeing an announcement to that effect on the mailinglist. http://search.cpan.org/dist/POE-Component-JobQueue/ gives me The distribution 'POE-Component-JobQueue' cannot be found, did you mean one of these... I know how to get it from backpan, so no worries about that. Hi, Rhesa. Thank you for bringing this to my attention. PoCo::JobQueue wasn't deliberately pulled from CPAN. I've just uploaded a new copy to replace the missing one. -- Rocco Caputo rcap...@pobox.com
Re: Robust IKC
Normally IKC's author is watching the list, but your mail might not have
reached him or he may be busy. Have you tried contacting him directly?
--
Rocco Caputo rcap...@pobox.com
On May 5, 2011, at 20:03, John R. wrote:
I would like to have my POE client recoever from a variety of IKC
failure scenarios. For example, detect that the IKC server has gone
away and reconnect when it joins.
Here is how I call the client:
POE::Component::IKC::Client-spawn(
host='locahost',
port=5200,
name='Counter',
on_error = \ikc_error,
on_connect= sub { Logger-log('counter_gui connected to
radio') },
);
POE::Component::IKC::Responder-spawn();
sub ikc_error {
Logger-log('counter_gui could not connect via IKC to Radio');
}
However, if the server goes down this handler is not hit either at
initial drop or when I attempt to post to the remote kernel. It does
get hit if server is not there at time client is executed.
Here is how the client posts:
$kernel-post('IKC', 'post', poe://Radio/radio/set_freq, $freq);
What does happen after I post to down server are messages such as:
23855: MSG TO $VAR1 = {
'kernel' = 'Radio',
'session' = 'radio',
'state' = 'set_freq'
};
23855: Unknown kernel 'Radio'.
23855: Known kernels: at
/usr/lib/perl5/vendor_perl/5.12.3/POE/Component/IKC/Responder.pm line 761.
So I looked at documentation for POE::Component::IKC::Responder and it
appears there is something in there that should do what I want (for
example monitor). So I added this code after spawning the Responder:
$poe_kernel-post('IKC', 'monitor', '*', {
register='remote_register'
});
sub remote_register {
Logger-log('counter_gui just detected IKC register');
}
However, this code code does not get hit on a connection (I figured I
would add unregister later if that was what I needed).
So, what steps am I missing? Or, is what I want to do not feasible?
Thanks,
John
Re: SocketFactory and Windows connections errors
On Feb 7, 2011, at 04:04, Ciprian Hacman wrote: When connecting to a server that is not yet listening or cannot be reached, the script just hangs. This happens with both ActiveState and Strawberry perl. Here is a test script that can reproduce this issue (there is no server listening on port 1234): [removed] Hi, Ciprian. This should fix it: https://github.com/rcaputo/poe/commit/8265022983656ed2b31bf010c4726462efc9566e It will be in a new release soon. -- Rocco Caputo rcap...@pobox.com
Re: Announce: Net:GPSD3::POE
On Apr 5, 2011, at 12:45, Michael R. Davis wrote:
POE Folks,
I've not used POE before but have plans to use a POE capability shortly.
Last night I added a POE::Session wrapper in my Net::GPSD3 (v0.15) package
but I'm not entirely sure it's using best practices.
http://search.cpan.org/dist/Net-GPSD3/lib/Net/GPSD3/POE.pm
Specifically, should I use a more specific HEAP key than wheel.
$heap-{wheel}=...
You may call it whatever you like. More specific names are good because they
help make the code more readable.
I've also not seen any best practices about passing the parent object around
in HEAP.
$heap-{gpsd}=$self;
Using object_states instead of inline_states makes sense in your case. All
your callbacks are essentially object methods. Here's an untested rewrite of
the guts of Net::GPSD3::POE. I'm sure it's not quite functional, but I hope
it's a good example.
### Called as a plain method, not a POE callback.
# @_ is $self and whatever the caller provides.
# In this case, object_states are being used because the callbacks are
# object methods. The $_[OBJECT] parameter will be populated with the
# $self for the callback. This eliminates the need to store $self
# explicitly.
sub start_session {
my $self = shift;#ISA Net::GPSD::POE
# Don't start another one.
return if $self-{sid};
$self-{sid} = POE::Session-create(
object_states = [
$self = {
_start = '_handle_poe_start',
input_event = '_handle_input_event',
shutdown= '_handle_poe_shutdown',
},
]
)-ID();
}
# POE callback. Start the session's resources. We're skipping
# $_[HEAP] altogether because the original code only shows need for
# one I/O watcher per object. We can use a single name for the
# ReadWrite resource (io). If we were managing multiple wheels,
# then we might create a hash of them keyed on wheel ID.
sub _handle_poe_start {
my $self = $_[OBJECT];
$self-{io} = POE::Wheel::ReadWrite-new(
InputEvent = input_event,
Handle = $self-socket(),
Filter = POE::Filter::Line-new(
InputLiteral = \r\n,
OutputLiteral = \n,
),
);
$self-{io}-put(qq(?WATCH={enable:true,json:true};));
},
### Called as a plain method, not a POE callback.
# @_ is $self and whatever the caller provides.
#
# This method asks the session to clean up and stop. POE's session
# encapsulation makes it difficult (but not impossible---this is Perl)
# to release another session's resources.
sub stop_session {
my $self = shift;
# Don't re-stop a dead one.
return unless $self-{sid};
$poe_kernel-call($self-{sid}, shutdown);
$self-{sid} = undef;
}
# POE callback. Deletes the wheel from within the context of the
# session that owns it.
sub _handle_poe_shutdown {
my $self = $_[OBJECT];
delete $self-{io};
}
# POE callback. Handle input.
sub _handle_input_event {
my ($self, $line) = @_[OBJECT, ARG0];
my @handler = $self-handlers();
push @handler, \Net::GPSD3::default_handler unless @handler;
my $object = $self-constructor($self-decode($line), string = $line);
foreach my $handler (@handler) {
$handler-($object);
}
$self-cache($object);
}
--
Rocco Caputo rcap...@pobox.com
Warning: Major internal data restructure
It's come to my attention that POE's not quite iThread-safe. POE keys much of its data on stringified session references. iThreads relocates objects in subthreads (and subprocesses on MSWin32), but their stringified versions in the hash keys aren't modified. Hilarity ensues when POE's data stops matching reality. I've tried defining class CLONE methods, but the data in question is sufficiently cross-referenced that it's not possible to rewrite the keys. Attempting it causes Perl to panic. Fun! Now I'm rekeying data on session ID. This should work without a time consuming CLONE phase. However it breaks many assumptions about POE's internal workings. Most people oughtn't care. If you do care, let's talk. -- Rocco Caputo - rcap...@pobox.com
IPv6 support improving, yet paradoxically breaking
Hi there. I'm about to break IPv6 support for existing IPv6 users of POE. You can avoid this breakage by vetting and installing Socket::GetAddrInfo as soon as possible. POE's IPv6 name resolution is moving to Socket::GetAddrInfo, since that module's more portable, more supported, and more future-proof. It, or something like it, is scheduled to be in Perl 5.14.0. Socket6 is redundant once Socket::GetAddrInfo is used, so I'll be removing support for it. This means the conditional IPv6 code in POE will look for Socket::GetAddrInfo instead of Socket6. Which means existing IPv6 houses will switch down to IPv4 if they upgrade POE without also installing Socket::GetAddrInfo. [Also announced at @rcaputo on Twitter, albeit with much less detail.] -- Rocco Caputo - rcap...@pobox.com
Re: Passing Sessions with Curses::UI::POE
Check out POE::Session's postback() and callback() methods, which were created
for this sort of thing. These generate anonymous coderefs that post() or
call() the invocant session. For example:
$CUI-set_binding( $SESSION-postback(blah), b );
See the docs for side effects, including numbness, shortness of breath, upset
stomach, and the ability to smell concepts that can't be expressed in a single
English word.
--
Rocco Caputo - rcap...@pobox.com
On Jan 18, 2011, at 13:05, p...@perlmeister.com wrote:
Using Curses::UI::POE and the key binding function set_binding(), I've been
using a global session variable to trigger events in POE:
use POE;
use Curses::UI::POE;
my $SESSION;
my $CUI = Curses::UI::POE-new(
inline_states = {
_start = sub { $SESSION = $_[SESSION]; },
blah = sub { # ...
},
});
$CUI-set_binding( sub { exit 0; }, q);
$CUI-set_binding( sub {
$poe_kernel-post( $SESSION, blah );
}, b);
$CUI-mainloop;
Is there a better way to post events to the Curses::UI::POE session
created earlier when the user presses a particular key?
-- Mike
Mike Schilli
p...@perlmeister.com
Re: POE::Component::SNMP Hangs When Multiple Aliases Added
I'm not familiar with POE::Component::SNMP, but I have a question.
How many @reachable_hosts do you have?
$heap-{pending} = scalar(@reachable_hosts)-1;
If you have 1 reachable host, then $heap-{pending} = 0.
if (--$heap-{pending} == 0) {
$kernel-post( $alias = 'finish' );
}
$heap-{pending} would be decremented to -1, and 'finish' would never
occur?
If @reachable_hosts 1, then finish occurs before the last host
reports? That sounds as if that could lose a host.
--
Rocco Caputo - rcap...@pobox.com
On Oct 28, 2010, at 06:36, Rehan Azher wrote:
OK I enabled the debug option
and this is what i got in the end :
No response from remote host 100.2.33.254
debug: [187] POE::Component::SNMP::close_snmp_session: calling
__clear_pending
debug: [604] POE::Component::SNMP::Dispatcher::__clear_pending():
start
debug: [615] POE::Component::SNMP::Dispatcher::__clear_pending():
clearing 0
pending requests
debug: [313] POE::Component::SNMP::Dispatcher::_unwatch_socket():
[152]
refcount 0, unselect
debug: [645] POE::Component::SNMP::Dispatcher::__clear_pending(): done
and here it hangs.
Best Regards,
--
Rehan Azher
Cell: +65 92967887
LinkedIn: http://www.linkedin.com/in/rehanazher
On Thu, Oct 28, 2010 at 11:03 AM, Rehan Azher
rehan.az...@gmail.com wrote:
Hi Experts,
I am new to POE, and to be on true end do not have more perl
experience
except some small scripts. Now I am trying to POLL one Subnet Range
using
POE::Component::SNMP. Results are displayed but at the end when
$heap-{pending}=0 it dosent seems to exit the snmp_handler sub .
Following is my code:
POE::Session-create( inline_states =
{ _start = \_start_subnet_system,
snmp_handler =
\snmp_subnet_system_handler,
}
);
sub _start_subnet_system {
my ($kernel, $heap) = @_[KERNEL, HEAP];
foreach my $address (@reachable_hosts) {
POE::Component::SNMP-create( alias =
$address,
hostname = $address,
# if you have seperate community
strings for
each host
# build a hash (@addresses becomes
%addresses)and
# associate them that way and then set
it
here.
community =
$snmp_settings[$temp_loop]{'community_string'},
version
=$snmp_settings[$temp_loop]{'snmp_version'},
timeout
=$snmp_settings[$temp_loop]{'timeout'},
retries
=$snmp_settings[$temp_loop]{'retries'},
# debug = 0x0A,
);
$kernel-post( $address = walk =
snmp_handler = -baseoid= $system_oid);
# If you are polling for N oids, this
next line
must reflect that, otherwise
# it will stop after the first OID and
not try
any of the others.
$heap-{pending} =
scalar(@reachable_hosts)-1;
}
}
$poe_kernel-run();
print Total Discovered Hosts:
$discovered_host_count\n;
print Total Not Discovered Hosts:
$not_discovered_host_count\n;
sub snmp_subnet_system_handler {
my ($kernel, $heap, $request, $response) = @_[KERNEL, HEAP, ARG0,
ARG1];
my ($alias, $host, $cmd, @args) = @$request;
my ($results, @callback_args) = @$response;
if (ref $results) {
$discovered_host_count++;
} else {
$not_discovered_host_count++;
}
if (--$heap-{pending} == 0) {
* $kernel-post( $alias = 'finish' );*
}
}
Where:
@reachable_hosts contains all hosts which are reachable via ICMP
Ping.
@snmp_settings is a hash of SNMP Settings need to be apploed ,
tested and
printed all the values it has all valued required.
$system_oid = '.1.3.6.1.2.1.1'
In fact this is a modified version of this code:
http://www.gdd.net/index.php/Asynchronous_SNMP_poller_%28Perl%29
Above code also hangs at this point *$kernel-post( $alias =
'finish' );*
Can Any pone pelase help on this.
Best Regards,
--
Rehan Azher
Cell: +65 92967887
LinkedIn: http://www.linkedin.com/in/rehanazher
Anyone calling _dispatch_event() directly?
I'm considering breaking _dispatch_event() into different methods per event type. Not all events need all of _dispatch_event(), and leaner, specific ones might be an improvement. Consider this an alert in case the changes are worth releasing. In an ideal world this shouldn't affect anyone. In the real world it probably breaks someone's code. Whose is it, and what can we do about that? -- Rocco Caputo - rcap...@pobox.com
News: Git, Moose and Snerp Vortex
Hi. It's been a while. I never write, I never call, but for what it's worth I *have* been tweeting: http://twitter.com/rcaputo - Git. POE's moving to it. There's a test project at http://gitorious.org/ poe with repositories for each top-level subproject. If everything checks out, I'll also push to Github. I'll see about converting the SourceForge project, too. If you hate Subversion, the best way to stall the migration is to report migration problems. If something's terribly wrong, I'll scrap it all and try again. But to be fair, most of POE's active committers prefer Git. It's in the project's best interests to facilitate their work. - Moose. I've been working on a tangential project called Reflex: http://search.cpan.org/~rcaputo/Reflex/ ... It's a modern, object-oriented take on POE. If there's something you don't like about POE, Reflex probably does it better. Mini-FAQ: Reflex works with existing POE-based modules. Reflex is OO, but non-OO programs can use it too. Non-Moose programs too, although Reflex will still pull in the dependency. POE remains Moose-free, so it continues to fix the hating Moose problem. :) Bunch of examples: http://github.com/rcaputo/reflex/tree/master/eg/ - Snerp Vortex. Anagram of Svn Exporter. It's a set of tools I wrote for the POE repository conversion. It converts POE's nearly 2900 revisions in about five minutes, so it's pretty cheap for me to scrap converted repositories and try again. And again. You might find it helpful, or it could explode and take off your hand. Either way, it's at http://github.com/rcaputo/snerp-vortex and patches are welcome. -- Rocco Caputo - rcap...@pobox.com
Re: POE sigdies due to die which should never be reached in POE::Queue::Array
Can you dump the queue at that point, and send me the results off-list? -- Rocco Caputo - rcap...@pobox.com On Jun 21, 2010, at 04:33, Jean Stebens wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm using version 1.2680 of POE. The following exception bumped me the last days: main::on_child_close Child has closed its output handles. main::server_stop Destroying myself. should never get here... maybe the queue is out of order at /usr/share/perl5/POE/Queue/Array.pm line 202. The main::* functions are my routines beeing called The first one is part of normal flow, the server_stop already tells me that there is something wrong going on - like a DIE Signal - then the DIE reaches the surface. It seems like POE::Queue::Array has some problems. Were they fixed in any newer versions? I can't find anything about Queue::Array beeing touched over the last year. Cheers. Jean -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAkwfI8YACgkQXY+L530SV9HsuAP/esvlaLDFdeAhbCBXw/uZVT9R JfRUQChnV6ilRUS+Kpet9Bje/8FIFQQaoPJR+SUNuXHDO1uDqq+x+ot5n6Xu9OL5 p5LDceREHGUm3LIUBAVfUfz+iysRCX8+Ifwi26CDLyAc3wcRhyEV57uVbJcfQRqF Efn30ui30h35gsWvJ/U= =f9N4 -END PGP SIGNATURE-
Re: Performance tunning for POE/Component::Client::HTTP
It's not unheard of for Perl code to be 10x slower (or more) than C. Still, a bit of Devel::NYTProf and optimization may be in order. Is ab pre-resolving and caching the host address? I'm pretty sure the Perl version isn't optimized for benchmarking loads from a single address, but if you replace the host with an IP address it should skip the resolver step. The last few responses take the longest to arrive. I've added a time() stamp and the response code to your output: 1276277210 (404) = 990 1276277210 (404) = 991 1276277210 (404) = 992 1276277210 (404) = 993 1276277210 (404) = 994 1276277211 (404) = 995 1276277211 (404) = 996 1276277211 (404) = 997 1276277212 (404) = 998 1276277212 (404) = 999 1276277227 (404) = 1000 Tweaking the Keepalive parameters seems to help a little bit. This seems a bit faster for me: my $url = http://216.115.98.241/2.8.1/build/fonts/fonts-min.css;; my $pool = POE::Component::Client::Keepalive-new( keep_alive = 1, max_open = 2000, max_per_host = 2000, timeout = 120, ); ... 1276277530 (404) = 988 1276277530 (404) = 989 1276277530 (404) = 990 1276277530 (404) = 991 1276277530 (404) = 992 1276277530 (404) = 993 1276277531 (404) = 994 1276277531 (404) = 995 1276277531 (404) = 996 1276277531 (404) = 997 1276277531 (404) = 998 1276277532 (404) = 999 1276277532 (404) = 1000 The Client::Keepalive tweaks are disturbing. From the response headers, it looks like Client::Keepalive shouldn't be holding onto sockets anyway: 1) macbookpoe:~/projects/misc/support% curl -D - http://216.115.98.241/2.8.1/build/fonts/fonts-min.css HTTP/1.1 404 Not Found Date: Fri, 11 Jun 2010 17:34:25 GMT Connection: close Server: YTS/1.17.23.1 Cache-Control: no-store Content-Type: text/html Content-Language: en Content-Length: 176 TODO: Verify whether Client::Keepalive (and/or Client::HTTP) socket cleanup paths for Connection: close transactions are optimal. It could also be socket buffer congestion on the client. On my OSX box: 1) macbookpoe:~% netstat -n|grep -c LAST_ACK 314 The POE benchmark is waiting for ACKs from the server, which is slowing things down. This is platform and version dependent, so your mileage may vary. For instance, you might have 300+ TIME_WAIT sockets instead, or your system could be tweaked to quickly recycle sockets. Anyway, if this isn't happening with ab, it means that Client::HTTP is doing something different. Possibly something that isn't optimal for benchmarking purposes. Be aware that optimal may conflict with correct. Benchmarks are permitted certain liberties that general- purpose libraries are not. Unfortunately for benchmarks, correct takes precedence. Which is not to say that Client::HTTP and Client::Keepalive are actually correct here. That's still to be seen. I'd appreciate it if you could dig into the problem a little deeper. I have some digging of my own to do, but I'm currently swamped. -- Rocco Caputo - rcap...@pobox.com On Jun 9, 2010, at 11:52, Ryan Chan wrote: Hello, I have a simple code at: http://pastebin.com/KeU4XANP This script down a small CSS file from Yahoo CDN for 1000 times, I benchmarked this script with ApacheBench(ab) POE/Component::Client::HTTP: 70 requests / sec ab (ab -n 1000 -c 100 'http://yui.yahooapis.com/2.8.1/build/fonts/fonts-min.css'): 500 requests /sec Since ab is running as single threaded mode, but still 7-8x faster than POE/Component::Client::HTTP. Is this result normal?
Re: How to deal with event timeout?
You can set a timeout for anything by using POE::Kernel's delay().
sub _start {
... in addition to the PoCo::Client::NNTP SYNOPSIS code:
$kernel-delay(connect_timeout = 60); # set it
}
sub _connected {
... in addition to the PoCo::Client::NNTP SYNOPSIS code:
$kernel-delay(connect_timeout = undef); # clear it
}
You will need to register a connect_timeout handler in POE::Session-
create() to catch the timeout.
--
Rocco Caputo - rcap...@pobox.com
On Mar 22, 2010, at 10:00, Ryan Chan wrote:
For example, I am using POE::Component::Client::NNTP
http://search.cpan.org/~bingos/POE-Component-Client-NNTP-2.14/lib/POE/Component/Client/NNTP.pm
This module does not specify any timeout, so sometimes my program
seems hanged and does not response.
Is it possible to specify a timeout or lifetime for the event, so it
will quit when reached the specified time?
About Proc::Daemon POE
If you find your POE based daemons unresponsive after calling Proc::Daemon::Init(), it's because the program has forked (twice) and closed all nonstandard filehandles. POE's internal signal-handling pipes are among the closed filehandles, and this causes some distress. POE::Kernel-has_forked() was added a little while ago to reset process-scoped data within POE after calling fork(). Such data includes outstanding child PIDs and the signal pipes. Please let me know if this doesn't fix things. Thanks! -- Rocco Caputo - rcap...@pobox.com
Re: POE::Loop::Glib/Gtk2 trips over Wheel output
On Mar 9, 2010, at 11:59, Mike Schilli wrote:
On Tue, 9 Mar 2010, Rocco Caputo wrote:
I believe you may have encountered a known bug with a simple
solution. https://rt.cpan.org/Public/Bug/Display.html?id=53302
Now if only we could somehow get that patch released
Is the solution to be applied to POE itself or POE::Loop::Glib?
Anything
I can do from 'userland'?
If it's the right solution, it's to be applied to POE::Loop::Glib.
There's not much to be done from userland, except maybe to ask the
author to apply and release the change. Maybe the author would like a
co-maintainer?
--
Rocco Caputo - rcap...@pobox.com
On Mar 9, 2010, at 03:10, p...@perlmeister.com wrote:
I'm trying to combine POE with a Gtk2 event loop, but it seems
that this
trips up POE, which then stops processing a wheel's output.
Below is a simplified example, which starts a Gtk2 loop and a Run
Wheel
which counts to 1, but POE stops processing its output after
420 and
then hangs (freezes GUI).
Funny thing is, you can even throw out the Gtk GUI parts, and it
still
fails, as long as the use Gtk2 '-init' line is there. As soon as
that's gone, POE processes everything correctly.
Would be great if someone could comment on if I'm doing something
weird.
-- Mike
Mike Schilli
p...@perlmeister.com
#!/usr/local/bin/perl -w
use strict;
use Gtk2 '-init';
use POE::Kernel { loop = Glib };
use POE::Session;
use POE::Wheel::Run;
use POE::Filter::Stream;
POE::Session-create(
inline_states = {
_start = \ui_start,
play = \play,
out= \stdout_handler,
});
$poe_kernel-run();
exit 0;
###
sub ui_start {
###
my ($kernel, $session, $heap) = @_[KERNEL, SESSION, HEAP];
$heap-{main_window} = Gtk2::Window-new ('toplevel');
$kernel-yield('play');
}
###
sub play {
###
my ($kernel, $session, $heap) = @_[KERNEL, SESSION, HEAP];
my $wheel =
POE::Wheel::Run-new(
Program = sub { print $_\n for 1..1; },
StdoutFilter = POE::Filter::Stream-new(),
StderrEvent = 'out',
StdoutEvent = 'out',
);
$heap-{player} = $wheel;
}
###
sub stdout_handler {
###
my ($heap, $input, $wheel_id) = @_[HEAP, ARG0, ARG1];
print STDERR $input\n;
}
Re: Access IP address in POE::Component::Client::HTTP
I've just released POE::Component::Client::HTTP 0.894 to PAUSE. It
adds an X-PCCH-Peer header to all responses. The header contains the
socket's remote address and port, separated by a dot. 127.0.0.1.309
represents port 309 on localhost.
X-PCCH-Peer will contain the proxy's address.port if the client is
connecting to a proxy.
--
Rocco Caputo - rcap...@pobox.com
On Jan 27, 2010, at 11:02, Doreen Grey wrote:
Hello all,
I've built a web client application with
POE::Component::Client::HTTP. I followed the examples in the
cookbook (http://poe.perl.org/?POE_Cookbook/Web_Client) and
everything works fine.
In my 'got_response' function I need to process the IP address of
the host this response came from. Let's say the $response-uri is http://poe.perl.org
, then I'll need the IP address 67.207.145.70 of that host.
Of course I could do an additional lookup of that host:
DB11 print inet_ntoa(inet_aton('poe.perl.org'))
67.207.145.70
But because POE has already resolved this name, why should I have to
do it again. So, is there a way to access the remote IP address in
the 'got_response' function?
Thanks for your help!
Doreen
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla
Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Re: Help with POE, Tk, and Multiple Processes
A third solution might be to prompt for the passphrase and perform the key setup in the parent process one time, before starting any children. Depending on your security policy, the parent may be able to cache the passphrase and reuse it for multiple machines. A fourth solution might be to delegate all this to an ssh agent. -- Rocco Caputo - rcap...@pobox.com On Dec 28, 2009, at 16:23, Votava, Craig M (Craig) wrote: Folks- You can check out the following link to see how I've been educated on this issue so far, but I'm having trouble engineering a solution. I hope to be able to put this solution into the cookbook, once it's been reviewed by all interested parties. http://www.perlmonks.org/?node_id=813252 Shows my initial question, the two answers I got, and my first failed attempt at a solution. Here is a quick summary: I'm using POE to fire off a series of processes that tail remote logfiles via ssh. The child processes try the remote commands, expecting the ssh public/private keys to already be setup between the two machines. If not, the child knows how to go ahead and set them up for the user - however it needs to get a password from the user for the setup to work. The parent process is running the Tk mainwindow for the GUI interface with the user. The two suggested solutions are: 1.) Run independent Tk event loops from the children 2.) Have the children request the parent to get this information. I'm currently trying to follow solution #2, but can't seem to get it to work. Any thoughts, pointers, suggestions, etc, are appreciated. Thanks -Craig PS - My code is available from the above link
Re: Can't store GLOB items at blib/lib/Storable.pm at /usr/local/lib/perl5/site_perl/5.10.0/POE/Filter/Reference.pm line 208
Storable can't serialize filehandles. Strip them from the data you're transporting, or choose a serialization mechanism that can handle it: % perl -wle 'use Storable; print length Storable::nfreeze(\*STDIN)' Can't store GLOB items at ../../lib/Storable.pm (autosplit into ../../ lib/auto/Storable/_freeze.al) line 339, at -e line 1 If you choose to use something like YAML, POE::Filter::Reference's documentation will explain how to replace Storable. -- Rocco Caputo - rcap...@pobox.com On Dec 22, 2009, at 16:28, Josh803316 wrote: My application using Poe::Wheel::RunPoCo::TCP::Server (and Client) and Poe::Component::Generic is crashing with the following stack trace. Most notably: pid 855 STDERR: 27:ERR: Can't store GLOB items at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_freeze.al) line 339, at /usr/local/lib/perl5/site_perl/5.10.0/POE/Filter/Reference.pm line 208 I was just wondering if anyone had seen this error before or could guide me in the best way to attack debugging it. (Trace) pid 855 STDERR: 27:ERR: 27: autoload method create_message at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 881. pid 855 STDERR: 27:ERR: 27: 1228: processing request create_message pid 855 STDERR: 27:ERR: 27: No wheel at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 382. pid 855 STDERR: 27:ERR: 1228: 9 - POE::Wheel::ReadWrite(6) - select read (from /usr/local/lib/perl5/site_perl/5.10.0/POE/Resource/ FileHandles.pm at 226) pid 855 STDERR: 27:ERR: 1228: 9 - tcp_server_got_error (from /usr/local/lib/perl5/site_perl/5.10.0/POE/Wheel/ReadWrite.pm at 288) pid 855 STDERR: 27:ERR: 1228: 9 - POE::Wheel::ReadWrite(6) - select write (from /usr/local/lib/perl5/site_perl/5.10.0/POE/Resource/ FileHandles.pm at 226) pid 855 STDERR: 27:ERR: 1228: 9 - tcp_server_got_flush (from /usr/local/lib/perl5/site_perl/5.10.0/POE/Wheel/ReadWrite.pm at 229) pid 855 STDERR: 27:ERR: 27: _stop at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 295. pid 855 STDERR: 27:ERR: 1228: 4 - _child (from /usr/local/lib/perl5/site_perl/5.10.0/POE/Resource/Sessions.pm at 538) pid 855 STDERR: 27:ERR: 1228: 4 - _stop (from /usr/local/lib/perl5/site_perl/5.10.0/POE/Resource/Sessions.pm at 528) pid 855 STDERR: 27:ERR: 26: DESTROY at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 840. pid 855 STDERR: 27:ERR: 27: DESTROY at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 840. pid 855 STDERR: 27:ERR: 1228: !!! Child process PID:1279 reaped: pid 855 STDERR: 27:ERR: 1228: !!! Your program may not be using sig_child() to reap processes. pid 855 STDERR: 27:ERR: 1228: !!! In extreme cases, your program can force a system reboot pid 855 STDERR: 27:ERR: 1228: !!! if this resource leakage is not corrected. pid 855 STDERR: 27:ERR: Can't store GLOB items at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_freeze.al) line 339, at /usr/local/lib/perl5/site_perl/5.10.0/POE/Filter/Reference.pm line 208 pid 855 STDERR: 27:ERR: Destroying self Jnms::Client::Client=HASH(0xa701e9c) at /usr/local/lib/perl5/site_perl/5.10.0/POE/Kernel.pm line 1282 pid 855 STDERR: 27: Wheel 7 generated read error 0: pid 855 STDERR: 27: Wheel 7 generated read error 0: pid 855 STDERR: 27: Wheel closed pid 855 STDERR: 27: Child 1228 exited with 5632 at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 714. pid 855 STDERR: 27: _done at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 305. pid 855 STDERR: 27: drop wheel at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 310. pid 855 STDERR: 27: remove alias 27 at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 321. pid 855 STDERR: 27: _stop at /usr/local/lib/perl5/site_perl/5.10.0/POE/Component/Generic.pm line 295. pid 855 STDERR: 855: 4 - _child (from /usr/local/lib/perl5/site_perl/5.10.0/POE/Resource/Sessions.pm at 538)
Re: Execute Jobs parallel using JobQueue
The other general advice is to use fork(), with or without POE, when
you need true parallelism.
--
Rocco Caputo - rcap...@pobox.com
On Dec 1, 2009, at 08:50, Mark Morgan wrote:
Good day, Ryan,
The problem with using 'sleep' in POE code is that POE isn't true
pre-emptive multi-tasking, but rather cooperative multitasking at the
process level. Different sessions are still running in the same
process/thread, so any actions that will monopolize CPU time for a
stretch will block all POE tasks. The general advice for POE tasks is
that they should do no blocking calls in any individual event
handling, in order to allow other sessions to run when the current one
is idle.
The best way to have a session delay itself for a time is one of the
methods described in
http://search.cpan.org/~rcaputo/POE-1.280/lib/POE/Kernel.pm#Timer_Events_%28Delayed_Messages%29
.
Take care,
Mark.
On Tue, Dec 1, 2009 at 4:38 PM, Ryan Chan ryanchan...@gmail.com
wrote:
Hello,
Consider my code below would like to execute the sleep() function in
parallel, using POE JobQueue component:
#=
use strict;
use POE qw(Component::JobQueue);
# Passive queue waits for enqueue events.
POE::Component::JobQueue-spawn(
Alias = 'passive',
WorkerLimit = 16,
Worker = \spawn_a_worker,
Passive = {
Prioritizer = sub { 1 }
}
);
sub spawn_a_worker {
my ( $postback, @job_params ) = @_;
POE::Session-create(
inline_states = {
_start = \start,
sleep = \sleep
},
args = [
$postback,
@job_params,
],
);
}
POE::Session-create(
inline_states = {
_start = \init,
_stop = sub { print END }
}
);
POE::Kernel-run();
exit(0);
sub init {
my $kernel = $_[KERNEL];
foreach ( 1 .. 10 ) {
$kernel-post( passive = enqueue = response = $_ );
}
}
sub start {
my $kernel = $_[ KERNEL ];
print Starting\n;
$kernel-yield(sleep);
}
sub sleep {
print Sleeping for 5 seconds\n;
sleep 5;
}
#==
It seems that tasks still block each other? If not, I would have all
message executed at the end of 5 seconds.
Re: Poe Design Question
What's your bottleneck? If it's just speaking with modems, POE can do
that asynchronously. You may be able to simplify the design by
pulling the jobs back into the main process.
--
Rocco Caputo - rcap...@pobox.com
On Nov 24, 2009, at 15:00, Simon Taylor wrote:
(updated)
I have built a POE app which forks children, executes some work,
returns
status back up the parent. All works fine.
Currently this is all running from one Session.
I now have a requirement to execute jobs which connect to the same
modem
bank together.
I was thinking I might structure it in the following way.
Assume 4 modem banks with 20 jobs per modem bank.
PARENT - Create Session + POE::Wheel::Run (PWR) one process per all
jobs
which need to connect to modem bank
CHILD 1 - Create Session + PWR
CHILD 1.1 one process per job
..
CHILD 1.20 one process per job
.
CHILD 4 - Create Session + PWR one process per job
This way I can use the heap of each session to manage the child jobs
which are connected to each modem bank
When using this mechanism to control how many jobs are passed to PWR
its
dependent on the heap content which in the original approach would
contain all jobs :-
while (keys(%{$heap-{task}}) $PARALLELISM ) {
Is there a better/simpler way someone can think of to use PWR and the
Session Heap to continue to execute jobs against different devices
whilst always maintaining 4 simultaneous jobs in each PWR (until
complete)
Simon
Currently start and manage starting tasks this way:-
sub StartTasks {
=Head3 _start
Function called when POE wants to start tasks
Shouldnt start any more than
$self-GetBSHParalleism($SDU::BatchSectionsHandler::SectionName)
When it does it spawns children
Event handlers allow information to be passed back to the parent
process
Mapping between state and function is done in the object states line
in
the POE::Session-create in _IterateChildrenParallel
=cut
my ($kernel, $self, $heap) = @_[KERNEL, OBJECT];
my ($child, $task);
$self-{_logger}-debug(Enter/Reentry);
while (keys(%{$heap-{task}}) $PARALLELISM ) {
if (ref($self-{_children}) eq ARRAY){
$child = shift @{$self-{_children}};
last unless defined $child;
$self-{_logger}-debug(ARRAY .Child = $child);
$task = POE::Wheel::Run-new(
Program = sub {local *__ANON__ =
_StartTasksProgramSub;
$self-_CreateChild($child);
},
StdoutEvent = TaskResult,
StdoutFilter = POE::Filter::Reference-new(),
StderrEvent = TaskError,
CloseEvent = TaskDone,
);
$heap-{task}-{$task-ID} = $task;
$self-{_logger}-info(Created child Task/PID
.$task-ID./.$task-PID);
$_[KERNEL]-sig_child($task-PID, 'sig_child');
# Wheel events include the wheel's ID.
$_[HEAP]{children_by_wid}{$task-ID} = $task;
# Signal events include the process ID.
$_[HEAP]{children_by_pid}{$task-PID} = $task;
} elsif (ref($self-{_children}) eq HASH) {
$self-{_logger}-debug(HASH .Child = $child);
$self-_CreateChild($child);
} else {
$self-{_logger}-debug(SCALAR .Child = $child);
$self-_CreateChild($child);
} # If end
} # While end
}
Simon Taylor
Development Team Lead NMS Applications
Network Managed Services
Nortel Networks
(e) s...@nortel.com
(p) +44 1279 402291 ESN 6 742 2291
(m) +44 7740 533743 ESN 6 748 3743
(yim) setuk_nortel
Re: Strategy in designing a scaleable robot with POE::Component::Client::HTTP?
Find out how many sites your system and network will let you crawl at once. Limit the number of parallel jobs to that. Read about tuning POE::Component::Client::HTTP, either in the documentation or in this mailing list's archives. Stay under your system's limits. Consider how performance plummets when a machine overcommits its memory and begins swapping. Don't let that happen to you. Use fork() with POE to take advantage of both cores. Are you looking for a design consultant? -- Rocco Caputo - rcap...@pobox.com On Nov 20, 2009, at 23:15, Ryan Chan wrote: Hello, Assume I only have a dual core server, with limited 1GB memory , I want to build a web robot to crawl 1000 pre-defined web sites. Anyone can provide a basic strategy for my tasks? Should I create 1000 sessions at the same time, to archive the max network throughput? Thanks.
Re: help with POE::Component::Client::HTTP
It appears that you're using Perl's built-in shutdown() function rather than the shutdown documented in POE::Component::Client::HTTP. Of course, I can't really tell without seeing your code, but that's what it looks like from the calls you've shown. Please look for shutdown in the POE::Component::Client::HTTP documentation. -- Rocco Caputo - rcap...@pobox.com On Nov 19, 2009, at 22:03, Aaron Goodmiller wrote: Hello all, I am using the POE::Component::Client::HTTP part of POE to call 4 URLs simultaneously. This works really well, except for the fact that there is either a 5 second lag or a 43 second lag from the last URL pulled. No matter what I set the keepalive or timeout too, it is always either 5 or 43 seconds (every once in a while 86 seconds, but that is about 1 out of a hundred times). I have tried to use the information from this URL to shut down the session after the last URL is pulled, but it never works. http://poe.perl.org/?Poe_faq/how_do_i_force_a_session_to_shut_down the calls i have tried are : shutdown(POE::Component::Client::HTTP); - it says i have too few arguments shutdown(POE::Component::Client::HTTP::*Kernel* ,POE::Component::Client::HTTP::*Session*); - nothing happens shutdown(POE::Component::Client::HTTP::*Kernel* ,POE ::Component ::Client::HTTP::*Session*,POE::Component::Client::HTTP::*Heap *); - it says i have too many arguements And I have used the code from example 2 on the following page for my URL pulls: http://poe.perl.org/?POE_Cookbook/Web_Client Any thoughts on why this could be happening? The software works superbly aside from this one glitch and I would hate to have to look yet again for another alternative to LWP. Thanks for any help! Aaron
Re: unexpected _child(lose) for a detached session from _start
Agreed, a _child(lose) before the _child(create) is bad.
It should either be a _child(create)/_child(lose) pair, or nothing in
this case. I'm tempted to go with nothing since it would be hard to
fix the create/lose timing. Also the new(detached = 1) seems good,
but I admit I haven't given it much though yet. Sometimes I change my
mind after thinking about things too hard.
If you haven't already, please submit this to bug-...@rt.cpan.org.
I'm liable to forget about POE bugs, patches, tests, etc. if they're
not in POE's bug tracker.
Thank you again for all your help.
--
Rocco Caputo - rcap...@pobox.com
On Nov 19, 2009, at 14:00, Olivier Mengué wrote:
Hi POE fellows,
I'm in the process of rewriting the backend of my
POE::Component::Schedule
to make the backend session independent of others session in the
system. The
point is that session is just backend stuff, so it should not fire
_child
events to the session from which the API may have been called. Also,
the
schedule session is a singleton that may be used by multiple
session, so it
has no reason for being attached to a particular session.
To achieve that, I'm calling POE::Kernel-detach_myself in the _start
handler of the session. POE does'nt fire _child(create) as I expected.
However I also found out that POE still fires _child(lose).
My opinion is that POE should not fire a _child(lose) event if the
session
is detached from its parent in the _start handler as a 'lose' without
'create'/'gain' is inconsistent.
Also it would be better if 'detach = 1' was an argument to
POE::Session-create(): it would make the 'not attached'
particularity of
this session more explicit for people reading the code.
Here is a test case that shows the current flawed behavior (tested
with POE
1.006, POE 1.280):
use strict;
use warnings;
use Test::More tests = 7;
use POE;
my $_child_fired = 0;
POE::Session-create(
inline_states = {
_start = sub {
$_[KERNEL]-alias_set('First');
pass _start First;
POE::Session-create(
inline_states = {
_start = sub {
$_[KERNEL]-alias_set('Second');
pass _start Second;
},
},
);
POE::Session-create(
inline_states = {
_start = sub {
$_[KERNEL]-alias_set('Detached');
pass _start Detached;
diag Detaching session 'Detached' from its
parent;
$_[KERNEL]-detach_myself;
},
},
);
},
_child = sub {
$_child_fired++;
ok($_[KERNEL]-alias_list($_[ARG1]) ne 'Detached',
$_[STATE]($_[ARG0]) fired for
.$_[KERNEL]-alias_list($_[ARG1]-ID));
},
},
);
POE::Kernel-run();
pass _child not fired for session detached in _start unless
$_child_fired
!= 2;
pass Stopped;
Olivier Mengué
http://o.mengue.free.fr/
Re: Not seeing anything back out of STDOUT
Yes, plain text looks like a very large data structure to
POE::Filter::Reference. It is busy buffering data until it has enough
to thaw(). That behavior appears to the application as if the filter
has stalled.
--
Rocco Caputo - rcap...@pobox.com
On Nov 10, 2009, at 04:29, Simon Taylor wrote:
Thanks Rocco you are right.
I came across the solution myself last night after discovering all the
POE ASSERT settings.
Trawled the stats at the end - could see many POE::Wheel::Run select
stdout activities but nothing that was calling the StdOut Event
Handler.
So I removed the StdoutFilter and now I'm getting to see all the
output
from the child process.
Now I just have to work out why POE::Filter::Reference was being
stalled.
Am I right in thinking that if the child sends anything on STDOUT that
isn't POE::Filter::Reference text then it stalls the comms for the
lifetime of that child process not just that instance of
POE::Wheel::Run
select stdout??
If this is the case then I maybe have some untrapped output I need to
chase down. Which I guess I can do by leaving the filter off.
Simon
Simon Taylor
Development Team Lead NMS Applications
Network Managed Services
Nortel Networks
(e) s...@nortel.com
(p) +44 1279 402291 ESN 6 742 2291
(m) +44 7740 533743 ESN 6 748 3743
(yim) setuk_nortel
-Original Message-
From: Rocco Caputo [mailto:rcap...@pobox.com]
Sent: 09 November 2009 23:04
To: POE Mailing List
Subject: Re: Not seeing anything back out of STDOUT
This can happen with POE::Filter::Reference if the child process
displays some non-POE::Filter::Reference text. POE::Filter::Reference
does its best to interpret the child process' output as legal data,
and it patiently awaits the completion of a bad record.
The socket connection is made by creating the socket in the parent
process, then sharing it between the parent and child after the fork()
duplicates it. No client/server shenanigans are performed to set up
the connection.
It could be something else, but I can't tell without seeing more
code. :)
--
Rocco Caputo - rcap...@pobox.com
On Nov 9, 2009, at 06:05, Simon Taylor wrote:
Using POE::Wheel::Run to create forked children.
As soon as i fork them off I try and send some output back to the
parent
but i never see it arrive.
At this point STDOUT in the child is not a TTY and lsof indicates
its a
socket connection.
new_batch 30624 sdu 0u unix 0x0100376a7680 9949033 socket
new_batch 30624 sdu 1u unix 0x0100376a7680 9949033 socket
new_batch 30624 sdu 11u unix 0x0100376a7680 9949033 socket
I'm thinking this is possibly how POE is connecting the child output
with that of the parent.
I've run POE in Debug mode and im not seeing any calls into the Event
Handler for STDOUT.
Setup as follows - STDERR seems to be working ok.
Any assistance appreciated.
sub StartTasks {
=Head3 _start
Function called when POE wants to start tasks
Shouldnt start any more than MAX_CONCURRENT_TASKS
When it does it spawns children
Event handlers allow information to be passed back to the parent
process
Mapping between state and function is done in the object states line
in
the POE::Session-create in _IterateChildrenParallel
=cut
my ($kernel, $self, $heap) = @_[KERNEL, OBJECT];
my ($child, $task);
$self-{_logger}-debug(Enter/Reentry);
while (keys(%{$heap-{task}}) MAX_CONCURRENT_TASKS) {
if (ref($self-{_children}) eq ARRAY){
$child = shift @{$self-{_children}};
last unless defined $child;
$self-{_logger}-debug(ARRAY .Child = $child);
$task = POE::Wheel::Run-new(
Program = sub {local *__ANON__ =
_StartTasksProgramSub;
$self-_CreateChild($child);
},
StdoutFilter = POE::Filter::Reference-new(),
StdoutEvent = TaskResult,
StderrEvent = TaskError,
CloseEvent = TaskDone,
);
$heap-{task}-{$task-ID} = $task;
$self-{_logger}-info(Created child Task/PID
.$task-ID./.$task-PID);
$_[KERNEL]-sig_child($task-PID, 'sig_child');
# Wheel events include the wheel's ID.
$_[HEAP]{children_by_wid}{$task-ID} = $task;
# Signal events include the process ID.
$_[HEAP]{children_by_pid}{$task-PID} = $task;
} elsif (ref($self-{_children}) eq HASH) {
$self-{_logger}-debug(HASH .Child = $child);
$self-_CreateChild($child);
} else {
$self-{_logger}-debug(SCALAR .Child = $child);
$self-_CreateChild($child);
} # If end
} # While end
}
sub TaskResult {
my ($self,$result) = @_[OBJECT, ARG0];
$self-{_logger}-info(ID/PID/Result ID: $result-{taskid} :
$result-{pid} :$result-{status}\n);
my %sec_status = %{$result-{section_status}};
foreach my $key (%sec_status){
$self-{_logger}-info($sec_status{$key}\n);
}
}
Simon Taylor
Development Team Lead
Re: Not seeing anything back out of STDOUT
This can happen with POE::Filter::Reference if the child process
displays some non-POE::Filter::Reference text. POE::Filter::Reference
does its best to interpret the child process' output as legal data,
and it patiently awaits the completion of a bad record.
The socket connection is made by creating the socket in the parent
process, then sharing it between the parent and child after the fork()
duplicates it. No client/server shenanigans are performed to set up
the connection.
It could be something else, but I can't tell without seeing more
code. :)
--
Rocco Caputo - rcap...@pobox.com
On Nov 9, 2009, at 06:05, Simon Taylor wrote:
Using POE::Wheel::Run to create forked children.
As soon as i fork them off I try and send some output back to the
parent
but i never see it arrive.
At this point STDOUT in the child is not a TTY and lsof indicates
its a
socket connection.
new_batch 30624 sdu 0u unix 0x0100376a7680 9949033 socket
new_batch 30624 sdu 1u unix 0x0100376a7680 9949033 socket
new_batch 30624 sdu 11u unix 0x0100376a7680 9949033 socket
I'm thinking this is possibly how POE is connecting the child output
with that of the parent.
I've run POE in Debug mode and im not seeing any calls into the Event
Handler for STDOUT.
Setup as follows - STDERR seems to be working ok.
Any assistance appreciated.
sub StartTasks {
=Head3 _start
Function called when POE wants to start tasks
Shouldnt start any more than MAX_CONCURRENT_TASKS
When it does it spawns children
Event handlers allow information to be passed back to the parent
process
Mapping between state and function is done in the object states line
in
the POE::Session-create in _IterateChildrenParallel
=cut
my ($kernel, $self, $heap) = @_[KERNEL, OBJECT];
my ($child, $task);
$self-{_logger}-debug(Enter/Reentry);
while (keys(%{$heap-{task}}) MAX_CONCURRENT_TASKS) {
if (ref($self-{_children}) eq ARRAY){
$child = shift @{$self-{_children}};
last unless defined $child;
$self-{_logger}-debug(ARRAY .Child = $child);
$task = POE::Wheel::Run-new(
Program = sub {local *__ANON__ =
_StartTasksProgramSub;
$self-_CreateChild($child);
},
StdoutFilter = POE::Filter::Reference-new(),
StdoutEvent = TaskResult,
StderrEvent = TaskError,
CloseEvent = TaskDone,
);
$heap-{task}-{$task-ID} = $task;
$self-{_logger}-info(Created child Task/PID
.$task-ID./.$task-PID);
$_[KERNEL]-sig_child($task-PID, 'sig_child');
# Wheel events include the wheel's ID.
$_[HEAP]{children_by_wid}{$task-ID} = $task;
# Signal events include the process ID.
$_[HEAP]{children_by_pid}{$task-PID} = $task;
} elsif (ref($self-{_children}) eq HASH) {
$self-{_logger}-debug(HASH .Child = $child);
$self-_CreateChild($child);
} else {
$self-{_logger}-debug(SCALAR .Child = $child);
$self-_CreateChild($child);
} # If end
} # While end
}
sub TaskResult {
my ($self,$result) = @_[OBJECT, ARG0];
$self-{_logger}-info(ID/PID/Result ID: $result-{taskid} :
$result-{pid} :$result-{status}\n);
my %sec_status = %{$result-{section_status}};
foreach my $key (%sec_status){
$self-{_logger}-info($sec_status{$key}\n);
}
}
Simon Taylor
Development Team Lead NMS Applications
Network Managed Services
Nortel Networks
(e) s...@nortel.com
(p) +44 1279 402291 ESN 6 742 2291
(m) +44 7740 533743 ESN 6 748 3743
(yim) setuk_nortel
Re: TCP keepalive?
Can it be done in an extensible, sustainable way? We can add a
constructor parameter and code to handle every possible socket option,
but I would like to see something better.
For example, would it make sense to pass socket options as an array of
setsockopt() parameters? They could be applied to the socket in
sequence:
SocketOptions = [
[ SOL_SOCKET, SO_KEEPALIVE, 1 ],
[ another option ],
...,
],
Possibly not, since some setsockopt() calls may need to know the
previous value of an option. flw's suggestion to use a Connected
callback makes more sense. You should be able to do anything you need
there, no matter what that entails.
--
Rocco Caputo - rcap...@pobox.com
On Oct 20, 2009, at 13:48, Adams Sean wrote:
never mind, this was easy to enable globally by modifying
SocketFactory.pm @ line 706:
setsockopt($socket_handle, SOL_SOCKET, SO_KEEPALIVE, 1) or do {
$poe_kernel-yield(
$event_failure,
'setsockopt', $!+0, $!, $self-[MY_UNIQUE_ID]
);
return $self;
};
Although I think POE should expose the option to users of
Client::TCP... do you want a patch for this?
On Oct 19, 2009, at 11:14 AM, Adams Sean wrote:
What is the best way to enable TCP keepalive on a
POE::Component::Client::TCP session?
I am using POE for home automation and I have connections which are
often idle for hours, or only get traffic in the receive direction.
In these cases there is no indication that the connection has
failed if, for example, the endpoint resets due to power outage.
POE 1.280 is released to PAUSE
POE 1.280 has just been released, but it may take up to a day before your favorite CPAN mirror catches wind of it. You'll also need the latest POE::Test::Loops, version 1.030. Several contributors helped make this release happen. Notably but not exclusively: Craig Andrew Feren Adam Kennedy Marius Kjeldahl Chris Williams The people of irc.perl.org #poe. The people of poe(a)perl.org. Let me know if I left you out. Those of you following along may notice that the version numbers jumped a little. That's because POE has undergone a couple optimizations that alter its behavior a little. I/O Dispatch is Faster I/O events jump the queue in POE 1.280. Skipping an enqueue and dequeue saves significant time. The drawback is that I/O is dispatched in a different order relative to other kinds of events. Most people won't care, but it has affected one of POE::Component::Client::HTTP's tests. Speak up if you think it's affecting you. Session Cleanup is Faster In POE 1.280, session cleanup is done just before the event loop would wait for new events. Programs that aren't event bound should show decreased latency because the cleanup will be scheduled during idle times. This optimization changes the timing of session cleanup and their resulting _stop events. While I don't think it affects many people, it has already bitten Adam Kennedy. Please let us know if you suspect it's gnawing on you, too. Other Changes POE::Wheel::Run::Win32 code has been merged into POE::Wheel::Run. Many thanks to Chris Williams for developing and contributing POE::Wheel::Run::Win32, and Andrew Feren for the patch. The tests should be a little faster since the full tracing has been turned off. Tracing is only enabled when running coverage tests now. This also exposes more warnings to the console, most of which have been fixed. POE::Wheel::ReadLine memory leaks have been fixed. Unfortunately, it requires the use of Scalar::Util::weaken(). This wheel won't run on really old versions of Perl anymore. Patches that don't reintroduce the memory leak are welcome. Miscellaneous $kernel-has_forked() fixes. The mark and sweep session garbage collection fixed an issue where call() would sometimes sidestep garbage collection. Mysterious program hangs should be eliminated by this release. Lots of MSWin32 fixes! Not nearly enough, but it's improved by a leap and a bound. ... and a bunch of really minor things in the CHANGES file. Thanks everyone! What's next? -- Rocco Caputo - rcap...@pobox.com
Re: POE::Wheel::Run::Win32 and Win32::Daemon
The question in my mind: If fork() is so troublesome on Windows, do we
have an alternative?
For the (Program = foo.exe) form, we can possibly avoid fork()
altogether. http://rt.cpan.org/Public/Bug/Display.html?id=48715#txn-659406
includes some code that promises to work well.
For the (Program = \foo) case, I don't know. Can Perl on Windows
handle that well at all?
--
Rocco Caputo - rcap...@pobox.com
On Oct 12, 2009, at 10:54, Andreas Altergott wrote:
Hi,
Andrew Feren wrote:
Something like the following will give you better results.
my $pid;
if($pid = fork()) {
print(FOUT running ($pid)\n);
wait();
} else {
open(FOR, '', 'C:\delme-kid.txt');
thread();
close(FOR);
sleep(10);
exit(0);
}
Thanks for the suggestion, but I do not see why this should give
better
results in combination with Win32::Daemon. As already described the
service will get a termination request as soon as the child
terminates,
if you do use fork. Nevertheless I tested this and it did terminate
the
service after one loop.
The termination request comes from the service control manager.
Probably it thinks the service terminated. This doesn't make sense.
Especially because it tries to tell a service to stop, which in its
opinion did already stop. Nevertheless it does so.
This behaviour happens only with fork AFAIK.
Regards,
Andreas
Upcoming POE Changes
[This is a repost of http://use.perl.org/~rcaputo/journal/39736] Those of you who use POE for serious things should be aware of a couple changes introduced after 1.269. First, here's a public service annoucement from POE: Developers who want to keep up with POE's latest changes are encouraged to follow its repository. You'll get instant notification of changes as often as you'd like, and you'll have maximum lead time to report new bugs or port production code to new features. I've also released Version 1.269_002 to the CPAN for developers who are more comfortable with that. Remember: CPAN shells don't install developer releases by default. And now back to the changes! Synchronous I/O Dispatch POE::Kernel dispatches I/O events synchronously after 1.269. Previously these events would be enqueued along with everything else, only to be dequeued and dispatched as soon as possible. Now they're dispatched as they happen, saving the overhead of a round trip through the event queue. Developers should notice an improvement in I/O bound programs. This naturally changes the timing of I/O events. Where in the past they may have been enqueued behind other events, they now come first. This could cause problems for users who depend on the relative timing of I/O events compared to other kinds of events. I expect most developers won't notice the difference. This optimization is most effective for code that uses POE::Kernel's select_read() and select_write() watchers directly. Additional layers of abstraction, such as POE::Component::Server::TCP or AnyEvent add overhead that has not been reduced by this optimization. Mark and Sweep Session Garbage Collection Session termination and memory reclamation have been combined and delayed. Combining them reduces the overhead of POE::Kernel's dispatcher by eliminating a few method calls per event. Delaying garbage collection allows POE to do this work when it's likely to be idle anyway. While the latter optimization doesn't reduce CPU consumption, it should reduce callback latency in the common case. People who require _stop to be called immediately when a session releases its last resource may be disappointed. _stop events are dispatched as a side effect of garbage collection, which as I've mentioned has been delayed. Adam Kennedy's Test::POE::Stopping has been affected. I hope his is a special case. More to Come There will be more improvements in the future, but that's all for now. Stay tuned, and please report any problems you encounter early and often. Thanks! -- Rocco Caputo - rcap...@pobox.com
Re: I need some help with POE::Wheel::Run on Windows
Thanks for pointing that out. I had forgotten the backstory on it. It strongly implies that the I/O redirection must be done BEFORE the fork() call on Windows, as it seems that fork() communicates stdio to exec() inside Perl. Time for test cases... -- Rocco Caputo - rcap...@pobox.com On Oct 2, 2009, at 09:12, Andrew Feren wrote: Hi all, If it helps anyone the original discussion about adding the Win32::Console::_SetStdHandle() and related changes can be found here. It seems pretty clear that a lot effort went into trying to get the original patch right. I'd really love understand why this code is needed (on not). So far all of my tests have performed identically (other than the leak) with or without the _SetStdHandle() calls. -Andrew Rocco Caputo wrote: First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged into POE::Wheel::Run. Andrew has also reported a memory leak POE::Wheel::Run under Windows: https://rt.cpan.org/Ticket/Display.html?id=50068 My problem is that I don't know Win32 APIs well enough to say whether his patch does any harm. He's bypassing Win32::Console::_SetStdHandle() calls that set STDIN, STDOUT and STDERR to the pipes that communicate with the parent process. It seems like reasonable code, but I don't know any better. Any help would be appreciated. Thank you.
I need some help with POE::Wheel::Run on Windows
First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged into POE::Wheel::Run. Andrew has also reported a memory leak POE::Wheel::Run under Windows: https://rt.cpan.org/Ticket/Display.html?id=50068 My problem is that I don't know Win32 APIs well enough to say whether his patch does any harm. He's bypassing Win32::Console::_SetStdHandle() calls that set STDIN, STDOUT and STDERR to the pipes that communicate with the parent process. It seems like reasonable code, but I don't know any better. Any help would be appreciated. Thank you. -- Rocco Caputo - rcap...@pobox.com
POE 1.260 may be imminent, but it's no big deal.
I mentioned this in the 1.020 release announcement, but it might be lost in the noise. POE 1.020 includes retrograde versions of all its sub-modules. As a result, the PAUSE indexer has rejected them: module: POE::Component version: 1.020 in file: lib/POE/Component.pm status: Not indexed because lib/POE/Component.pm in R/RC/RCAPUTO/POE-1.007.tar.gz has a higher version number (1.2447) ... and everything else but POE itself. This may also cause problems for people who rely on specific sub-module versions. I think it may also affect package managers outside CPAN. It's an unfortunate side effect of the ongoing migration from Subversion to Git. I had to remove reliance on Subversion's $Revision $ tags, so now all the sub-modules track POE's version. A POE 1.260 release should resolve the issue. POE and all its modules will have versions numerically greater than their highest released versions. Indexers will be happy again. -- Rocco Caputo - rcap...@pobox.com
POE::Loop::{Event,Gtk,Tk} Now Separate Distros
I just released these loops (versions 1.300) as separate distributions. Older versions are still in POE's distribution until the next release, which I hope to be this week. Software that needs these modules MUST depend on them explicitly now, or they won't install properly after the next POE release. This is your last opportunity to fix dependencies in advance. I'll probably warn y'all again once POE's released, but by then it'll be, as they say, TOO LAATE!! -- Rocco Caputo - rcap...@pobox.com
Re: how to create parallel sessions?
Perl's for() is not a parallel dispatcher, sorry. POE::Session-
create() should take relatively little time, after which your
program should call POE::Kernel-run(). This run() method is a
cooperative timeslice dispatcher, which is often parallel enough.
--
Rocco Caputo - rcap...@pobox.com
On Aug 25, 2009, at 21:56, Liu, Fred wrote:
Hello,
I use for () { POE::Session-create() }.
But it seems for() is not a parallel dispatcher.
Thanks.
Fred Liu
POE::Wheel::Run ClosedEvent reliability and SIGCHLD timing changes
There has been an issue on some systems (Linux, it seems) where POE::Wheel::Run doesn't emit a CloseEvent for children behind a pty or pty-pipe conduit. Philip Gwyn provided test cases for this, and we were able to make a fix. POE's repository has it now, and you can get a copy to try by running: svn co https://poe.svn.sourceforge.net/svnroot/poe/trunk/poe poe There's a caveat. The timing between SIGCHLD delivery and EOF from a child process may have changed. It may even vary. Do any operating systems even guarantee an order? If you suspect you have a program that relies on SIGCHLD or CloseEvent coming first, please check out and test a copy of POE as soon as possible. For those whose code breaks, it may be more reliable after revision 2617 to trigger cleanup on CloseEvent rather than SIGCHLD. Programs will still need to register sig_child() watchers to reap child processes, though. -- Rocco Caputo - rcap...@pobox.com
1.007 is released.
POE 1.007 is on PAUSE, and it should be at your favorite CPAN mirror shortly. A number of my components have also been fixed, but their releases are delayed until POE 1.007 is thoroughly distributed. They'll help test POE more thoroughly that way. Highlights of POE 1.007: call() has been optimized slightly. DrGeek on irc.perl.org #poe pointed out in irc.perl.org that call() doesn't need to do a garbage collection check. It never intrinsically affects a session's reference count. Michael Fowler fixed POE::Component::Server::TCP documentation and added a regression test for the component. Philip Gwyn added a signal pipe to make signals more reliable when the USE_SIGNALS switch is enabled. Gcola on irc.perl.org #poe did substantial testing on ActivePerl for Windows. Adam Kennedy wrested some Windows machines from Microsoft for testing, which helped a lot. Some of the signals tests were moved out to POE::Test::Loops so that other event loop adapter writers can take advantage of them. If POE::Loop authors have their own tests they'd like to share, let me know what I can include. Clarified a couple warnings: the run() was never called warning now points to documentation to disable it. The PID reap warnings explain themselves better. -- Rocco Caputo - rcap...@pobox.com
Plans for 1.010
Provided no severe bugs appear: I'm rounding up the version number due to a public API change and a planned distribution restructuring. POE::Component::Server::TCP public API change, per the previous POE::Component::Server::TCP bug fixes, possibly incompatible thread. Code that relies on the current, undocumented behavior will need to be coordinated with a POE upgrade. I'll work on this first, and I'll announce when the change is committed. This should give concerned people more time to review and plan for the change. POE::Loop::Event, ::Tk and ::Gtk will be distributed separately. If your code relies on one of these POE::Loop classes, be sure the dependency is explicitly set. This will load the proper loop and base POE distribution, now and in the future. Cygwin testing and fixes, time permitting. rt.cpan.org has a couple tickets that I can get to now that I have access to a faster Windows machine. Thanks again to Adam Kennedy and crew for making it happen. -- Rocco Caputo - rcap...@pobox.com
Re: POE::Component::Server::TCP bug fixes, possibly incompatible
I went with option C. The change is committed and ready for review: http://poe.svn.sourceforge.net/viewvc/poe?view=revrevision=2613 The commit message reads: !!! This change breaks backward compatibility on a relatively unused !!! feature. You are affected if you use ARG0 or ARG1 in a !!! POE::Component::Server::TCP ClientConnected callback. ClientArgs promised more than it could deliver, and people finally noticed. This change backs off supplying the socket in $_[ARG0], and it expands ClientArgs' arrayref into @_[ARG0..$#_]. Thanks to Michael Fowler for rt.cpan.org #47855 (which this resolves), and POE's mailing list for advice on which way this change should go. -- Rocco Caputo - rcap...@pobox.com On Jul 21, 2009, at 06:40, Olivier Mengué wrote: Euh, well, I was meaning option A. But either A or C is good for me. Option B is too awkward as a bad API would stay forever and would bite any new Server::TCP user. Le 21 juillet 2009 12:37, Olivier Mengué olivier.men...@gmail.com a écrit : 2009/7/16 Chris 'BinGOs' Williams ch...@bingosnet.co.uk Anyways, I see three options: a). Make the functionality match the documentation; b). Make the documentation match the functionality; c). Do what dngor suggests and flatten ClientArgs, forget the socket and document as such. Cheers, As a POE::Component::Server::TCP user (useful to quickly write tests for client components), I prefer option C as I complained about 2 months ago : http://www.mail-archive.com/poe@perl.org/msg04260.html Olivier Mengué.
Re: POE::Test::Loops 1.020, and upcoming POE releases
On Jul 24, 2009, at 06:29, Olivier Mengué wrote: 2009/7/24 Rocco Caputo rcap...@pobox.com POE::Test::Loops 1.020 has been released. I'm concerned about bug 45158 [1] which is blocking a clean install of POE on HP-UX. To summarize, the test POE/Test/Loops/sbk_signal_init.pm is reliyng on the assumption that sleep() can work while an alarm() is set, which the Perl documentation clearly warns against, and is effectively not working on HP-UX. Does replacing sleep(5) with select(undef,undef,undef,5) fix it? I also asked on the ticket just a few minutes ago. If that works, I'll patch it up and release 1.021. Also, why did the version number bump from 1.005 to 1.020 ? I accidentally bumped the release twice. I originally meant it to be 1.010. QA took longer than expected, and by release time I forgot that I had already bumped the revision. This release includes some harsh signals regression tests from POE's distribution. I expect it to cause new headaches for some POE::Loop authors. Signals are often painful to deal with. -- Rocco Caputo - rcap...@pobox.com
Re: poe.perl.org down?
Thanks for letting me know. Slicehost tells me that the physical server hosing poe.perl.org's VPS is failing, and they are moving my VPS to a new machine: The server hosting your slice is showing signs of imminent hardware failure, as a precautionary measure we will be moving all slices off of this server shortly. I've sent them support mail asking how long the site will be down. -- Rocco Caputo - rcap...@pobox.com On Jul 20, 2009, at 10:46, jorge sanchez wrote: Oops, missed the list.. the poe.perl.org site seems to be down again... Jorge
Re: POE+Signals : The final solution
Thanks for the patch. Tony Cook also helped prevent this from being a penultimate solution by discussing some of the subtler issues. I've applied the patch as revision 2576. It tests clean here (OSX with Select, Event and IO::Poll; FreeBSD with Tk, Event, Select and IO::Poll). As Philip mentioned, I plan to make a developer release next week for testing and a production 1.007 release if that goes well. There's never too much testing, so feel free to check out a copy of the repository and begin your own QA procedures. Thanks! -- Rocco Caputo - rcap...@pobox.com On Jul 19, 2009, at 00:37, Philip Gwyn wrote: Hello POEers. This is a heads-up about problems with POE and signals. If you use a signal handler in POE, you are probably affected. As of 1.006, POE's event queue manipulation code isn't signal safe. If a signal occurs while POE is removing an event from the queue (example: $poe_kernel-remove_alarm( $aid )), there is a chance that POE will remove the wrong element. POE::Queue::XS::Array probably doesn't suffer from this problem. Long running daemons that fork a lot of sub-processes (example: pre- or post-forking daemons) are highly susceptable to this problem. What's more, there is a race condition between verifying the queue and calling select() or poll(). You have probably been affected by this bug, without knowing it. If you have seen mysterious hanging processes, POE events that are going missing or other heisenbugs, this bug is a prime suspect. Rather then try patch around the problem, we are going to adopt a final solution : Semantically, the signal handlers and the main queue are running in different threads. The only robust way to implement threads is share- nothing. This means that the signal handlers have to talk to the main queue via some sort of conduit like a socket or pipe. The RT ticket is here : https://rt.cpan.org/Ticket/Display.html?id=47966 The second patch implements a signal pipe using POE::Pipe::OneWay, which is highly portable. The previous unsafe behaviour is available if the POE_USE_SIGNAL_PIPE=0 env var is set. The patch has already been tested on Linux (CentOS 4) and Mac OS X against all the POE::Loops that we could install. If possible, it would be very much appreciated if you could test it on your systems. Report here on list or via RT. A developer release is planed, to see how much smoke the CPAN testers release. Then general CPAN release. Thank you, -Leolo
Version 1.008 Goal
While the list is on the topic of event loops, I'd like to finally split POE::Loop::Event, POE::Loop::Gtk and POE::Loop::Tk into separate distributions for the 1.008 release. They'll get better CPAN testers coverage as their own distributions with mandatory dependencies. More test reports leads to more love, which may improve quality. Thanks! -- Rocco Caputo - rcap...@pobox.com
Re: POE::Component::Server::TCP bug fixes, possibly incompatible
On Jul 14, 2009, at 02:16, Michael Fowler wrote: http://rt.cpan.org/Ticket/Display.html?id=47855 47855 requires a bit of discussion. The problem is that the ClientConnected callback does not actually receive a socket in ARG0. ARG0 has been spliced off in the POE::Wheel::ReadWrite constructor, so ARG0 is actually the ClientArgs parameter. This change was implemented nearly 4 years ago (to fix a leaking socket problem), so anything that actually uses ARG0 will break if the code is changed to match the documentation. How should the code be changed? Should it be made conservatively, so that any code relying on ARG0 being ClientArgs continues to work? Should it be fixed to match the documentation? The documentation is wrong. I misread the code and thought that ClientConnected was part of the POE::Wheel::SocketFactory SuccessEvent handler. It's not. It's really part of the client-handling session's _start handler, which has different semantics. For starters, $_[ARG0] isn't guaranteed to contain anything in particular. One advantage of out and out breaking old code is that ClientArgs could actually be flattened into ARG1..$#_. I think you're almost right. The correct behavior would be for ClientArgs to align with @_[ARG0..$#_]. This still breaks current code, but it's cleaner. -- Rocco Caputo - rcap...@pobox.com
Re: poe.perl.org down?
Out of memory again. I've rebooted and reconfigured Apache a little. Sorry for the inconvenience. -- Rocco Caputo - rcap...@pobox.com On Jul 15, 2009, at 07:59, Larry Clapp wrote: Oops, I meant to send this to the list. -- Forwarded message -- From: Larry Clapp la...@theclapp.org Date: Wed, Jul 15, 2009 at 7:58 AM Subject: Re: poe.perl.org down? To: Phil Whelan phil...@gmail.com On Tue, Jul 14, 2009 at 7:21 PM, Phil Whelan phil...@gmail.com wrote: I couldn't see it early either, but seems to available now. Is it back for you, Larry? As of 7:50am Eastern time, I can't get it from home or work. Home ISP is rr.com; dunno 'bout at work. I can resolve the IP address but the browser (Opera, if it matters) just hangs. It doesn't even time out, as near as I can tell. Yesterday I switched back to the browser and it'd been trying to get to poe.perl.org for over an hour. -- Larry
Re: Doesn't run under activestate?
I responded on PerlMonks. -- Rocco Caputo - rcap...@pobox.com On Jul 14, 2009, at 08:47, Craig Votava wrote: Folks- I would like to add something like this to the POE cookbook, but this version won't run under activestate. Any pointers on what I'm doing wrong? This is also part of a discussion at http://www.perlmonks.org/?node_id=775719 . Thanks -Craig
Re: poe.perl.org down?
The virtual machine it was hosted on went into swap death. The logs are quite full, but they don't really say why this happened. I suspect I need to reduce Apache's resource limits. Some site news while we're talking about it: New CSS. The central column will stretch if you open the window wider. There are experimental RSS feeds for major changes, and all changes. I'm going to tweak the save form later to discourage making all changes major. Also to encourage meaningful change messages. I'm sure there are bugs. Please keep up the feedback. :) -- Rocco Caputo - rcap...@pobox.com On Jul 14, 2009, at 17:33, Larry Clapp wrote: I can't get poe.perl.org to talk to me. Anyone know why? -- Larry
Re: POE site not displayed correctly under IE7
Thanks for the report. I'm able to log in fine, with my current account and a new one from scratch. I did find and fix a cookie problem, which might be related. Please try again and contact me directly if there's still a problem. -- Rocco Caputo - rcap...@pobox.com On Jun 27, 2009, at 10:29, Olivier Mengué wrote: It looks like the wiki login does not work correctly. The login page and the signup/preferences pages says I'm logged in (user name : Dolmen, user id : 1062), but the other pages don't. When I try to login, it says the password I defined from the preferences page is invalid.
Re: POE Newbie chasing anothers code
Class methods work by lucky chance rather than deliberate design. Calling POE::Kernel by class may not work for all methods, and it may not work in the future. There's no plan to change this, but it may be a side effect of some (also unplanned) future feature. Or it may become officially supported, in which case you'll see it in the docs. The $poe_kernel export (or $POE::Kernel::poe_kernel) is mainly for libraries that may not get POE::Session's usual callback parameters. -- Rocco Caputo - rcap...@pobox.com On Jun 25, 2009, at 22:38, Mark Swayne wrote: Bruce Ferrell wrote: is there a difference between: POE::Kernel-post() and $poe_kernel-post() Bruce, In case you haven't found it yet, they are (basically) the same. $poe_kernel is exported by POE::Kernel. It's a reference to the Kernel singleton. Calling $poe_kernel-post, calls the post method on the $poe_kernel object. While POE::Kernel-post, is using a hard coded class name. The only place I'd expect a difference, is if you start working with a subclass of POE::Kernel that overrides the post method. Then all your POE::Kernel calls will create chaos. (Or maybe if a future version of post breaks without an object reference, like ID). The examples for post use $_[KERNEL] to access the kernel object. Out of distrust for exported globals, I'd do as in the docs, and use $_[KERNEL]. http://search.cpan.org/dist/POE/lib/POE/Kernel.pm#$poe_kernel http://search.cpan.org/dist/POE/lib/POE/Kernel.pm#post_DESTINATION,_EVENT_NAME_ [,_PARAMETER_LIST] --Mark Swayne
Re: Simple datafile-to-GUI help needed
Craig also asked at http://perlmonks.org/?node_id=775181 so I replied there. There's no point in having this conversation in two places. The code was small enough to include on the list. Please only post good code to the Cookbook. Corollary: please report (or fix) broken code in the Cookbook. -- Rocco Caputo - rcap...@pobox.com On Jun 26, 2009, at 12:19, Craig Votava wrote: Folks- I have a simple problem that I want to solve with POE. As I'm looking at all the various options, I'm getting overwhelmed and need some help picking out the best. I have an ascii logfile (non-growing) that I want to represent in a GUI (using Tk). My code so far, creates a POE session, and builds the GUI output window (which is ready to start getting data to add into it). Now I need to read in the data, parse it into an internal data structure, then feed that to the GUI for display. What is the best way to do this? Here are what I think are my 2 best thoughts so far: 1.) Same session: use Tk's fileevent to get any data that is available, then parse it, then display it (POE handles the sequencing so the GUI still functions while the reading-in and parsing is happening, right?). 2.) Separate sessions: Create a filter that parses the data and use something like POE::Wheel::FollowTail starting it at the beginning of the file. Use events between the two sessions to alert the GUI there's a new internal data structure ready for slapping up on the GUI. Can the POE experts help me understand why I would want one over the other? Are there any better options? Would it make sense to post this result into the cookbook (I couldn't find an example of this anywhere)? Any pointers are appreciated. Thanks -Craig
Re: POE site not displayed correctly under IE7
Thanks for the pointers. I've updated the templates header generation code to pass validator.w3.org for the front page. It's a wiki without a test suite, so I can't guarantee every page will validate. In fact, I strongly suspect that many pages will fail. Feel free to patch pages with bad content. There's a login/signup link at the bottom, and it'll enable an edit link when you do. I know some of the cookbook examples are too wide for the content column. I'm going to try to make the content column stretch to accommodate wide content. -- Rocco Caputo - rcap...@pobox.com On Jun 14, 2009, at 05:45, Olivier Mengué wrote: This is because under quirks mode, the auto margin method is not enough to make IE align your container to the center So the right fix would be to tell IE to run in standards mode instead of quirks mode. This can be done by adding a doctype to the HTML The W3C validator would be helpful to fix the problems. http://validator.w3.org/check?uri=http%3A%2F%2Fpoe.perl.org%2Fcharset=(detect+automatically)doctype=HTML+4.01+Strictgroup=0user-agent=W3C_Validator%2F1.654 In particular : - use type=text/javascript instead of language=javascript for script tags - fix URL encoding : replace with amp; in href attributes - add p around input (search box) Thanks for POE and the huge documentation work. Olivier.
Re: How to get rid of the delay after the real work is done?
That's probably the keep-alive timer in POE::Component::Client::HTTP. You can preemptively shutdown the client when you know you won't need it anymore. Starting and stopping POE involves some setup cleanup overhead. I'm not sure if the overhead will exceed your expectations. If it does, I have a POE::Component::Client::HTTP wrapper that avoids the stop/ restart and provides a different API. Experimental, unreleased code, no warranties, same-terms-as-perl, etc.: http://poe.dyndns.org/~troc/tmp/pua.pl http://poe.dyndns.org/~troc/tmp/pua-defer.pl -- Rocco Caputo - rcap...@pobox.com On Jun 19, 2009, at 05:29, Michael Lackhoff wrote: I am totally new to POE, so this might be a silly question but I looked at the mailing list archive and the FAQ and didn't find the answer. What I want to do is a parallel web client. For this I found a good recipe in the POE cookbook http://poe.perl.org/?POE_Cookbook/ Web_Client The first example looked exactly like what I was looking for so I copied the code and only added a few more URLs to @url_list. Everything went fine, I got the web pages very fast but then after the real work was done (all pages displayed) I had to wait for another 5 seconds until the script ended. When I did this with the real pages I want to get (some JSON results) and a bit of Time::HiRes output the relation was 4 seconds for the actual work and then the 5 seconds delay until I could proceed. If I could speed this up to the 4 seconds needed for the actual work, everything would be fine and so much better than 9 seconds. How can I achieve this? Eventually I want to wrap this script into a method of my application, call it with a list of URLs and return the combined result. The application is a mod_perl web app. Are there any issues with this setup I should watch out for? Thanks -Michael
Re: How to get rid of the delay after the real work is done?
You can shut down POE::Component::Client::HTTP by posting a shutdown event to it, generally by its alias. Interesting. It could be that the program is exiting before connections are released by POE::Component::Client::Keepalive (used by the HTTP client), and global destruction is causing things to be freed out of order. I wonder why I hadn't seen that when I wrote it... -- Rocco Caputo - rcap...@pobox.com On Jun 19, 2009, at 16:08, Michael Lackhoff wrote: On 19.06.2009 18:35 Rocco Caputo wrote: That's probably the keep-alive timer in POE::Component::Client::HTTP. You can preemptively shutdown the client when you know you won't need it anymore. How would I do that? As I said I am totally new to POE and still have some problems picking up the concepts involved. Starting and stopping POE involves some setup cleanup overhead. I'm not sure if the overhead will exceed your expectations. If it does, I have a POE::Component::Client::HTTP wrapper that avoids the stop/ restart and provides a different API. Experimental, unreleased code, no warranties, same-terms-as-perl, etc.: http://poe.dyndns.org/~troc/tmp/pua.pl http://poe.dyndns.org/~troc/tmp/pua-defer.pl Thanks, I will try them with my application (on Monday). Looks promising, though in pua.pl I get this error message: (in cleanup) Can't call method free on an undefined value at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 during global destruction. -Michael
Re: POE site not displayed correctly under IE7
Change applied, thank you very much.
--
Rocco Caputo - rcap...@pobox.com
On Jun 14, 2009, at 02:00, Tsz Ming WONG wrote:
Hello,
Now look better, but the whole page is still aligned to the left,
rather than center in Firefox/Opera.
This is because under quirks mode, the auto margin method is not
enough to make IE align your container to the center
It can be fixed by adding the following CSS into your global.css
body {
text-align:center
}
#container {
text-align:left;
}
On Sun, Jun 14, 2009 at 1:43 PM, Rocco Caputo rcap...@pobox.com
wrote:
Change applied. Thank you, Phil.
--
Rocco Caputo - rcap...@pobox.com
On Jun 14, 2009, at 00:33, Phil Whelan wrote:
Hi Rocco,
You can change this in your global.css
#navigation {
FONT-SIZE: 8pt; WIDTH: 100px
}
to this...
#navigation {
float: left;
FONT-SIZE: 8pt; WIDTH: 100px
}
Cheers,
Phil
--
Best Regards,
tszming
Re: Need some help...
Please turn on warnings. You are using my ($kernel, $self, $heap) = $_[KERNEL, OBJECT, HEAP]; when an array slice is needed my ($kernel, $self, $heap) = @_[KERNEL, OBJECT, HEAP]; Note the difference between 1) poerbook:~% perl -e 'my ($a, $b, $c) = $x[0,1,2];' (no output) and with warnings on: 1) poerbook:~% perl -we 'my ($a, $b, $c) = $x[0,1,2];' Multidimensional syntax $x[0,1,2] not supported at -e line 1. Name main::x used only once: possible typo at -e line 1. -- Rocco Caputo - rcap...@pobox.com On Jun 13, 2009, at 20:20, Rob Fugina wrote: I've been away from the list for a while, but now I'm wondering if everyone else hasn't, as well. Is anybody still here? I've been having some trouble writing a couple of modules with object states recently -- usually I stick to inline states -- and I was hoping someone here would be able to give me some advice. Maybe someone can start by explaining why in the attached program it seems that the parameters aren't lined up properly with the constants (OBJECT, SESSION, HEAP, etc...). The result is a mess... Thanks, Rob objtest.pl
