POE::Component::Logger roadmap
Hi POE fans,
POE::Component::Logger provides a session that uses the Log::Dispatch
framework for centralized logging. Once it is spawn, you can simply log
with:
Logger-log('message');
or
Logger-log({ level = debug, message = 'message');
This module was originally written by Matt Sergeant 8 years old. It has a
few
issues that I'm currently fixing as Matt promoted me to co-maintainer.
The code in development is hosted on GitHub:
http://github.com/dolmen/POE-Component-Logger
I've already published 2 developer releases:
- 1.00_01 a few days ago: added a test suite
- 1.00_02 a few hours ago: more tests, and a major optimization
If you are already a PoCo::Logger user you are invited to test 1.00_02 now.
The next planned release in the next days will be:
- 1.01: same as 1.00_02, but a public release
- 1.10: major internal refactoring to fix RT#62397, a race condition
problem that occurs when logging at $DefaultLevel and $DefaultLevel
(may be there will be a 1.09_01 before if I get some feedback)
- 1.50: add a proper 'shutdown' state (old RT#4062): there was
no proper way before. As a workaround some users were posting
a '_stop' message to the session to tell it to terminate.
This is dirty and this will be deprecated in that release: a message
will be sent to the log at the 'notice' level to alert about the new
API.
I would appreciate your feedback about this plan.
I would also appreciate if you tell me if you are a PoCo::Logger user, and
in
particular if you have a CPAN distribution that uses it: that could help me
to understand how P:C:L is actually used for writing the right regression
tests.
Olivier Mengué, POE::Component::Logger co-maint.
Re: Easy way to daemonize a POE script?
2010/3/10 Winfried Neessen nees...@cleverbridge.com Now I'd like to run it independently, so my question is, is there an easy way for me to run a POE script daemonized (w/o having to use Unix backgrounding/forking)? You'll of course have to use that. But use CPAN packages. I've used Proc::Daemon successfully with a POE application. But I recommend to deamonize before starting the POE loop. Olivier.
Re: unexpected _child(lose) for a detached session from _start
2009/11/20 Rocco Caputo rcap...@pobox.com Agreed, a _child(lose) before the _child(create) is bad. This a case of _child(lose) without any _child(create) ever (neither before or after). 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. I'm tempted to go with nothing, as the session is declared detached. 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. See bug #51772. Thank you again for all your help. POE is helping me much, so thanks to you. It helped me to build my application during the last 9 months. However, debugging is painful and I'm still tracking a particular bug in my code for 3 weeks now. I just discovered POE::API::Peek and it looks like it is the toolbox I was looking for for months. Olivier.
unexpected _child(lose) for a detached session from _start
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/
Bug #50907 blocks ActiveState auto-packaging of POE since May
Could someone have a look at bug #50907 ? t/30_loops/select/connect_errors.t failure on Win32 (blocks ActiveState PPM auto-packaging) http://rt.cpan.org/Public/Bug/Display.html?id=50907
Debugging not stopping sessions
Hi, I'm using POE::Wheel::Run::Win32 0.16 with POE 1.006 on ActivePerl 5.10 (1003). My POE-based program has a main session which launchs sessions which use a P::W::R::Win32 to run an external process. The process are running OK, the output is returned OK, the sig_child is fired as expected. Also, the wheel is released and destroyed. But the problem I have is that the session around the wheel is never released. This is a problem because I don't want to stop my main session before all child programs are stopped. So I wonder what is keeping the session alive. I've not been able to reproduce the problem with a simple test case The ASSERT flags I tried are unusable due to the amount of data they print. I tried to track the session refcount, but it seems to be quite low. So here is my question: what can I use to track what is keeping the session alive ? How can I inspect the session (even using private APIs) and the kernel ? Olivier.
Re: Git
2009/10/25 Joel Bernstein j...@fysh.org On 25 Oct 2009, at 19:19, Guy Hulbert wrote: On Sun, 2009-25-10 at 11:23 -0600, chris fedde wrote: you might also consider hanging out on irc.perl.org#poe. Most of the active developers frequent that channel. Thanks for letting me know. I have enough bad habits already that I have not yet had time to master irc ... but if lurking here is fruitless then perhaps I'll have to consider it. It's not a given. #poe isn't really a chat channel, although some goes on. I can understand avoiding IRC as it has the potential to be a distracting time-sink but (for me, anyway) it's a much more gratifying and interactive way to get in contact with developers (both of POE, and people using POE) than the list. You'll find that the learning curve is trivial, and the rewards considerable. And if your reason to not want to try IRC is because you have to install software, just use this web gateway: http://widget.mibbit.com/?server=irc.perl.orgchannel=%23poenoServerTab=truenoServerNotices=truenoServerMotd=trueautoConnect=true Olivier.
Fwd: Which editor(s) or IDE(s) are you using for Perl development?
Hi, Gabor Szabo, the Padre team leader, has started a poll about editors/IDE. See his message below. Olivier. -- Forwarded message -- From: Gabor Szabo Date: 2009/10/21 Subject: Which editor(s) or IDE(s) are you using for Perl development? Hi, I am running a poll with the above question. I'd appreciate if you took 5 seconds and answered it. http://bit.ly/2V8Ltz regards Gabor http://szabgab.com/blog.html
Re: POE::Wheel::Run::Win32 and Win32::Daemon
2009/10/13 Andrew Feren acfe...@yahoo.com I'm not really sure, but I'd guess that the Daemon module isn't copying/cloning something that it should. As a result Win32::Daemon::StopService(); is getting called unexpectedly in a DESTROY or END block when the child exits. That is probably the reason as there is effectively an END block. Maybe checking $$ before calling StopServicewould fix the problem. I'll try this.
Re: Upcoming POE Changes
2009/10/9 Rocco Caputo rcap...@pobox.com [This is a repost of http://use.perl.org/~rcaputo/journal/39736http://use.perl.org/%7Ercaputo/journal/39736 ] 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. For those that may not be familiar with the CPAN shell features, developer releases can be installed with the CPAN shell: cpan install RCAPUTO/POE-1.269_002.tar.gzMore 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! I tried 1.269_002 with my test suite for POE::Component::Schedule. In my test 12-session-ref.t I got this warning: t\12-session-ref-1.t .. 4/6 Use of uninitialized value $sid in hash element at C:/STRAWB~1/perl/site/lib/POE/Resource/SIDs.pm line 80. Olivier.
Re: POE::Wheel::Run::Win32 and Win32::Daemon
2009/10/9 Andreas Altergott alterg...@mira-consulting.net
Hi,
Hi Andreas
this will be especially interesting for dolman :-)
dolmen !
as already described in previous emails there is a big problem when
using POE::Wheel::Run::Win32 with Win32::Daemon as a windows service.
Your service will get a termination request from windows, as soon as any
child process terminates.
Here is the bug I submitted in the POE::Component::Daemon::Win32 queue, for
reference:
https://rt.cpan.org/Ticket/Display.html?id=50020
This happens because POE::Wheel::Run::Win32 is using the fork() method.
I do not know how exactly ActiveStates Perl handles the fork() method,
but it does it different than the system() method. The system() method
also creates a child process, but it waits for the child until it
terminates. This does not initiate a termination request to the
service. Although both do create sub processes.
Speaking in windows terminology one has to say threads instead of
processes. So system() is using fork() according to the perldocs. And
fork() tries to do a real fork() if it is available. On windows it is
not. So it has to create a thread. I don't know how it does terminate
a thread though. It must be different when you use system(), else it
wouldn't terminate your service.
This description is incomplete.
POE::Wheel::Run{,::Win32} on Win32 creates an external process using
Win32::Job and uses the thead created with fork() to monitor the job
(-watch) and report its status.
Win32::Job-watch() does polling (which is awkward when you live in the POE
world) to monitor the subprocess.
Luckily, using threads is not a blocking process. It means that your
POE program can continue working, while the thread is also doing it's
work. The only drawback is, that your programs will be windows
specific. You can not do a 'use threads;' inside of eval, require or
any other trick to make it system independent.
o http://perldoc.perl.org/threads.html
The fast solution is to use threads instead of POE::Wheel::Run::Win32.
I think that POE::Wheel::Run{,::Win32} already does this.
use threads;
my $thr = 0;
sub thread {
return(system(C:/Progs/any.exe));
}
...
# inside a POE subroutine that's getting called over and over again
unless ($thr) {
print(creating thread\n);
$thr = threads-create('thread');
}
if ($thr-is_joinable()) {
print(thread returned . $thr-join() . \n);
$thr = 0;
}
...
I've been reading in some previous mails, that POE::Wheel::Run and
POE::Wheel::Run::Win32 have been merged. This is nice to hear :-)
But in this case it complicates things. Because now POE::Wheel::Run is
system independent by using fork().
If you look at the code you'll see that the code path on Win32 is quite
different.
So merged does not means does the same.
Also, the aim of the merge is to make your code system independent (of
course this is not the case when using Win32::Daemon too).
As described this is not possible
with Win32::Daemon. So either it should be noted somewhere, that
POE::Wheel::Run is not usable from a windows service, or it should be
split again :-p into POE::Wheel::Run::Win32 using threads instead of
fork(). ;-)
Maybe this issue is easier to fix, by attacking fork() itself.
Well, you do not strictly need POE::Wheel::Run, if you do use threads.
They are not blocking anyway, by doing the test is_joinable().
I'm not sure if this concerns only Win32::Daemon or if it is a global
windows service problem with Perl using fork().
I think that the problem is in Win32::Daemon, for which we don't have the
source (his author, Dave Roth seems to have disappeared without publishing
the source for its latest binary release). See the bug where I have posted a
simple test case that does not involves neither POE,
POE::Wheel::Run{,::Win32}, Win32::Job or POE::Component::Daemon::Win32.
I managed to workarounk the bug by separating the program in two process:
- a service wrapper that uses Win32::Daemon, open a server socket and
launches the real service as a subprocess. When it receive a command from
the service manager it forward it to the child as a message on the socket.
- the real service : connects to the service wrapper socket when it starts
and monitors it with a POE::Component::Client::TCP
I wanted to use Win32 pipes instead of Internet sockets, but I've found
nothing to monitor them with POE (there is no select() on file/pipe handles
in the Win32 world).
Anyway this works because there is exactly only one process launched from
the wrapper, and when the child exits, we want the service to stop which
matches the state change that Win32::Daemon sends.
However this is a really ugly and we will still need one day a fixed
Win32::Daemon.
Olivier Mengué (dolmen).
Re: Communication between a Session and TCP Client Component
2009/10/11 Dave Schwartz dece...@gmail.com Hi, Excuse me for spamming a long mail. Stumbled upon POE and want to use it for my latest project. Don't worry. All messages on this list are usually quite long. Is there something obviously wrong here when the user tries to give an offset other than 0 or the way I am trying to send data to the server. Any advice would be a great help. The problem is that you try to send messages to the server before the connection occured. Try to modify your program like this: - create the $server in the _start event of the main session, and store the id in $_[HEAP] - make the Connected event send an event 'Connected' to the main session - create the watcher on the Connected event in the main session Olivier.
Re: I need some help with POE::Wheel::Run on Windows
2009/10/2 Rocco Caputo rcap...@pobox.com First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged into POE::Wheel::Run. Great news ! I'm using POE::Wheel::Run::Win32 with my patch for bug #43995 https://rt.cpan.org/Ticket/Display.html?id=43995 Looks like you applied the patch. Fine! 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. This part of the code is the most obscure to me and I've still not figured out why it is required. The comments in the code are not enough for me to understand. Any help would be appreciated. Win32::Job-spawn() has options : stdin, stdout; stderr. Maybe a path to explore? Olivier. http://search.cpan.org/~dolmen/ http://search.cpan.org/%7Edolmen/
Re: session not stopping
2009/9/30 Andreas Altergott alterg...@mira-consulting.net It simply does not shut down, although there are no more jobs running from my point of view. I don't understand yet though, how I can check, if there is indeed something still keeping it alive. (replying to the list this time. Grrr) Do you send the 'shutdown' event to the POE::Compononent::Win32::ChangeNotify session in your SIGINT handler?
Re: running POE as a windows service
2009/9/29 Andreas Altergott alterg...@mira-consulting.net Hi, I was trying to find a solution how to run POE applications as a Windows service. I've found two solutions so far, but I am not quite satisfied with them. I'm also writing a Win32 service with POE for a few months now. You may have seen my recent posts on PerlMonks.org. o Using Win32::Daemon with POE::Component::Daemon::Win32 This would be perfect, but Win32::Daemon is not available as a PPM for Perl 5.10. POE::Component::Daemon::Win32 is not available as a PPM at all. Win32::Daemon for Perl 5.10 is still beta and it seems this project is stalled. There's no source available to further develop this, is there? http://www.roth.net/forums/topic.php?id=206 It is worse: I tried to contact Dave Roth get access to the missing source and to takeover the maintainership, but he doesn't responds to e-mail and I've seen no news from his on the net since 2008. I've managed to build a PPM from the latest binary available (20080324) and was hoping to build my application on it, even with the risk of not having the source in case of bug. However I discovered last week a major Win32::Daemon bug for my application: an incompatibility with the fork() implementation. See https://rt.cpan.org/Ticket/Display.html?id=50020 Since yesterday I'm trying to workaround this bug by isolating the service management part in a separate process that launch my main service code using Win32::Job. My prototype of this service wrapper is working but I've now to implement IPC to send events from the wrapper to my POE session in the wrapped process. I'll post my questions about this in a separate thread. o Using instsrv and srvany from Windows. This tools do not interact with POE. They simply kill the service without giving it a chance to stop. That's why I'm not using it. Olivier.
Re: run an interactive command using POE::Wheel?
2009/9/25 woosley. xu. redic...@gmail.com
besides, if you write the interactive code like this:
my $user = STDIN;
chomp $user;
$_[HEAP]-{job}-put($user);
my $pass = STDIN;
chomp $pass;
$_[HEAP]-{job}-put($pass);
It won't pop up all the message from the child process until you finished
all your input. Maybe this is not the right way to do it, I am wondering
which is the way.
You should do user input in the POE way too: by watching events coming from
STDIN.
Maybe POE::Wheel::ReadLine is what you need.
Olivier.
Re: run an interactive command using POE::Wheel?
2009/9/24 Andreas Altergott alterg...@mira-consulting.net Please let me (us on the mailing list ;-) ) know if you do. It would be easier if the mailing list admin would reconfigure the list so we get poe@perl.org as the recipient when we choose Reply. More than once I made the mistake of replying only to the post author. Olivier.
POE debugging without STDOUT/STDERR ?
Hi, I'm building a Windows service with POE (using POE::Component::Daemon::Win32). In a service I have no access to STDOUT/STDERR. The only output I have is my log file (Log::Dispatch::File). How can I use POE's debugging features without access to STDOUT/STDERR? I would like to find why a event does not seem to be dispatched. Is it possible to get a POE state image (sessions, and list of events in the queue of each session) as a string? Olivier. http://search.cpan.org/~dolmen/
Re: POE debugging without STDOUT/STDERR ?
Le 22 septembre 2009 11:42, Olivier Mengué olivier.men...@gmail.com a
écrit :
How can I use POE's debugging features without access to STDOUT/STDERR?
This was obvious:
close STDOUT;
close STDERR;
open STDOUT, ':utf8', ${log_file}.out;
print STDOUT --\n;
open STDERR, ':utf8', ${log_file}.err;
print STDERR --\n;
Re: POE::Test::Loops 1.020, and upcoming POE releases
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. Also, why did the version number bump from 1.005 to 1.020 ? [1] http://rt.cpan.org/Ticket/Display.html?id=45158 -- Olivier Mengué http://search.cpan.org/~dolmen/
Re: POE::Component::Server::TCP bug fixes, possibly incompatible
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::Component::Server::TCP bug fixes, possibly incompatible
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 site not displayed correctly under IE7
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. 2009/6/26 Rocco Caputo rcap...@pobox.com 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
[Announce] POE::Component::Schedule
Hi, I just published POE::Component::Schedule, a component that generate alarms from DateTime::Set objects. This module is a friendly fork of POE::Component::Cron by Chris Fedde, that has less dependencies as the cron specific bits are removed. See https://rt.cpan.org/Ticket/Display.html?id=2 for the history Olivier Mengué (DOLMEN).
Component::Server::TCP: how to get access to the server's HEAP from a client handler?
Hi,
I'm using POE for 3 months now with great pleasure. Thanks to all the
developers!
I'm now playing with TCP client and server.
I've created a POE::Component::Server::TCP which has global state stored in
its HEAP, initialized in the Started event.
How can I get access to that HEAP from the Client* events (ClientConnected
in particular) as those are called from a different session ?
Maybe there is a parent-child relationship between the sessions I could use
to retrieve the server session and call it's -get_heap() ?.
Below is some sample code that I'm sure you'll help me to complete.
Olivier
dolmen on cpan.org
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests = 8;
use POE qw(Component::Server::TCP Component::Client::TCP);
my $host = 'localhost';
my $port = 12344;
POE::Component::Server::TCP-new(
Alias = server,
Address = $host,
Port = $port,
Started = sub {
pass [Server] Started #.$_[SESSION]-ID;
$_[HEAP]{test} = 42;
},
ClientConnected = sub {
pass [Server] ClientConnected #.$_[SESSION]-ID;
# How to get access to {test} from the server session's HEAP ?
#is(???, 42, Server HEAP access);
},
ClientInput = sub {
pass [Server] ClientInput #.$_[SESSION]-ID;
diag($_[ARG0]);
},
ClientDisconnected = sub {
pass [Server] ClientDisconnected #.$_[SESSION]-ID;
$poe_kernel-post('server', 'shutdown');
},
);
POE::Component::Client::TCP-new(
Alias = client,
RemoteAddress = $host,
RemotePort= $port,
Started = sub {
pass [Client] Started;
},
Connected = sub {
pass [Client] Connected;
$_[HEAP]{server}-put(Hello);
$poe_kernel-yield('shutdown');
},
ServerInput = sub { },
Disconnected = sub {
pass [Client] Disconnected;
},
);
$poe_kernel-run;
pass 'Stopped';
Re: Component::Server::TCP: how to get access to the server's HEAP from a client handler?
Le 26 mai 2009 16:46, Mark Morgan makk...@gmail.com a écrit :
From the P:C:S:TCP docs, it looks like you should be able to do this
by passing a reference to it via ClientArgs constructor argument.
You may need to end up weakening it in client, to allow the server
sessions and anything else the client heap is referring to to be
reaped.
Mark.
I have found a solution using ClientArgs.
However it is currently broken, at least it doesn't work as the
documentation says.
See my code below. I've shown with JSON what I get in ClientConnected args :
- socket is missing
- ARG0 is the given ClientArgs. It would me more useful to get Args
flattened in ARG0..$#_
The documentation for this code has still many TODOs and no one is
complaining on RT so probably not many use it.
http://search.cpan.org/~rcaputo/POE-1.005/lib/POE/Component/Server/TCP.pm#Default_Child_Connection_Sessionshttp://search.cpan.org/%7Ercaputo/POE-1.005/lib/POE/Component/Server/TCP.pm#Default_Child_Connection_Sessions
Olivier
http://search.cpan.org/~dolmen/ http://search.cpan.org/%7Edolmen/
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests = 8;
use JSON 'to_json';
use POE qw(Component::Server::TCP Component::Client::TCP);
my $host = 'localhost';
my $port = 12344;
POE::Component::Server::TCP-new(
Alias = server,
Address = $host,
Port = $port,
ClientArgs= [ {} ],
Started = sub {
pass [Server] Started #.$_[SESSION]-ID;
my $server_data = $_[HEAP]-{server_data} = $_[ARG0]; # The hash given
in Args
$server_data-{test} = 42;
},
ClientConnected = sub {
# According to the documentation ARG0 is the socket, ARG1 is ClientArgs
# But the doc doesn't match the code :(
# We get ClientArgs in ARG0, but it would be more consistent to get it
flattened
diag(to_json([ @_[ARG0..$#_] ]));
my $server_data = $_[HEAP]-{server_data} = $_[ARG0]-[0]; # The hash
given in Args
pass [Server] ClientConnected #.$_[SESSION]-ID;
is($server_data-{test}, 42, Server HEAP access);
},
ClientInput = sub {
pass [Server] ClientInput #.$_[SESSION]-ID;
diag($_[ARG0]);
my $server_data = $_[HEAP]-{server_data};
is($server_data-{test}, 42, Server HEAP access);
},
ClientDisconnected = sub {
pass [Server] ClientDisconnected #.$_[SESSION]-ID;
$poe_kernel-post('server', 'shutdown');
},
);
POE::Component::Client::TCP-new(
Alias = client,
RemoteAddress = $host,
RemotePort= $port,
Started = sub {
pass [Client] Started;
},
Connected = sub {
pass [Client] Connected;
$_[HEAP]{server}-put(Hello);
$poe_kernel-yield('shutdown');
},
ServerInput = sub { },
Disconnected = sub {
pass [Client] Disconnected;
},
);
$poe_kernel-run;
pass 'Stopped';
