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 - [email protected]


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