bad param patch for PoCo::Client::TCP
Any objections to adding a check for bad params in Client::TCP? It would've
saved me some recent typo-related head-scratching. I just stole the code
from Server::TCP.
Dan
--- /usr/lib/perl5/site_perl/5.8.5/POE/Component/Client/TCP.pm 2004-07-15
10:01:38.0 -0400
+++ TCP.pm.my 2006-02-02 18:24:01.576860544 -0500
@@ -95,6 +95,11 @@
croak $mi requires a ServerInput parameter unless defined
$input_callback;
+ # Complain about strange things we're given.
+ foreach (sort keys %param) {
+carp $mi doesn't recognize \$_\ as a parameter;
+ }
+
# Defaults.
$session_type = 'POE::Session' unless defined $session_type;
POE::Component::OSCAR 0.03 released
Hi all, Just wanted to let everyone know that POE::Component::OSCAR 0.03 is out. I've included two sample scripts in the distribution, one is an OSCAR/telnet gateway, and the other uses Wheel::FollowTail to IM log lines to you. Changes since 0.02: - Added throttle argument to prevent rate problems with server - Added sleep 0.1 statements as a hack to interact better with Net::OSCAR (these will get removed upon the next release of Net::OSCAR) Enjoy, Dan
Re: Problems sending to stdin of POE::Wheel::Run-spawned process
I briefly considered whether the wheel should guarantee flushing on
shutdown, but I decided against it. Sometimes people may want to shut
down a client regardless of the input waiting for it.
Maybe the shutdown methods need flush/immediate options?
That would definitely be convenient. Would it be as simple as this? It
works with the test case I sent earlier. I'll re-submit it with a doc patch
if it looks ok.
--- Run.pm Mon Nov 15 23:31:17 2004
+++ Run.pm.new Thu Dec 23 15:28:09 2004
@@ -859,8 +859,13 @@
# Shutdown the pipe that leads to the child's STDIN.
sub shutdown_stdin {
- my $self = shift;
+ my ($self, %args) = @_;
+
return unless defined $self-[HANDLE_STDIN];
+
+ if ($args{flush}) {
+ $self-[DRIVER_STDIN]-flush($self-[HANDLE_STDIN]);
+ }
$poe_kernel-select_write($self-[HANDLE_STDIN], undef);
Dan
Re: Problems sending to stdin of POE::Wheel::Run-spawned process
Ah. Fascinating. Thanks! Whaddya say I submit a doc patch mentioning that (a) it's up to the user to flush the buffer (if they want to) when using shutdown_stdin and (b) get_driver_out_octets is a handy part of the process. For that matter, should I take a stab at documenting get_driver_out_octets and get_driver_out_messages in POE::Wheel::Run (or POE::Wheel?) since they aren't mentioned anywhere? Dan On 12/21/04 9:57 PM, Rocco Caputo [EMAIL PROTECTED] wrote: On Tue, Dec 21, 2004 at 08:39:53PM -0800, Dan McCormick wrote: So consider this: I have a stream of data, which I'm sending to the POE::Wheel::Run process. At an arbitrary time I can get a signal that the stream has ended, at which point I want to shutdown the process's STDIN. If I knew the last bit of data sent was going to be the last bit of data, I could set a flag as I send it to the POE::Wheel::Run process, and then the next StdinEvent could call stdin_shutdown. But I don't know which bit of data is going to be the last. So when I receive the signal to shutdown STDIN, I don't know if the STDIN buffer is flushed or not (do I?). I can set a flag, but if it's already flushed, the StdinEvent will never get called. It seems I need a way to tell if there's anything pending in the buffer. Checking $wheel-get_stdin_filter-get_pending() seems like a good bet, but doesn't seem to be working -- it always seems to return false, even though if I then call stdin_shutdown the data never arrives at my process. Any suggestions? Am I missing something? Yep! The child's STDIN is the wheel's otput buffer. Whenever you put() something to a wheel, you're writing whole things (where thing is defined by the filter you're using). Since things are sent whole, filters don't need to buffer them for output. Rather, they convert them and return them right away. The serialized things are sent to the driver for flushing in a little while. Anyway, most wheels have get_driver_out_octets() methods that tell you how many octets are waiting in the driver to be flushed. I think that's what you're looking for.
Re: Problems sending to stdin of POE::Wheel::Run-spawned process
Hmmm. Interesting.
So consider this:
I have a stream of data, which I'm sending to the POE::Wheel::Run process.
At an arbitrary time I can get a signal that the stream has ended, at which
point I want to shutdown the process's STDIN.
If I knew the last bit of data sent was going to be the last bit of data, I
could set a flag as I send it to the POE::Wheel::Run process, and then the
next StdinEvent could call stdin_shutdown. But I don't know which bit of
data is going to be the last.
So when I receive the signal to shutdown STDIN, I don't know if the STDIN
buffer is flushed or not (do I?). I can set a flag, but if it's already
flushed, the StdinEvent will never get called.
It seems I need a way to tell if there's anything pending in the buffer.
Checking $wheel-get_stdin_filter-get_pending() seems like a good bet, but
doesn't seem to be working -- it always seems to return false, even though
if I then call stdin_shutdown the data never arrives at my process.
Any suggestions? Am I missing something?
Thanks,
Dan
On 12/21/04 3:18 PM, Rocco Caputo [EMAIL PROTECTED] wrote:
On Mon, Dec 20, 2004 at 10:44:23PM -0800, Dan McCormick wrote:
Shouldn't the code below print 1, 2, 3, 4 on separate lines to the file
/tmp/test.txt?
If I comment out lines 537-538 of POE::Wheel::Run.pm, namely:
$poe_kernel-select_pause_write($self-[HANDLE_STDIN])
unless ($self-[OCTETS_STDIN]);
... things work as (I) expected. Some cursory debugging suggests POE isn't
flushing the buffer when the state returns, as the docs indicate.
They don't quite work the way I expect, but I think you'll agree that
teh problem's over in shutdown_stdin() (around line 872):
# Shutdown the pipe that leads to the child's STDIN.
sub shutdown_stdin {
my $self = shift;
return unless defined $self-[HANDLE_STDIN];
$poe_kernel-select_write($self-[HANDLE_STDIN], undef);
eval { local $^W = 0; shutdown($self-[HANDLE_STDIN], 1) };
close $self-[HANDLE_STDIN] if $@;
}
The problem's fairly obvious. Your test case calls put() to prime the
STDIN buffer, then it calls shutdown_stdin() to close STDIN.
Unfortunately, the wheel also stops select_write() for the handle.
That prevents the buffer from ever being flushed.
The proper thing to do is perhaps to set a shutdown flag if there is
pending input for the child process, and do the actual shutdown when
the input has flushed.
Also, even with the commented-out lines, it looks like I still need the
'doit' and 'shutdown' events to be separate (i.e., combining everything into
the _start event doesn't work). Is that behavior intentional?
I think it's creating a race condition where your expected behavior
occurs. It seems to be working only by coincidence.
Problems sending to stdin of POE::Wheel::Run-spawned process
Hi,
Shouldn't the code below print 1, 2, 3, 4 on separate lines to the file
/tmp/test.txt?
If I comment out lines 537-538 of POE::Wheel::Run.pm, namely:
$poe_kernel-select_pause_write($self-[HANDLE_STDIN])
unless ($self-[OCTETS_STDIN]);
... things work as (I) expected. Some cursory debugging suggests POE isn't
flushing the buffer when the state returns, as the docs indicate.
This behavior holds for the following tested systems, all running POE
0.3003:
Mac OS X Perl 5.8.1
Redhat 7.3 Perl 5.6.1
Redhat 9.0 Perl 5.8.0
Also, even with the commented-out lines, it looks like I still need the
'doit' and 'shutdown' events to be separate (i.e., combining everything into
the _start event doesn't work). Is that behavior intentional?
Thanks,
Dan
#!/usr/bin/perl
use strict;
use POE qw(Wheel::Run);
POE::Session-create(
package_states = [
main = [qw( _start _stop doit shutdown err stderr close)]
]
);
$poe_kernel-run();
sub _start {
my $heap = $_[HEAP];
$heap-{wheel} = POE::Wheel::Run-new(
Program = '/bin/cat /tmp/test.txt',
StderrEvent = stderr,
ErrorEvent = err,
CloseEvent = close,
);
$_[KERNEL]-yield(doit);
}
sub doit {
my ($kernel, $heap) = @_[KERNEL, HEAP];
print Created wheel . $heap-{wheel}-ID . \n;
print Sending...\n;
$heap-{wheel}-put( 1 );
$heap-{wheel}-put( 2 );
$heap-{wheel}-put( 3 );
$heap-{wheel}-put( 4 );
$kernel-yield('shutdown');
}
sub shutdown {
my $heap = $_[HEAP];
print Shutting down...\n;
$heap-{wheel}-shutdown_stdin();
}
sub _stop {
}
sub stderr {
my ($input, $wheel_id) = $_[ARG0]..$#_;
print stderr from wheel $wheel_id: $input\n;
}
sub err {
my ($input, $wheel_id) = $_[ARG0]..$#_;
print Error from wheel $wheel_id: $input\n;
}
sub close {
my ($wheel_id) = $_[ARG0]..$#_;
print Close from wheel $wheel_id\n;
}
Re: AIM/OSCAR Component?
It has been lurking in the deeper recesses of my computer, but here, at last, it sees the light of day: http://www.codeop.com/POE-Component-OSCAR-0.01.tar.gz It's also working itself through the CPAN process slowly but surely. Dan On Thu, 2004-04-01 at 13:51, Rocco Caputo wrote: Back in August, Dan McCormick said he had written (and documented!) POE::Component::Net::OSCAR. There's call for such a beast if it still exists. Has anyone seen it lately? -- Rocco Caputo
Re: fork and talking to parent
Hi Jay,
Have you played with POE::Wheel::Run? It seems suited to what you're
doing: Wheel::Run spawns child processes and establishes non-blocking,
event based communication with them.
Give that a try and let us know how you fare.
Dan
On Thu, 2003-12-04 at 19:09, Jay Strauss wrote:
Hi,
I have this process that forks, the child opens up a socket and listens (in
a while loop).
When the child reads something, it calls the appropriate sub to handle the
message (tickPrice for example). Once I'm in tickPrice(), I'd like to send
some data back to the parent.
1) is the a proper use of POE.
I figured I'd use POE::Component::Client::TCP in the child and
POE::Component::Server::TCP in the parent. After looking at the docs for
POE::Component::Client::TCP, and the cookbook. I don't see how I could send
a message back to the parent.
I know there is:
$heap-{server}-put(@things_to_send);
But I don't know how I'd get the value of $heap into my subroutine? Since
there was no POE event.
Thanks
Jay
Re: Beginner's Question - Tk and POE
Hi Tom,
POE uses the concept of sessions, which are similar to threads.
POE::Component::Client::TCP (hereafter Poco::TCP) spawns a new session,
which is distinct from the main session of the rest of your app. Each
session has its own distinct heap.
So, first off, wrt your application, saying...
$_[HEAP]-{server}=POE::Component::Client::TCP-new
... doesn't do what you think it does. As far as I know PoCo::TCP
returns a reference to a session, not a wheel (i.e., not something you
can call a put method on, as you do later).
Just take out that initial $_[HEAP]-{server}=. (It's not doing any
harm, but it's misleading you.)
Further, the heap you refer to in that line is actually different than
the heap that PoCo::TCP uses.
The PoCo::TCP states that you set up and call, like handle_connect,
handle_connect_error, all get passed PoCo::TCP's heap.
cv_send, however, gets passed the main session's heap, which doesn't
have a {server} attribute in it.
If you want handle_send to be able to access PoCo::TCP's heap, just do
$web_heap = $kernel-alias_resolve('web')-get_heap();
$web_heap-put($input_record\n);
(Note, though, that you misspelled Alias in your call to PoCo::TCP's
constructor. Note, too, that you're passing a send paramater to
PoCo::TCP -- with the line send = \handle_send, -- which doesn't do
anything, because PoCo::TCP doesn't take send as an argument.)
Starting out with POE involves a lot of thrashing around like this --
don't worry, you'll get used to it. I've found that things get very
confusing when you're dealing with more than one session within a single
file. I usually create package files with subroutines for each session
to simplify things.
Dan
On Wed, 2003-12-03 at 14:55, Phillips Thomas E Contr AFMC/ITON wrote:
New to POE, so please be gentle.
Using Tk and POE to write a client. Have read that there are some issues
with Tk, POE and ActiveStates Perl on Win32; however, I think my problems
are more basic. I am using the TkClient example from the Cookbook as the
basis of my Tk interface.
I have been able to successfully connect to a server, display status
messages in the Tk windows and receive input from the server. I cannot send
info to the server. Would like to tie the 'Request Update' button to the
'send' event. How do I do this?
vitals:
POE = v0.27
OS=Windows 2000
ActiveStates Perl = v 5.8.0 Build 806
--- client.pl -
#!/perl/bin/perl
use warnings;
use strict;
use Tk;
use POE;
use POE::Filter::Stream;
use POE::Component::Client::TCP;
local $| = 1;
my $svr = localhost; # Server's ip address
my $port = 32080; # Server's port which app is running on.
my $status = Starting point...;
# Create the session that will drive the user interface.
POE::Session-create
( inline_states =
{ _start = \ui_start,
ct_start = sub {
$_[HEAP]-{server}=POE::Component::Client::TCP-new
( Alais = 'web',
RemoteAddress = $svr,
RemotePort = $port,
Connected = \handle_connect,
ConnectError = \handle_connect_error,
Disconnected = \handle_disconnect,
ServerInput= \handle_server_input,
ServerError= \handle_server_error,
ServerFlushed = \handle_server_flush,
send = \handle_send,
); $status = Connected; },
cv_send = \handle_send,# This doesnt work, but
when I push the request update button I come here.
}
);
# Run the program until it is exited.
$poe_kernel-run();
sub ui_start {
my ( $kernel, $session, $heap ) = @_[ KERNEL, SESSION, HEAP ];
$poe_main_window-Label( -text = Counter )-pack;
$heap-{counter_widget} =
$poe_main_window-Label( -textvariable = \$status )-pack;
$poe_main_window-Button
( -text = Connect,
-command = $session-postback(ct_start)
)-pack;
$poe_main_window-Button
( -text = Request Update,
-command = $session-postback(cv_send) #
subst 'send' for 'cv_send' doesnt work
)-pack;
$poe_main_window-Button
( -text = Disconnect,
-command = $session-postback(Disconnect)
)-pack;
$status=Press Connect Button;
}
sub handle_start {
my @args = @_[ARG0..$#_];
}
sub handle_connect {
$status = 2Connected;
}
sub handle_send {
my ($kernel, $heap,$input_record) = @_[KERNEL, HEAP, ARG0];
chomp $input_record;
print Server send $input_record\n;
$_[HEAP]-{server}-put($input_record\n) ; # This doesnt work
}
sub handle_connect_error {
my ( $kernel, $heap, $syscall_name, $error_number, $error_string) =
@_[KERNEL, HEAP,ARG0, ARG1, ARG2];
$status = I had problems.\n$syscall_name\n
$error_number\n$error_string;
}
sub
$session-callback() return value
Actually, whaddya say we return the actual return value of the callback instead of POSTBACK_RETVAL? As you know, POSTBACK_RETVAL is hard coded to zero for postback, but looking over a Gtk mailing list, someone notes: Event signals return a boolean value. Gtk uses this value to decide whether to propagate an event upwards from a child widget onto its parent. If an event handler returns true, it means that the event has been handled and Gtk will not propagate it upwards. If it returns false, it means that the event has not been handled and will be propagated. Thus allowing the user to decide what gets handed back to Gtk could be handy. Dan
Re: $session-callback
On Sat, 2003-08-23 at 19:22, Rocco Caputo wrote: On Sat, Aug 23, 2003 at 04:04:26PM -0400, Dan McCormick wrote: (Which raises the question: has there been talk of a synchronous $session-callback()?) Not until today. :) If you look at the postback() code in POE::Session, it should be straightforward to build a callback() version. Copy, paste, s/post/call/ throughout the new sub. Test it against Net::OSCAR, and submit a patch if it works. A documentation patch would also be appreciated. 'Kay, I whipped it up and it seems to be working. I wasn't sure what to do with the various auxiliary bits, though. Would you like me to create a CALLBACK_RETVAL, POE::Session::Callback::DESTROY method, and %callback_parent_id hash, and call refcount_increment with a 'callback' identifier, or just use the the postback versions of those? Of course, since it's synchronous, I'm pretty sure inc'ing and dec'ing the refcounts shouldn't matter, so I could also just take those bits out. Dan
Re: PoCo::Net::OSCAR -- solved!
On Fri, 2003-08-22 at 17:38, Rocco Caputo wrote:
On Fri, Aug 22, 2003 at 03:09:59PM -0400, Dan McCormick wrote:
[...]
fileno() returning undef is a great way to check for a closed file.
Your problem is you're ignoring it. Try this instead:
unless (defined fileno $handle) {
$kernel-select($handle);
return;
}
That'll stop watching closed sockets.
The trick is that by this point, $handle is invalid. If ASSERT_USAGE is
on, POE dies when you try that select. Otherwise, it ignores it, but
seems to keep watching the invalid filehandle. (That is, rd_ok and
wr_ok keep getting called, but fileno($socket) returns undef.)
My guess is that Net::OSCAR hasn't cleaned up after the closed socket
yet. I would need to read the source/documentation on it to determine
how to force that.
I think you're onto something. Here's what seems to be going on:
Net::OSCAR creates a connection upon signon. This socket gets assigned
a fileno -- say, 3. When we set POE to select on this socket,
everything is peachy.
After signon, Net::OSCAR drops that connection, thus freeing up fileno
3. POE, however, does not seem to be aware of this. Net::OSCAR then
immediately establishes a new connection, which also uses fileno 3.
The two problems at this point seem to be:
1) POE keeps watching a socket that no longer exists. To stop watching
the socket, POE needs a valid socket in the $kernel-select($socket)
call, but we don't have a valid socket to give it.
2) If we try to watch the new socket, POE complains that it can't watch
the same handle in the same mode 2+ times because (I think) it's
confusing the old fileno 3 with the new fileno 3.
To support this, I added the line
$main::poe_kernel-select( $connection-{socket} );
in Net::OSCAR immediately before it disconnects the login socket
(Net::OSCAR::Callbacks line 521) and, afterwards, everything worked
perfectly.
Furthermore, tracing through POE's guts, when we call
$kernel-select($socket) in rd_ok or wr_ok with an invalid socket, it
ends up at _data_handle_remove, in which the second line that calls
fileno($handle) returns undef. Meanwhile, a look at %kr_filenos
indicates that fileno 3 is still there.
So somehow we need (a) Net::OSCAR to alert POE that it's closing the
socket or (b) POE to stop watching an invalid filehandle.
Happily, there's a Net::OSCAR callback that we can set up to alert us
before it closes a connection. The only hitch is that using a
$session-postback seems to give us the socket too late --
$connection-{socket} is already undef.
But if I make it a straight subroutine call, everything works fine.
(Which raises the question: has there been talk of a synchronous
$session-callback()?)
In any case, the PoCo::Net::OSCAR module is now fully functional and
perhaps even well-coded. I'll post it on the Wiki shortly.
Thanks for the guidance, Rocco.
Dan
Re: PoCo::Net::OSCAR
Thanks, Rocco. I appreciate the help.
I've been playing with your solution and it seems to work ok for the
login portion of the interaction, but not the hand off to BOS (whatever
that is -- I assume it's just the chat server).
Here's what happens:
Net::OSCAR interacts with the login server, then closes the connection.
At this point its debug code shows this:
login: Got authorization response.
login: Login OK - connecting to BOS
login: Closing.
BOS: Connecting to 205.188.8.47:5190.
At that point, the code you suggested dies with:
Can't call method process_one on an undefined value at
POE/Component/OSCAR.pm
... which is from the process_one line in wr_ok.
So I added some debug code to wr_ok, like so:
my $fileno = fileno($socket);
print in write ok: . join(', ', $fileno, $socket-opened,
$socket-error, $socket-clearerr, join(',', $socket-stat)) . \n;
which at this stage yields
in write ok: , , -1, -1,
i.e., the socket appears to be invalid/non-existent.
Adding a simple
return unless $fileno;
avoids the error, but just causes the app to hang, as both wr_ok and
rd_ok are repeatedly called with an invalid socket.
During all this, ex_ok is never called, though it should be upon the
disconnect, right?
Also, if I set an event to look at all the Oscar connections a few
seconds into all this, there's still only one, and it's fileno is the
same as that of the original socket. Can something happen so that a
socket and its fileno become dissociated?
I can post the code if you're interested, but completely understand if
you've got bigger fish to fry.
Thanks,
Dan
On Thu, 2003-08-21 at 21:10, Rocco Caputo wrote:
On Thu, Aug 21, 2003 at 04:12:34PM -0400, Dan McCormick wrote:
Howdy,
If no one's released a PoCo::Net::OSCAR (i.e. the public face of AOL's
IM), I've got one to offer.
However, I was hoping for a bit of feedback first, because I'm not sure
I've gone about it in the best way. The Net::OSCAR module is very nice
in that it can use other event loops. The only hitch is that it thinks
in terms of filenos and it looks like POE thinks in terms of sockets and
handles. I'm not too well-versed in this area, but after a bit of trial
and error, I came up with this:
# sign on, and set up POE to monitor all the connections
$_[HEAP]-{oscar}-signon( %args );
[...]
This works fine, but it seems a bit heavy on the selects. Is there a
better way?
It looks like Net::OSCAR has a findconn() function that will find a
connection based on a socket's file descriptor. Generating file
descriptors from socket handles is a lot easier than going the other
way: just call fileno() on them.
This code (untested!) simulates Net::OSCAR::process_connections() on one
connection at a time.
The only shame is that Net::OSCAR::findconn() does a grep on all the
connections to find the matching one. A hash of (fileno = connection)
pairs would be nice there.
foreach my $conn (@{ $heap-{oscar}-{connections} }) {
$kernel-select($connection-{socket}, 'rd_ok', 'wr_ok', 'ex_ok');
}
sub rd_ok {
my ($heap, $socket) = @_[HEAP, ARG0];
my $conn = $heap-{oscar}-findconn(fileno($socket));
$conn-process_one(1, 0);
}
sub wr_ok {
my ($heap, $socket) = @_[HEAP, ARG0];
my $conn = $heap-{oscar}-findconn(fileno($socket));
$conn-process_one(0, 1);
}
sub ex_ok {
my ($heap, $socket) = @_[HEAP, ARG0];
my $conn = $heap-{oscar}-findconn(fileno($socket));
$kernel-select($socket); # stop the socket from POE
$connection-{sockerr} = 1;
$connection-disconnect();
}
Good luck.
PoCo::Net::OSCAR
Howdy,
If no one's released a PoCo::Net::OSCAR (i.e. the public face of AOL's
IM), I've got one to offer.
However, I was hoping for a bit of feedback first, because I'm not sure
I've gone about it in the best way. The Net::OSCAR module is very nice
in that it can use other event loops. The only hitch is that it thinks
in terms of filenos and it looks like POE thinks in terms of sockets and
handles. I'm not too well-versed in this area, but after a bit of trial
and error, I came up with this:
# sign on, and set up POE to monitor all the connections
$_[HEAP]-{oscar}-signon( %args );
for my $connection (@{ $_[HEAP]-{oscar}-{connections} }) {
next unless $connection-{socket};
$_[KERNEL]-select( $connection-{socket}, 'process', 'process',
'process' );
}
[... below ... ]
sub process {
while (1) {
my ($rin, $win) = $_[HEAP]-{oscar}-selector_filenos();
my $ein = $rin | $win;
my $nfound = select($rin, $win, $ein, .01);
last unless $nfound;
$_[HEAP]-{oscar}-process_connections( \$rin, \$win, \$ein );
}
}
This works fine, but it seems a bit heavy on the selects. Is there a
better way?
Thanks,
Dan
Re: problems using package methods...
Hi Josh,
If Ping.pm is a separate file, you need to use POE to import the
KERNEL, HEAP, etc. constants. Try that and see if things improve.
Dan
Josh wrote:
I am having a strange problem w/package methods not seeming to work
properly, at least as far as I understand them. This is my first POE
program, it is a simple program that pings some hosts using
POE::Component::Client::Ping. I am trying to put the event handlers related
to pinging in their own package. If anyone has any ideas or suggestions I
would really appreciate it, bc I have read all the docs and online resource
and this is erally starting to bake my noodle. Example output and the code
is below.
-josh
I first wrote the program using inline handlers w/all the coderefs in the
same file. running this works fine:
# perl daemon.pl
START KERNEL
216.33.69.110 0.0165859460830688
216.33.68.131 0.0180959701538086
216.33.69.33 0.0192290544509888
216.33.68.132 0.0205649137496948
216.33.66.190 0.0219370126724243
216.33.66.150 0.0233149528503418
64.37.201.22 0.0246679782867432
216.33.69.110 : NO RESPONSE
216.33.68.131 : NO RESPONSE
216.33.69.33 : NO RESPONSE
216.33.68.132 : NO RESPONSE
216.33.66.190 : NO RESPONSE
216.33.66.150 : NO RESPONSE
64.37.201.22 : NO RESPONSE
STOP sess 3
STOP KERNEL
However, if I move the handlers out of this file to a package and change the
Session's event mapping to use package methods, none of my handlers get
invoked (w/assertions and debuggin this time):
START KERNEL
sg POE::Kernel is polling for signals at 1056131081.00576 at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 2711.
sg POE::Kernel has no child processes at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 2770.
sg POE::Kernel will poll again after a delay at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 2790.
STOP sess 3
sg dispatching ET_SIGNAL (IDLE) to session raef-3ef34807a03d
(POE::Kernel=ARRAY(0x8304598)) at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 2407.
sg propagating compatible signal (IDLE) to session 2 (pinger) at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 2451.
sg propagated to session 2 (pinger) at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 2463.
sg stopping signaled session session 2 (pinger) at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 703.
sg stopping signaled session session raef-3ef34807a03d
(POE::Kernel=ARRAY(0x8304598)) at
/usr/local/lib/perl5/site_perl/5.8.0/POE/Kernel.pm line 703.
STOP KERNEL
Here is the program and the package:
use warnings;
use strict;
sub POE::Kernel::ASSERT_DEFAULT () { 1 }
sub POE::Kernel::TRACE_SIGNALS () { 1 }
use POE qw( Component::RRDTool Component::Client::Ping);
use cwexodus::Device;
use Ping;
sub refresh_index {
my ($kern, $heap) = @_[KERNEL, HEAP];
my $d = new cwexodus::Device;
my $dev = $d-getDevices();
my $i = 0;
foreach my $devid (keys %$dev) {
$d-setFocus($devid);
my $a = $d-getAttrs();
if (($a-{ipaddresses} =~ /^([0-9]{1,3}\.){3}[0-9]{1,3}$/))
{
$a-{id} = $devid;
$heap-{deviceByIp}-{qq($a-{'ipaddresses'})} = $a;
$heap-{deviceById}-{$devid} = $a;
$heap-{deviceByName}-{qq($a-{'name'})} = $a;
$i++;
}
}
$heap-{deviceNum} = $i;
}
sub schedule_start {
my ($kern, $heap, $sess) = @_[KERNEL, HEAP, SESSION];
print START sess . $sess-ID . \n;
$heap-{deviceById} = {};
$heap-{deviceByIp} = {};
$heap-{deviceByName} = {};
$heap-{deviceNum} = 0;
$kern-yield('refresh_index');
$kern-yield('ping_start');
}
sub schedule_stop {
my ($sess) = $_[SESSION];
print STOP sess . $sess-ID . \n;
}
sub _default {
print Default caught an unhandled $_[ARG0] event.\n;
print The $_[ARG0] event was given these parameters:
@{$_[ARG1]}\n;
return 0 ;
}
# COMPONENTS
POE::Component::Client::Ping-spawn
( Alias = 'pinger',# The component's name will be pinger.
Timeout = 5,# The default ping timeout.
);
# SESSIONS
POE::Session-create(
inline_states = {
_start = \schedule_start,
_stop = \schedule_stop,
refresh_index = \refresh_index,
_default = \_default,
},
package_states = [
Ping = [qw(ping_start pong)],
],
);
print START KERNEL\n;
POE::Kernel-run();
print STOP KERNEL\n;
# HERE IS THE Ping.pm PACKAGE file
package Ping;
sub ping_start {
my ($kernel, $heap) = @_[KERNEL, HEAP];
foreach my $ip (keys %{$heap-{deviceByIp}}) {
conditionally using ASSERT_STATES
Howdy,
This is more of a Perl question, but since it's POE-related...
How do you conditionally turn on something like ASSERT_STATES?
I'd like to do something like...
if ($TEST_MODE) {
sub POE::Kernel::ASSERT_STATES () { 1 }
}
use POE;
but of course the subroutine gets compiled regardless of $TEST_MODE.
Is there a trick around this?
Thanks,
Dan
ReadWrite wheels, InputStates, and error events
Hi, I discovered something -- not sure if it's a bug or a feature -- but it's worth noting: When using ReadWrite wheels to just send data (is there a better method?), defining an empty InputState (or, presumably, any InputState, but since we're just sending data InputState = '' will suffice) will trigger socket error events more quickly than not defining one. In my simple tests, it took two sent records over a dropped connection to trigger an error without an InputState, but with an InputState the dropped connection was detected immediately. Dan
ikc question
Hi,
I have a few IKC questions...
I'm monitoring client connections using
IKC = 'monitor',
'*' = {
register = 'client_connect'
}
When a client connects, the 'client_connect' state gets called *three*
times, each time with a different kernel alias, which will be one of
something like
hostname-3b8a4c2f5717
127.0.0.1:1234
client_kernel_name (as set by the 'name' parameter of create_ikc_client)
Is this correct behavior?
Poking around, I've found I can always get the kernel ID by using
(keys %{$sender-[OBJECT]-{self}{alias}})[0];
and the kernel name (again, as set by the create_ikc_client 'name') with
$sender-[0]-{self}{alias}{$kernel_id}-[1][0];
in the 'client_connect' state.
Then, when a client posts an event to the server, I can get the kernel
ID with
$sender-[OBJECT]{from}{kernel};
... all of which is a bit kludgy. Is there a better way? My ultimate
goal is to be able to figure out who's connecting to the server and
who's sending events to it, where 'who' is defined by the 'name'
parameter of client_ikc_client.
Thanks,
Dan
problems with $kernel-delay and Gtk - follow-up
Hi,
Below is a small app that reproduces the Gtk/delay problem. If you
comment out use Gtk, as I've done, 'go2' gets called after one second
and 'go' after 10, as you'd expect. However, if you uncomment use
Gtk, the first 'go2' takes 10 seconds to get hit.
Does anyone know anything about the Gtk event loop, or how POE interacts
with it, that could explain this behavior?
This has been tested on two Redhat Linux 7.1 systems.
Thanks,
Dan
use strict;
#use Gtk;
use Time::HiRes;
use POE;
new POE::Session (
_start = \start,
go = \go,
go2 = \go2,
);
$poe_kernel-run();
sub start {
my $kernel = $_[KERNEL];
$kernel-delay( 'go', 10 );
$kernel-delay( 'go2', 1 );
}
sub go {
print Hit , Time::HiRes::time, \n;
}
sub go2 {
print Hit2 , Time::HiRes::time, \n;
}
Original Message
Subject: problems with $kernel-delay and Gtk
Date: Wed, 15 Aug 2001 16:22:31 -0400
From: Dan McCormick [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi,
Has anyone had any problems using $kernel-delay and Gtk? In my
application, setting a delay of one second takes 15 seconds to process.
But if I take out the use Gtk statement, it works fine. I can't seem
to reproduce the code in a small snippet, so until I whittle it down
further I thought I'd see if anyone else had run into this...
Thanks,
Dan
problems with $kernel-delay and Gtk
Hi, Has anyone had any problems using $kernel-delay and Gtk? In my application, setting a delay of one second takes 15 seconds to process. But if I take out the use Gtk statement, it works fine. I can't seem to reproduce the code in a small snippet, so until I whittle it down further I thought I'd see if anyone else had run into this... Thanks, Dan
