Our client has a failover setup wherein they have multiple ldap servers.
When they ping to this particular hostname "thcg.net" then it returns the
IP address of the LDAP server currently being used.
If we configure the particular IP address as the hostname in our
application then we are able to connect to ldap successfully. But if we
configure "thcg.net" as the hostname then we are unable to connect. In
effect our application is not able use the functionality fail-over. The
ldap_simple_bind_s() API fails with error code as 91 and the error message
as "Can't connect to LDAP server'.
dev-tech-ldap mailing list
The length of buffer supplied to gethostbyname_r API is hard-coded to 1024. While the expected output on my machine is more than 1024.
The limit should be increased in future release.
In reply to this post by Neha Agarwalla
I'm using a 32-bit 6.0.6 LDAP C-SDK DLL, that I build with MozillaBuild, and running with my 32-bit Windows service. The system is Win7 64-bit.
Let me say first off that I did not notice any related patches listed on the wiki, applied since 6.0.6.
And also that I'm investigating my application for any inadvertent sharing of the LDAP instance between threads. I generally try to avoid sharing between threads (trying to keep usage as single-threaded as possible, for simplicity).
With that said, and with the possibility of threading issues, I have encountered this call stack on a remote machine:
NSLDAP32V60.dll!msgid_getdata(void * pTableData=0x110f8d88, void * key=0x0450d478, void * * ppData=0x0450d444) Line 1907 + 0x6 bytes C
NSLDAP32V60.dll!htable_get(HashTable_struct * pTable=0x00c1eec8, void * key=0x0450d478, void * * ppData=0x0450d444) Line 1765 + 0x1a bytes C
NSLDAP32V60.dll!memcache_access(ldapmemcache * cache=0x03e50858, int mode=0, void * pData1=0x0450d48c, void * pData2=0x0450d478, void * pData3=0x03fe1268) Line 1436 + 0x14 bytes C
NSLDAP32V60.dll!memcache_add(ldap * ld=0x00c572a8, unsigned long key=331271083, int msgid=170, const char * basedn=0x03fe1268) Line 1033 + 0x1d bytes C
NSLDAP32V60.dll!ldap_memcache_new(ldap * ld=0x00c572a8, int msgid=170, unsigned long key=331271083, const char * basedn=0x03fe1268) Line 752 + 0x15 bytes C
NSLDAP32V60.dll!nsldapi_search(ldap * ld=0x00c572a8, const char * base=0x03fe1268, int scope=2, const char * filter=0x117f46e8, char * * attrs=0x00000000, int attrsonly=0, ldapcontrol * * serverctrls=0x00000000, ldapcontrol * * clientctrls=0x00000000, int timelimit=-1, int sizelimit=100, int * msgidp=0x111c0a58) Line 239 + 0x15 bytes C
NSLDAP32V60.dll!ldap_search_ext(ldap * ld=0x00c572a8, const char * base=0x03fe1268, int scope=2, const char * filter=0x117f46e8, char * * attrs=0x00000000, int attrsonly=0, ldapcontrol * * serverctrls=0x00000000, ldapcontrol * * clientctrls=0x00000000, timeval * timeoutp=0x00000000, int sizelimit=100, int * msgidp=0x111c0a58) Line 150 + 0x3c bytes C
Apologies for wide lines. I guess my question to you is whether this call stack is remotely familiar to anyone (I can always hope!). Otherwise, I was studying usage of LDAP_MUTEX_LOCK(ld,LDAP_MEMCACHE_LOCK) and the corresponding unlock in ldap_memcache_new. Not fully understanding the lock implementation in Windows, is it possible to get all the way down this stack, and simultaneously call ldap_unbind from another thread? And looking at ldap_unbind, seems like once I'm inside ldap_memcache_new, unbind would block for thread safety.
Hoping someone has any kind of suggestion or idea that might help me. Since I can't reproduce the problem on my debug machine, I can at least try to eliminate any threading issues that have creeped in. Otherwise, not sure what else might be impacting me?
dev-tech-ldap mailing list
|Free forum by Nabble||Edit this page|