Re: POE::Component::Client::Ping.
From the error message and the common symptoms, I'd guess that
PBS_POSTBACK is going out of bounds somewhere or $old_info is not
pointing to an array that is fully initialized correctly.
That is just a guess, though.
-jeff
At 12:00 PM 10/7/2007, you wrote:
Actually, I'm chasing the exact same problem right now. I think either my
ping volume or frequency dramatically dwarfs yours, because I can trigger
a consistent failure within a few hours. =)
- billn
On Sun, 7 Oct 2007, William Fletcher wrote:
> Hi,
>
> Not too sure if this is mildly off topic, so please let me know
if it is...
>
> I have a piece of software using POE's Ping.pm component, etc...
>
> It is essentially a daemon.
>
> It works for about 10-15 days before it dies with this the following:
>
> Use of uninitialized value in subroutine entry at
/usr/local/lib/perl5/site_perl/5.8.8/POE/Component/Client/Ping.pm line 409.
> Can't use string ("") as a subroutine ref while "strict refs" in
use at
/usr/local/lib/perl5/site_perl/5.8.8/POE/Component/Client/Ping.pm line 409.
>
> # Duplicate pings? Forcibly time out the previous one.
> if (exists $heap->{addr_to_seq}->{$sender}->{$address}) {
> my $now = time();
> my $old_seq = delete $heap->{addr_to_seq}->{$sender}->{$address};
> my $old_info = delete $heap->{ping_by_seq}->{$old_seq};
> $old_info->[PBS_POSTBACK]->( undef, undef, $now, undef ); # <--- 409.
> }
>
> Any help appreciated. I'm sure the developer behind Ping.pm would
appreciate
> a fix for this, I'm just not sure how to even begin to fix this problem.
>
>
Re: Wheel::Filetail and File::Readbackwards
At 05:26 PM 10/2/2007, John R. wrote: Jonathan S. Polacheck wrote: > Hello POE group, > > I have a script that uses File::Tail to monitor the syslog file on a > Ciscoworks server. When syslog entries pass one of the grep tests, the > script reads the syslog file backwards to make sure the same event has not > been seen for at lease 30 min. [snip] I can't help with your questions, but how about keeping track of what events have been sent and then searching that? Maybe a light weight database can be used for tracking/expiring. John I agree with John, but I'm going to be a little more forward in my opinions. It's an entire waste of effort to go back through the file. It should be very straight forward to create a very simple hash that is keyed of some piece of data that identifies an "event" uniquely enough for the requirements. Then the value of the hash would be the time that you last saw that particular event. When an event passes a grep test, look up the last time from the hash. Send an email if you don't get a value, or the value is older than 30 minutes. Then update the value to the current event time. You could probably even use POE's HEAP for this, if you really wanted. At a minimum, you could use it to store the hash. There's no reason to use a database, unless you need to persist your hash across script invocations. -jeff lowrey
Re: There needs to be a book!
At 04:22 PM 9/11/2007, you wrote: None of them will generate money. I'd bet the rent on it. These books are published as credentials, not as money makers. One of the reasons for this is because all technology books are obsolete by the time they hit the shelves. I *wouldn't* buy the book, unless I personally knew the author. Even if I was going to make extensive and frequent use of the information contained therein. Books are heavy, and don't fit in my suitcase very well. Never underestimate the bandwidth of a USB flashdrive full of PDFs. And I don't use POE often enough to have any tuits to contribute to the wiki. Ianas/Al - it really seems you're the only one with enough interest in seeing a book, that you're likely the only person on the planet who can ever make it happen - for whatever reason you choose to do so. If all you're looking for is something nifty to flip through on those cold nights when you're sweating your current code and dreaming of a new source of inspiration... then now's the time to get started planning it. By the time you're done, you'll have written code that demonstrates all the inspiration you're hoping to be given from on high. And have the perspiration to show for it. If you're only looking for a way to evangelize POE in the Perl community - maybe you should start small and write up the programs you've done with POE for TPJ. Or at least get started on the process, and find out what TPJ wants in the way of an article on POE, and then add to your POE knowledge until you can produce that. There aren't really a lot of experts on POE out there, it seems. And the ones that there are, are way too busy to write books - or don't have a stake in the outcome like you do. This means that there's plenty of room on the ground floor for more experts on POE. -Jeff Lowrey
Re: POElitically incorrect question
At 12:44 PM 9/10/2005, Rich Morin wrote: My interest here is in being able to have multiple scripts inter-operate in POE-style, even if: * they are running on different machines So you'd need some way of communicating over a network between the different machines. * they are written in different languages So, you'd need some sort of common mechanism for describing data and the events/actions to be performed. I realize, of course, that they wouldn't run as efficiently as they would if they were all running under the same interpreter, but the flexibility could be really useful. So if flexibility is important, you'd like some sort of self-describing mechanism for the data and the methods... How close does POE come to this now? I can't answer this, exactly. Would it be worthwhile to put together an interface spec for other languages to build to? While there is more than one way to do it, why re-invent the wheel? This is exactly the sort of problem space that "Web Services" - which is "XML-RPC over HTTP" or "SOAP" - is trying to solve in a very large way. XML dictionaries for things like all regular transactions in the insurance industry, or the financial industry, or or or, have been created. There are still some ongoing implementation problems - shared authentication/authorization, the poor quality of HTTP as a transport, and etc - that have limited the widespread domination of WebServices across the internet. SOAP is exactly what you want. Or at least, near enough for most things. This problem space gets *really* interesting on the enterprise level. "Service Oriented Architecture" is a good buzzword these days for running an entire business as a set of distributed procedure calls, with a set of engines and transports to link them all together. If SOAP is not what you want, you probably want Grid. -Jeff
Re: namespace request (combined reply)
On Sat, Aug 27, 2005 at 05:16:06PM -0400, Rocco Caputo wrote: On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: use POE::Component::Server::MDP::POEQueueProvider; Wow, that's long, and Provider seems to overlap with Server. POE::Component::MDP::QueueProvider still has some length to it, but it sounds a lot less redundant. I assume there will be a lot of modules below POE::Component::MDP. I'm happy to move up from Server. There will in fact be several different Providers, I have two now and will, I think, shortly do one for a Thread::Queue. So I can't really use "QueueProvider" for the one I showed, since they will all be queue providers. I could go with just POEProvider. But that might be redundant... Brevity should never fall before clarity except in the service of obfuscation. Well, maybe not never.. On Sat, Aug 27, 2005 at 05:16:06PM -0400, Rocco Caputo wrote: Any objections to the namespace? Better suggestions? "Perl Messaging Service" has already been rejected... ;-) Perl Queuing Runtime Server Thingy? :) Nahh. Then I'd have to build a UniversalVarientWorkingXample... :-) At 05:26 PM 8/27/2005, Erick Calder wrote: > On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: > >> use POE::Component::Server::MDP::POEQueueProvider; is a server really a component? wouldn't POE::Server::MDP make more sense? Well, I was working from Poco::Server::SimpleHTTP... Also, I didn't want to create POE::Server myself. Happy to do it if it seems appropriate. At 05:38 PM 8/27/2005, Matt S Trout wrote: POE::Server::MessageBus POE::Component::MessageBus::Client ? MessageBus might be a little bit reaching for me. A message bus, to me, is more than just access to a MOM layer. It's a combination of a MOM layer and a schema/protocol for the conversations that occur on it. You can't do SOA without a message bus (HTTP is *not* a messaging protocol, sorry!). Also, I'm working from the intention that my code is acting as a server to the user's code. So I don't want to call my code a client. Although the whole business does get messy - as particularly with the WebSphere MQ provider I have, my code can create both a 'server' connection and a 'client' connection (and boy that was a pain, given the DWIM behavior of the MQSeries perl modules). -Jeff
namespace request - PoCo::Server::MDP
I'm in what I hope is final testing before releasing a public beta of
a set of modules that act as POE components to provide Message Driven
Perl services - in the vein of a JMS provider.
The intent is that someone will be able to do something similar to
#
use POE;
use POE::Component::Server::MDP::POEQueueProvider;
my $queue = POE::Queue::Array->new();
POE::Component::Server::MDP::POEQueueProvider->new(
'inline_states' => {
'on_message' => \&onMessage
},
'Queue' => $queue
);
POE::Kernel->run();
#someone puts stuff on $queue, and following is called for each message.
sub onMessage {
my $msg = $_[ARG0];
print $msg->{'Priority'},$msg->{'ID'},$msg->{'Payload'};
}
#
Any objections to the namespace? Better suggestions?
"Perl Messaging Service" has already been rejected... ;-)
-Jeff Lowrey
