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

Status: NEW

(MailNews Core :: LDAP Integration, defect)

Description

[John Marmion]

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.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Turning on logging for the 'ldap' NSPR log module may help track down what's
going on here.

Comment 2

[John Marmion]

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

[Mark Smith [:mcs]]

Added myself to the Cc. Are any referrals involved?

Comment 4

[John Marmion]

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". 

Comment 5

[Sean Gao]

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... 

Comment 6

[Sean Gao]

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

[Mark Smith [:mcs]]

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.

Comment 8

[(not reading, please use [e-mail] instead)]

mass re-assign.