POE::Component::Client::HTTP not reconnecting, why?

[albertocurro]

Hi everyone,

 I've found this problem with POE::Component::Client::HTTP, as when the 
endpoint (HTTP Server) shuts down, POE is not reconnecting after a while, even 
if the server comes up again. 

 This is part of the initialization code:

 POE::Session->create(
       inline_states => {
             _start => sub {
                   $_[KERNEL]->alias_set("store_remote_$self->{RIDX}");
                   $self->{SESSION} = $_[SESSION];
                   $_[HEAP]{self} = $self;                  
                   POE::Component::Client::HTTP->spawn(
                         Timeout => 
$config->get('remote_store')->[$idx]->{'request_timeout'},
                         Alias => $self->{ALIAS},
                         Proxy => $config->get('remote_store.proxy'),
                         Protocol => 'HTTP/1.1',
                         ConnectionManager => 
POE::Component::Client::Keepalive->new(
                               keep_alive => 1,
                               max_open => 100,
                               max_per_host => 100,
                               timeout => 10,
                                resolve_cb => sub { 
$self->_resolve_cb(@_); },
                         ),
                   );
            },
             on_handle => \&_handle,
             on_response => \&_response,
             on_read_dir_response => \&_read_dir_response,
             on_mkdir_response => \&_mkdir_response,
             on_retry => \&_retry,
             _monitoring_tick => \&_monitoring_tick,
       }
 );

  Looking for a possible similar issue in the mailing list database, I've found 
this message @ http://www.mail-archive.com/poe@perl.org/msg04735.html, where 
Gabor suggested to increase the number of max connections in the KeepAlive 
instatiation; changing it to 1000 instead of 100, the issue is gone.

I'd like to understand why this exactly happens. Maybe the client not freeing 
the connections when they can't be stablished? is this a known issue, or 
something designed this way? 

 I can see also that, from 1.357, the error shown in the logs is 408 Request 
timeout, while in previous versions was 111: connection refused. IMHO the 
previous one was more accurate than the one in 1.357, because the endpoint is 
down at this time.

 Regards
 Alberto