RE: Hard loop soon after a connection failure in .31?

More information.  Running the scenario under DProf, I get:

Total Elapsed Time = -40.7223 Seconds
  User+System Time =        0 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 0.00   14.29 14.290 973341   0.0000 0.0000  Net::SSLeay::write_partial
 0.00   8.807  0.000      3   2.9356 0.0000  Net::SSLeay::ssl_write_all
 0.00   7.780 10.132 973341   0.0000 0.0000  Net::SSLeay::print_errs
 0.00   2.865  2.865      1   2.8650 2.8650  Net::SSLeay::connect
 0.00   2.352  2.352 973341   0.0000 0.0000  Net::SSLeay::ERR_get_error
 0.00   0.585  0.630    267   0.0022 0.0024  Convert::ASN1::asn_dump
 0.00   0.330  0.330    640   0.0005 0.0005  IO::Socket::INET::_sock_info
 0.00   0.263  3.847    320   0.0008 0.0120  IO::Socket::INET::configure
 0.00   0.226  0.360   3168   0.0001 0.0001  Convert::ASN1::_decode

This looks like the failure is in the SSLeay module.  Anybody else have 
experience with this issue on this list? 

Thanks --
-- Rick

> -----Original Message-----
> From: Rick Cobb [mailto:rcobb@xxxxxxxxxxx]
> Sent: Wednesday, May 26, 2004 10:02 PM
> To: perl-ldap@xxxxxxxx
> Subject: Hard loop soon after a connection failure in .31?
> 
> 
> I'm running into a situation that I'm finding hard to track down.
> 
> I've got a daemon-like (long-lived, but not detached) process 
> that does a lot of LDAP queries & updates on request from 
> another system.  I've carefully coded it to catch 
> LDAP_SERVER_DOWN, connection fail, and a couple of other 
> error codes, at which time it unbinds and disconnects, and 
> then later retries the connection.
> 
> Most of our testing of this daemon is done from Windows XP 
> laptops, over wireless links.
> 
> When we have a connection, and then lose physically lose a 
> link and then restore it (e.g., pull out a wired ethernet 
> cable, lose our wireless connectivity), we can execute one or 
> two LDAP commands (add/update/modify/search), and then we hit 
> a wall: we issue a command (I see the sent information from 
> turning debug on), and then the daemon sits in a hard loop 
> chewing up all CPU.  This seems to happen right after Windows 
> has decided that DHCP conversations are complete.g
> 
> All of our LDAP calls are synchronous; this is the 'quick & 
> dirty' version before going through and coding with callbacks.  
> 
> We build our own Perl from sources, but haven't compiled for 
> debugging, so I can't see exactly which Perl routine is going 
> haywire.  However, it's pretty clear from tracing it through 
> in the Windows debugger that the loop is doing a 
> malloc/memcpy sequence over and over again as part of what's going on.
> 
> Any insight?  Known bugs?  Should I keep looking deeper at 
> this problem, or re-code to use callbacks and believe it'll 
> just go away?
> 
> Thanks --
> -- Rick Cobb
>