PoCo::Client::HTTP 0.943 + run_one_timeslice = block

2011-06-18 Thread poe

Something must have changed in PoCo::Client::HTTP 0.943 leaving the
kernel blocking even if all requests have been processed.

It occurs with a component using the (evil, I know!) run_one_timeslice()
method, namely

http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/POE.pm

which then hangs in the test at

http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/t/001Basic.t

What I'm seeing is that even when the only HTTP request has been
processed, the kernel reports

=== 18510 ===  +- GC test for session 1-
 | total refcnt  : 2
 | event count   : 0
 | post count: 0
 | child sessions: 2
 | handles in use: 0
 | aliases in use: 0
 | extra refs: 0
 | pid count : 0
 +---

and then blocks on the main CORE::select() with a timeout of roughly
3600 seconds instead of terminating the main loop.

Any ideas on what might have changed recently?

-- Mike

Mike Schilli
p...@perlmeister.com


Re: PoCo::Client::HTTP 0.943 + run_one_timeslice = block

2011-06-22 Thread Rocco Caputo
It may have something to do with the new POE::Component::Resolver dependency 
via POE::Component::Client::Keepalive.

You're trying to trigger a shutdown by destroying a LWP::UserAgent::POE object. 
 However, you don't have a DESTROY method that "shutdown"s PoCo::Client::HTTP.

Without an explicit shutdown, I think KeepAlive is keeping sockets alive.

-- 
Rocco Caputo 

On Jun 18, 2011, at 14:17, p...@perlmeister.com wrote:

> Something must have changed in PoCo::Client::HTTP 0.943 leaving the
> kernel blocking even if all requests have been processed.
> 
> It occurs with a component using the (evil, I know!) run_one_timeslice()
> method, namely
> 
> http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/POE.pm
> 
> which then hangs in the test at
> 
> 
> http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/t/001Basic.t
> 
> What I'm seeing is that even when the only HTTP request has been
> processed, the kernel reports
> 
> === 18510 ===  +- GC test for session 1-
>  | total refcnt  : 2
>  | event count   : 0
>  | post count: 0
>  | child sessions: 2
>  | handles in use: 0
>  | aliases in use: 0
>  | extra refs: 0
>  | pid count : 0
>  +---
> 
> and then blocks on the main CORE::select() with a timeout of roughly
> 3600 seconds instead of terminating the main loop.
> 
> Any ideas on what might have changed recently?
> 
> -- Mike
> 
> Mike Schilli
> p...@perlmeister.com



Re: PoCo::Client::HTTP 0.943 + run_one_timeslice = block

2011-07-30 Thread Rocco Caputo
Please open a ticket against POE::Component::Client::HTTP if shutdown in your 
DESTROY method doesn't resolve it.

-- 
Rocco Caputo 

On Jun 22, 2011, at 23:19, Rocco Caputo wrote:

> It may have something to do with the new POE::Component::Resolver dependency 
> via POE::Component::Client::Keepalive.
> 
> You're trying to trigger a shutdown by destroying a LWP::UserAgent::POE 
> object.  However, you don't have a DESTROY method that "shutdown"s 
> PoCo::Client::HTTP.
> 
> Without an explicit shutdown, I think KeepAlive is keeping sockets alive.
> 
> -- 
> Rocco Caputo 
> 
> On Jun 18, 2011, at 14:17, p...@perlmeister.com wrote:
> 
>> Something must have changed in PoCo::Client::HTTP 0.943 leaving the
>> kernel blocking even if all requests have been processed.
>> 
>> It occurs with a component using the (evil, I know!) run_one_timeslice()
>> method, namely
>> 
>>http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/POE.pm
>> 
>> which then hangs in the test at
>> 
>>
>> http://cpansearch.perl.org/src/MSCHILLI/LWP-UserAgent-POE-0.03/t/001Basic.t
>> 
>> What I'm seeing is that even when the only HTTP request has been
>> processed, the kernel reports
>> 
>> === 18510 ===  +- GC test for session 1-
>>  | total refcnt  : 2
>>  | event count   : 0
>>  | post count: 0
>>  | child sessions: 2
>>  | handles in use: 0
>>  | aliases in use: 0
>>  | extra refs: 0
>>  | pid count : 0
>>  +---
>> 
>> and then blocks on the main CORE::select() with a timeout of roughly
>> 3600 seconds instead of terminating the main loop.
>> 
>> Any ideas on what might have changed recently?
>> 
>> -- Mike
>> 
>> Mike Schilli
>> p...@perlmeister.com
>