Sorry - sending this again without attachments.... Yes - I have verified that we have the same problem with the latest version of POE.
Upon distilling the problem down, I've discovered that it's actually some sort of interaction with Proc::Daemon (which we use to daemonize the parent process...) and POE. We've been using this module for daemonization for as long we we've been using POE and it didn't exhibit problems with earlier versions of POE. I've created a snippet here: http://snipt.org/kgoZ that reproduces the problem. If you comment out the Proc::Daemon::Init call at the beginning and let it run in the foreground, the problem does not occur. If you uncomment it, then you should see that the master process spikes on the CPU. I'm guessing the fact the Daemon::Init closes some filehandles confuses POE. Please let me know if you have any advice about how to make these modules play better together. Thanks, Mike Ellery -----Original Message----- From: Ellery, Michael [mailto:mell...@websense.com] Sent: Thursday, September 02, 2010 9:12 AM To: Rocco Caputo; POE Mailing List Subject: RE: unfortunate behavior after upgrading POE I'm pretty sure we've tried with the latest release (from CPAN) and had the same issue, but I will confirm. JSON.pm is loaded by our script, so I think that's where the filehandle comes from. Somehow a filehandle value of 4 (which happens to correspond to the JSON.pm library in our particular process...) is getting into the select list. All the other file descriptors in the select list are sockets, so the one to the JSON.pm file is either because it just happens to have a magic value or it is the lowest numbered open filehandle in the process. Either way, that one shouldn't be in the select list, it seems to me and I'm not sure how it's getting in the list. I will see about creating a simple test case. Thanks, Mike Ellery -----Original Message----- From: Rocco Caputo [mailto:rcap...@pobox.com] Sent: Wednesday, September 01, 2010 8:51 PM To: POE Mailing List Subject: Re: unfortunate behavior after upgrading POE Have you tried with the latest POE release? 1.284 is seven releases behind current, and there have been at least two signals-related fixes since. If the problem persists with the latest release, I would appreciate a small, self-contained test case. This sounds like a nasty bug, and I'd like to fix it if I can. First, however, I need to see it breaking so I can track down the problem. The filehandle to JSON.pm is peculiar. POE doesn't mention JSON at all, so I wonder where the filehandle came from. 1) macbookpoe:~% cd projects/poe/poe 1) macbookpoe:~/projects/poe/poe% ack JSON 1) macbookpoe:~/projects/poe/poe% ack -ai JSON 1) macbookpoe:~/projects/poe/poe% -- Rocco Caputo - rcap...@pobox.com On Sep 1, 2010, at 13:28, Ellery, Michael wrote: > Hello, > > We use POE to manage a group of child processes doing processing in > our system, using the POE::Wheel::Run plugin. > > We recently upgraded our version of POE from 0.9989 to 1.284 and > noticed a dramatic change in the performance of the system. With the > older version of POE, the child processes consumed most of the CPU - > which is expected since they do all the processing. With the newer > version of POE, however, we notice that the parent process (the POE > session manager) consumes all the CPU and starves the children. The > parent process is really just there to manage the children, so it > should consume very little resources. > > I did some investigation with strace and noticed that the parent > process was doing select/read in a very tight loop...and the > filehandle it is trying to read from is just some perl library file > on our system (I think it was JSON.pm, but that doesn't matter..). > What's more, the list of FDs being passed to select included 10 > sockets (presumably to the child processes) AND this one file handle > to the JSON.pm module that the perl process has open. Since this > file is always ready to read, select always returns true indicating > that this file is ready to read..thus the tight loop. > > I did a little investigating in the POE code and noticed that there > is a lot of new code to handle signals differently. As an > experiment, I tried setting USE_SIGNAL_PIPE to 0 in my script before > loading POE and the behavior goes back to normal (that is, the > parent process no longer consumes all the CPU). > > So, has anyone else observed this behavior when using Wheel::Run to > manage child processes? Is my workaround a reasonable one or should > I fix this problem some other way. Based on my observations, it > seems like the fundamental problem is that POE is calling select() > with one incorrect file descriptor in its list..thus causing select > to always return immediately and causing POE to try to read from > some disk file instead of from a socket to child processes. > > Thanks, > Mike Ellery > > > Protected by Websense Hosted Email Security -- www.websense.com To report this as spam, please forward to s...@websense.com. Thank you.
