[email protected] wrote: > Hi, > > In our application, for LDAP Directory search operations, we are using single > LDAP Handle. All threads shares this single/same LDAP Handle for all search > operations. With OpenLDAP, if we use same LDAP handle for multiple threads, > under the load some part of LDAP handle structure (especially ld_errno) is > being shared across the threads. Due to this behavior from OpenLDAP library, > we are getting -4: Decoding error. > > Thread A is calling ldap_get_values API call. During ldap_get_values API > call, we are trying to fetch attribute values from directory. If attribute > value is empty or attribute is nor present in the directory server, OpenLDAP > internal logic is updating ld_lderrno value to -4 (during ber_printf in > getvalues.c at line:74). > > Thread B is calling ldap_search_ext_s for user lookup using same LDAP Handle. > During this call, while returning "return( ldap_result2error( ld, *res, 0 ) > );" from search call, it checks for ld_errno value. As this value is set to 4 > by Thread A, ldap_search_ext_s API is retuning with -4 error. > > This is the synchronization or atomic operation issue. Under heavy load, at a > particular point, sharing of ld_errno by two threads is causing the problem. > > Could you please check this and provide any solution that is available? As, > this became critical in our application, we are blocked here. > After some research, we identified that ldap_dup API can be used to solve > this issue in multi threading environment. But, we are looking for production > level solution for this problem. Can we use ldap_dup() to fix this issue or > any other fix/solution available? Please share your inputs.
The ldap_dup(3) manpage clearly states that it is to be used in a multithreaded environment. Particularly to enable consistent error handling. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
