Re^2: Using Mozilla::LDAP instead of Net::LDAP

Strat,

O.K. - here we go :-)

I am searching a directory using an authenticated bind.

I am using the same connection for a number of searches; essentially navigating down the X.500 DIT to extract leaf entries from some (but not all) limbs of the directory.

On the test system this always works.

On the live system this often works.

When searching a particularly large subtree I seem to get all the data back, but the connection is shown in the DSA log as unbinding, although I have not issued an 'unbind'.

The next search fails (obviously); I then have to bind to the directory again before I can search again.

I have no real evidence as to why the connection has unbound. It could be a timeout condition under load, perhaps.
My main problem is that I can't see any way under Mozilla::LDAP to set the timeout period for a search.
I can see in Net::LDAP that I can specify a timeout when I bind, which may be inherited by the searches, but the interface through Mozilla::LDAP seems to be very simplistic.

Any suggestions on how to improve the resilience of the search would be welcome.

Regards

Dave R.

Nothing succeeds like a budgie with no teeth.

Comment on Re^2: Using Mozilla::LDAP instead of Net::LDAP

Replies are listed 'Best First'.
Re^3: Using Mozilla::LDAP instead of Net::LDAP by strat (Canon) on Sep 27, 2006 at 08:23 UTC
What does the Server log tell you? Do you do error handling in your code? if yes, the server will tell you about timeouts etc. Which error messages is given? Best regards, perl -e "s>>F>e=>y)\martinF)stronat)=>print,print v8.8.8.32.11.32"	[reply]
Re^4: Using Mozilla::LDAP instead of Net::LDAP by LittleGreyCat (Scribe) on Oct 03, 2006 at 09:54 UTC
Strat, there is error handling in the code; however the symptoms are: (1) A search completes without error, returning the expected (large amount of) data. (2) The next searches fails 'Unable to contact LDAP server' (or similar). The server log shows that the connection was unbound after the successful search in (1) although the code did not issue an 'unbind'. This in turn explains the unexpected failure in (2) as there is no longer a connection. I have not yet located a log which shows any error associated with the connection which unexpectedly 'unbound'. I have so far been unable to reproduce the fault on a test system, and I am reluctant to propose upping the server logging on an extremely heavily loaded live service. Regards Dave R. Nothing succeeds like a budgie with no teeth.	[reply]
Re^5: Using Mozilla::LDAP instead of Net::LDAP by strat (Canon) on Oct 03, 2006 at 10:53 UTC
To be able to help you, I need more specific information: the output of the following line after the first search: `$conn->printError() if $conn->getErrorCode();` If there's no output, then also put it into the loop where you are fetching the entries. which LDAP Server you use (also which patch level; e.g. IBM Tivoli Directory Server 5.2 without patches sometimes behaves strange) see some code, especially the connect/bind and search properties. Best regards, perl -e "s>>F>e=>y)\martinF)stronat)=>print,print v8.8.8.32.11.32"	[reply] [d/l]
Re^6: Using Mozilla::LDAP instead of Net::LDAP by LittleGreyCat (Scribe) on Oct 10, 2006 at 11:12 UTC


Think about Loose Coupling
	PerlMonks