Open Bug 139793 Opened 19 years ago Updated 9 years ago

LDAP entries lost following a query to a WAN LDAP Directory Server


(MailNews Core :: LDAP Integration, defect)

Not set


(Not tracked)


(Reporter: john.marmion, Unassigned)


(Blocks 1 open bug)


This was first brought to my attention in 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.
QA Contact: nbaca → yulian
Turning on logging for the 'ldap' NSPR log module may help track down what's
going on here.
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. 

Added myself to the Cc. Are any referrals involved?
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?  
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.
mass re-assign.
Assignee: racham → sspitzer
Blocks: 213274
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Component: Address Book → MailNews: LDAP Integration
Product: Mozilla Application Suite → Core
Assignee: mail → nobody
QA Contact: yulian → ldap-integration
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.