Open
Bug 139793
Opened 22 years ago
Updated 2 years ago
LDAP entries lost following a query to a WAN LDAP Directory Server
Categories
(MailNews Core :: LDAP Integration, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: john.marmion, Unassigned)
References
Details
This was first brought to my attention in OpenOffice.org which integrates with Mozilla's LDAP Address Book. But this problem also exists in Mozilla. The problem is intermittent but it is worth putting down a marker against. I can create this when doing an Advanced Query on an LDAP Server located not on a LAN but on a WAN. If two entries are expected as the results of a query, sometimes only one returns. The one that is returned is not always the same. To re-create may involve me repeatedly running the same query. I have checked that the server correctly returns two entries always. It appears that the client (Mozilla) is getting an end result before we get the last record. I hope to do some more investigation to get a better handle on this.
Updated•22 years ago
|
QA Contact: nbaca → yulian
Comment 1•22 years ago
|
||
Turning on logging for the 'ldap' NSPR log module may help track down what's going on here.
Reporter | ||
Comment 2•22 years ago
|
||
Using the logging facility confirms my original suspicion that where we have 2 entries returned, we see the message type returned in the order: 1. Bind 2. Entry 3. Entry 4. Result Where only one entry is returned the message type returned is 1. Bind 2. Entry 3. Result 4. Entry i.e. we are receiving the "Result" before the last "Entry". The type Result sets the mFinished member in nsAbLDAPDirectoryQuery::OnLDAPMessage() to true thereby ignoring the following Entry. Disabling this allows the two entries to be always returned even though the message type order is incorrect. Obviously I need to investigate why we are receiving the "Result" before the "Entry" in the C-SDK or whether there are any other indicators returned by the Server to indicate the correct sequence.
Comment 3•22 years ago
|
||
Added myself to the Cc. Are any referrals involved?
Reporter | ||
Comment 4•22 years ago
|
||
No, we re-create this using an ldap server which employs referrals and one which does not. I am also unable to reproduce this using "ldapsearch".
Is ldapsearch working in "sync" mode while mozilla LDAP searching in "async" mode? I just find that if I end a search in ldapsearch, the TCP connection is released soon while in mozilla it will hold for a while...
AFAIK, Evolution also deals LDAP searchin in asynchronous way, but the data loss does not happen in it (at least I have not found it yet). It uses the openldap as the base library, is it close to our C-SDK?
Comment 7•22 years ago
|
||
The OpenLDAP and Mozilla LDAP client libraries share some common DNA (both are based on the Univ. of Michigan LDAP open source distribution circa 1996) but they have diverged a lot by now. It would be nice to narrow this down and see whether it is a libldap bug or a Mozilla client bug. The "Result" message is always sent after all entries by an LDAP server, so it is definitely not expected that they would be received out of order.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•19 years ago
|
Assignee: sspitzer → mail
Updated•19 years ago
|
Component: Address Book → MailNews: LDAP Integration
Product: Mozilla Application Suite → Core
Updated•16 years ago
|
Assignee: mail → nobody
QA Contact: yulian → ldap-integration
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•