Home > Archive > PERL POE > September 2007 > First post, new POE apprentice some doubts to clarify
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
First post, new POE apprentice some doubts to clarify
|
|
| Marcel 2007-09-18, 10:29 pm |
| Hello poe-masters!
After reading the documentation, cases, samples, and understanding a little
of the POE platform, I am dwelling with the examples at the cookbook section
of the site, learning more, and trying to figure out some problems i'm
having with the ikc_server and ikc_client example of Inter POE's Kernel
Communique.
As for now, i only get the response from ikc_server if i comment out the
line below of the client, which supresses the yield(_stop) event to the
server:
$kernel->yield('_stop');
If this line remains uncommented, all i get from issuing the client is the
line that is the output of the _stop event of the client:
~/learning_poe$ ./poe_ikc_client.pl
Finished...
~/learning_poe$
With that line commented out, issuing the execution of the client leads to:
~/learning_poe$ ./poe_ikc_client.pl
Result!
1
Result!
2
Result!
3
Result!
4
Result!
5
Result!
6
Result!
7
Result!
8
Result!
9
Result!
10
But the client never finishes, but that behaviour was expected.
At the server terminal:
~/learning_poe$ ./poe_ikc_server.pl
Someone called!
Someone called!
Someone called!
Someone called!
Someone called!
Someone called!
Someone called!
Someone called!
Someone called!
Someone called!
And the client communicates fine with the server.
Can you point me what is the problem with that example given?
Thank you in advance,
Marcel Mitsuto.
| |
| Matt Sickler 2007-09-18, 10:29 pm |
| I havn't used IKC before, but it seems that the client session closes
itself before getting any data from the server.
The
$kernel->yield('_stop');
causes the kernel to fire the current session's _stop handler. This
is bad for two reasons:
1) With this model, the client probably stops before ever getting any
data back from the server.
2) One should _NEVER_ call the predefined underscore events ( _start
_stop etc ) yourself. Bad things happen and small children cry.
I am currently learning the POE::Component::IKC module, and will
update that wiki page as soon as I can (and I learn my wiki password
:( )
Thanks for taking an interest in POE, by the way!
~ Matt
On 9/18/07, Marcel <webknowledge@gmail.com> wrote:
> Hello poe-masters!
>
> After reading the documentation, cases, samples, and understanding a little
> of the POE platform, I am dwelling with the examples at the cookbook section
> of the site, learning more, and trying to figure out some problems i'm
> having with the ikc_server and ikc_client example of Inter POE's Kernel
> Communique.
>
> As for now, i only get the response from ikc_server if i comment out the
> line below of the client, which supresses the yield(_stop) event to the
> server:
>
> $kernel->yield('_stop');
>
> If this line remains uncommented, all i get from issuing the client is the
> line that is the output of the _stop event of the client:
>
> ~/learning_poe$ ./poe_ikc_client.pl
> Finished...
> ~/learning_poe$
>
> With that line commented out, issuing the execution of the client leads to:
>
> ~/learning_poe$ ./poe_ikc_client.pl
> Result!
> 1
> Result!
> 2
> Result!
> 3
> Result!
> 4
> Result!
> 5
> Result!
> 6
> Result!
> 7
> Result!
> 8
> Result!
> 9
> Result!
> 10
>
> But the client never finishes, but that behaviour was expected.
>
> At the server terminal:
>
> ~/learning_poe$ ./poe_ikc_server.pl
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
>
> And the client communicates fine with the server.
>
> Can you point me what is the problem with that example given?
>
> Thank you in advance,
>
> Marcel Mitsuto.
>
| |
| Zack Payton 2007-09-18, 10:29 pm |
| Marcel,
Thanks for taking an interest in POE... please don't let my horrible example
deter you from reaping its' benefits. I am the author of that example and
you are completely right, it's an error on my part. The reason is that the
1..10 post statements simply put the call statements in a queue which are to
be executed at the POE kernels convenience rather than right now (for
immediate execution use call rather than post). I haven't looked closely
enough at the source however I'd bet a shiny plastic nickel that the _stop
event is prioritized and causes (as Matt indicates) the POE kernel to exit
before the "Inter Kernel Communique" occurs. I'm not sure the best way to
handle an exit on the clients behalf and this is a very interesting
question.
If we're not to call _stop directly, what is the best way to put an exit
event at the end of the queue to that all events are executed first and then
we gracefully terminate.
Thanks,
Zack
On 9/18/07, Marcel <webknowledge@gmail.com> wrote:
>
> Hello poe-masters!
>
> After reading the documentation, cases, samples, and understanding a
> little
> of the POE platform, I am dwelling with the examples at the cookbook
> section
> of the site, learning more, and trying to figure out some problems i'm
> having with the ikc_server and ikc_client example of Inter POE's Kernel
> Communique.
>
> As for now, i only get the response from ikc_server if i comment out the
> line below of the client, which supresses the yield(_stop) event to the
> server:
>
> $kernel->yield('_stop');
>
> If this line remains uncommented, all i get from issuing the client is the
> line that is the output of the _stop event of the client:
>
> ~/learning_poe$ ./poe_ikc_client.pl
> Finished...
> ~/learning_poe$
>
> With that line commented out, issuing the execution of the client leads
> to:
>
> ~/learning_poe$ ./poe_ikc_client.pl
> Result!
> 1
> Result!
> 2
> Result!
> 3
> Result!
> 4
> Result!
> 5
> Result!
> 6
> Result!
> 7
> Result!
> 8
> Result!
> 9
> Result!
> 10
>
> But the client never finishes, but that behaviour was expected.
>
> At the server terminal:
>
> ~/learning_poe$ ./poe_ikc_server.pl
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
>
> And the client communicates fine with the server.
>
> Can you point me what is the problem with that example given?
>
> Thank you in advance,
>
> Marcel Mitsuto.
>
| |
| Matt Sickler 2007-09-18, 10:29 pm |
| Zack,
The best way would be to clean up all of the things keeping the POE
Kernel alive.
In the client case, its the POE::Component::IKC::Client session. Send
it a shutdown event, and the program will clean itself up.
See the updated example I put online (
http://poe.perl.org/?POE_Cookbook/I...rnel_Communique )
On 9/18/07, Zack Payton <zpayton@gmail.com> wrote:
> Marcel,
>
> Thanks for taking an interest in POE... please don't let my horrible example
> deter you from reaping its' benefits. I am the author of that example and
> you are completely right, it's an error on my part. The reason is that the
> 1..10 post statements simply put the call statements in a queue which are to
> be executed at the POE kernels convenience rather than right now (for
> immediate execution use call rather than post). I haven't looked closely
> enough at the source however I'd bet a shiny plastic nickel that the _stop
> event is prioritized and causes (as Matt indicates) the POE kernel to exit
> before the "Inter Kernel Communique" occurs. I'm not sure the best way to
> handle an exit on the clients behalf and this is a very interesting
> question.
>
> If we're not to call _stop directly, what is the best way to put an exit
> event at the end of the queue to that all events are executed first and then
> we gracefully terminate.
>
> Thanks,
> Zack
>
> On 9/18/07, Marcel <webknowledge@gmail.com> wrote:
>
| |
| Zack Payton 2007-09-18, 10:29 pm |
| What happens if the IKC requests don't finish in less than five seconds, say
due to network delay? Or if you want to run forever and then call a
shutdown routine when some predetermined event happens?
On 9/18/07, Matt Sickler <crazyfordynamite@gmail.com> wrote:
>
> Zack,
> The best way would be to clean up all of the things keeping the POE
> Kernel alive.
> In the client case, its the POE::Component::IKC::Client session. Send
> it a shutdown event, and the program will clean itself up.
> See the updated example I put online (
> http://poe.perl.org/?POE_Cookbook/I...rnel_Communique )
>
> On 9/18/07, Zack Payton <zpayton@gmail.com> wrote:
> example
> and
> the
> are to
> closely
> _stop
> exit
> to
> then
> Kernel
> the
> the
> the
> leads
>
| |
| Matt Sickler 2007-09-18, 10:29 pm |
| Then you will get no data. You will just tell the IKC client to
shutdown as part of your cleanup routine.
On 9/18/07, Zack Payton <zpayton@gmail.com> wrote:
> What happens if the IKC requests don't finish in less than five seconds, say
> due to network delay? Or if you want to run forever and then call a
> shutdown routine when some predetermined event happens?
>
>
> On 9/18/07, Matt Sickler <crazyfordynamite@gmail.com> wrote:
> http://poe.perl.org/?POE_Cookbook/I...rnel_Communique
> )
> example
> and
> the
> are to
> closely
> _stop
> exit
> to
> then
> Kernel
> the
> the
> the
> leads
>
>
| |
| Marcel 2007-09-19, 7:29 pm |
| Nice to have all these kind replies,
I am programming in perl for almost three years now, having successfully
implemented some systems that interacts with Nagios, Syslog-ng, Cacti, SNMP,
SEC, and so on... It's a big ISP here in Brazil, and we are researching for
means to scale our monitoring system to fit the growth of our
infrastructure. It has a prevision of growth of 200% in the next 2 years,
and I'm worried about all scripts that glue all those mentioned systems
together. They're all perl scripts that were assembled to fit our needs and
the security policies that kind of difficult some system engineering
strategies, but they're all work fine. Beyond monitoring systems, I'm
responsible for audience auditing, having almost 1k webservers divided into
farms, there is a need of agile statistics over apache's logfiles analysis,
it's becoming a nightmare to manage.
My goal in learning POE is that I'm inclined to merge the monitoring agent
with the backup agent and as for the audience metrics, create an agent that
will collect and summarize all metrics I need, all within a POE distributed
agent that will aggregate all those roles by this event-driven platform,
because I see that if all events were mapped, the maintenance and the
managing of those roles will become far more easy and manageable.
So I'm interested in using POE's framework to sy min, data gathering,
apache's log analysis and network/systems event correlation.
So far I'm just picking all code snipets I've put my eyes on and tweaking a
little with'em to get familiarized with the implementation shift I'll need
to understand before getting my feet wet and design that super agent.
Thank you all for your kind attention and time,
Marcel Mitsuto
On 9/19/07, Matt Sickler <crazyfordynamite@gmail.com> wrote:
>
> Then you will get no data. You will just tell the IKC client to
> shutdown as part of your cleanup routine.
>
> On 9/18/07, Zack Payton <zpayton@gmail.com> wrote:
> say
> example
> that
> which
> (for
> to
> way
> exit
> and
> a
> cookbook
> i'm
> out
> to
> client is
>
| |
| Bill Nash 2007-09-19, 7:29 pm |
|
POE can absolutely do all of the things you're talking about. When you
start talking about issues of scale, however, POE may be too heavy or not
efficient enough to meet your needs. For your device performance
monitoring, you may be better served with an snmp agent (read: net-snmp)
on each server, handling your local collection more efficiently, and using
POE to collect and monitor that performance. I don't recommend a local
agent written in POE, unless you're doing some seriously custom craziness
that needs that kind of flexibility.
POE's memory footprint can and will be a concern as you scale. I've done
some great things with POE that I later revamped to remove POE's overhead
as a restrictive element. At some point, you'll be making the engineering
decision of convenience versus efficiency. I've got over 5k servers in my
network, I'd rather leave their resources for production use than consume
them with POE/perl's memory footprint, which is occasionally much larger
than it needs to be.
- billn
On Wed, 19 Sep 2007, Marcel wrote:
> Nice to have all these kind replies,
>
> I am programming in perl for almost three years now, having successfully
> implemented some systems that interacts with Nagios, Syslog-ng, Cacti, SNMP,
> SEC, and so on... It's a big ISP here in Brazil, and we are researching for
> means to scale our monitoring system to fit the growth of our
> infrastructure. It has a prevision of growth of 200% in the next 2 years,
> and I'm worried about all scripts that glue all those mentioned systems
> together. They're all perl scripts that were assembled to fit our needs and
> the security policies that kind of difficult some system engineering
> strategies, but they're all work fine. Beyond monitoring systems, I'm
> responsible for audience auditing, having almost 1k webservers divided into
> farms, there is a need of agile statistics over apache's logfiles analysis,
> it's becoming a nightmare to manage.
>
> My goal in learning POE is that I'm inclined to merge the monitoring agent
> with the backup agent and as for the audience metrics, create an agent that
> will collect and summarize all metrics I need, all within a POE distributed
> agent that will aggregate all those roles by this event-driven platform,
> because I see that if all events were mapped, the maintenance and the
> managing of those roles will become far more easy and manageable.
>
> So I'm interested in using POE's framework to sy min, data gathering,
> apache's log analysis and network/systems event correlation.
>
> So far I'm just picking all code snipets I've put my eyes on and tweaking a
> little with'em to get familiarized with the implementation shift I'll need
> to understand before getting my feet wet and design that super agent.
>
> Thank you all for your kind attention and time,
>
> Marcel Mitsuto
>
> On 9/19/07, Matt Sickler <crazyfordynamite@gmail.com> wrote:
>
|
|
|
|
|