30 seems rather low - we had a problem (since fixed) with our Atlassian Crowd server (which we use to gateway JIRA, Stash, etc authentication to 389DS via LDAP) where it wouldn't release connections and would have 900+ connections before the 389DS server would stop accepting connections and we'd have to restart Crowd (or 389DS, but restarting Crowd was less disruptive). Though most of those 900 connections were idle just taking up slots on the server, vs active queries...


On Mon, Nov 4, 2013 at 11:46 AM, Jan Tomasek <jan@tomasek.cz> wrote:
On 11/04/2013 05:22 PM, Rich Megginson wrote:
> On 11/04/2013 09:08 AM, Jan Tomasek wrote:
>> On 11/04/2013 05:04 PM, Rich Megginson wrote:
>>
>>> Does the script open a connection to the same server it is being called
>>> from?
>>
>> Yes.
>
> So this is a case of self-deadlock?  I don't understand.  What is it
> exactly that you expect will happen?

If there is one connection it works. If there is 29 parallel bind
requests it works. If there is 30 and more it immediately hang. I'm
seeking why 29 is ok and 30 is bad.

In other words deadlock happens only if I run 30+ parallel connections.
I do this:

> for i in `seq 1 30`
> do
> time ldapsearch -LLL -H ldaps://xxx.cesnet.cz -x \
>   -b dc=perun-shadow,dc=cesnet,dc=cz \
>   -D "uid=semik$i,ou=People,dc=perun-shadow,dc=cesnet,dc=cz" \
>   -w 'zadek' -s base dn &
> done

and 389 is immediately deadlocked. That should not happen I think.

The script itself binds anonymously so it should not go into PAM.

That script was just proof of concept. Maybe I should explain what I
want to do in other thread.

--
-----------------------
Jan Tomasek aka Semik
http://www.tomasek.cz/


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users