Diagnosing LDAP connection errors.

[Benji Wakely]

If you're just after the number of concurrent connections held open simultaneously to a particular LDAP server or group of servers,
and you just want it for one point in time,
would netstat on the IdP suffice?
(Looking for 'ESTABLISHED' connections.)

--Benji

Benji Wakely - b.wakely at latrobe.edu.au
Unix Systems Administrator

Work phone: +613 9479 5499
mobile: +614 34 307 667


>-----Original Message-----
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Tom Poage
>Sent: Thursday, 29 September 2011 5:03 AM
>To: users at shibboleth.net
>Subject: Re: Diagnosing LDAP connection errors.
>
>On 09/27/2011 11:16 AM, Cantor, Scott wrote:
>> The empty strategy is what gets used when there is no pool. Every
>checkout
>> of the pool creates a connection and the checkin destroys it.
>>
>> A recent poster indicated that leaving out a pool config causes the
>data
>> connector to still reuse some connections. If that's true, it's below
>the
>> layers of software and somewhere inside the JVM, because the code in
>the
>> IdP is pretty clearly not doing any reuse.
>
>Is there a way to monitor the number of (simultaneous) LDAP connections
>on the IdP when pooling is not enabled?
>
>One might sift through LDAP logs (ours are about 40 GB/day spread across
>a handful of busy servers), perhaps infer from the number of SSO
>requests logged prior to corresponding audit entries, or turn up
>debugging and analyze IdP logs. These all seem to require 'stateful' log
>file inspection.
>
>I do see that when pooling is enabled and edu.vt.middleware.ldap is set
>to DEBUG it reports pool size information.
>
>Thanks!
>Tom.
>--
>To unsubscribe from this list send an email to users-
>unsubscribe at shibboleth.net