Hy all, I was reading the messages in the forum looking for some information for a problem I have. And I found this post: On August 30, 2005 6:42:39 PM -0400 Alan DeKok <aland at ox.org> wrote:
Frank Cusack <fcusack at fcusack.com> wrote:
In ldap_get_conn(), conns[i].locked must not be tested until after a lock is obtained.
fixed in rlm_ldap.c#1.156 but I don't know how to propagate this change to 1.0.5 candidate.
Looking at the code, I'm not even sure that the "locked" member is appropriate for a threaded environment. It could probably be deleted.
For non-threading mode, the LDAP module can't be using multiple connections, because it can only be called once. For threading mode, the mutexes protect the data structure.
The "locked" member should be deleted, unless I'm missing something.
I have a question: In the ldap_get_conn I see that you use a pthread_mutex_trylock. So if you try to get connection and all the connections are locked, the module fails. Why don´t you use the pthread_mutex_lock function instead in order to wait until the connection is unlocked? Thanks a lot Peter ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com
Peter Manckok <peter_manckok@yahoo.es> wrote:
Why donŽt you use the pthread_mutex_lock function instead in order to wait until the connection is unlocked?
Because the LDAP server may be blocked. So waiting for the lock means waiting for 20-30 seconds, which is unacceptabled. The current implementation allows the server to fail over to a second LDAP database if all of the connections to the first one are used. Also, the configurationj limits the number of connections to the LDAP server, to avoid overloading it with RADIUS requests. Once the number of connections are limited, you *have* to fail when all are in use. This makes the server more robust, because it gracefully handles failures, rather than stopping dead. Alan DeKok.
participants (2)
-
Alan DeKok -
Peter Manckok