373167 - LDAP lookup against Active Directory causes repeated app freezes

Status: RESOLVED WONTFIX

(MailNews Core :: LDAP Integration, defect)

Description

[Andrew Simmons]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2
Build Identifier: 

Thunderbird freezes for 30 seconds, presumably doing lookups for auto-complete  against Active Directory, whenever I type unrecognised names in the message recipient text box. Names that have been used before do not cause the freeze. This is having a major effect on usability.

Reproducible: Always

Steps to Reproduce:
1. Configure LDAP to point at Active Directory LDAP server
2. Start composing a new email
3. Type recipient name that has not been previously seen by T'bird, causing a lookup against the configured LDAP directory


Actual Results:  
Thunderbird freezes for 20-30-40 seconds.

Expected Results:  
Name auto-completes whilst you are typing. (Name lookups in MS Outlook are much, much, much quicker.)

I'm using Linux (Mandriva 2007); I haven't checked whether the Windows version behaves the same way.

Comment 1

[Mark Banner (:standard8)]

Just to be clear: have you checked if the delay happens when you TB is configured not to use the LDAP directory for autocomplete?

What happens if you go into the address book and do a quick search on the LDAP directory there - is that still slow?

Comment 2

[Andrew Simmons]

Just to confirm that the same version of Thunderbird (1.5.0.10), on the same physical machine, works as expected when I reboot it into Windows.

Mark: No, I haven't tested either of those scenarios - I'll follow-up tomorrow when I'm back in the office.

I should probably have mentioned the version as well: Version 1.5.0.10 (20070221)

I'm somewhat surprised that there's not already a bug filed on this, as I don't remember it ever working properly under Linux - I'd put it down to quirks of our AD, were it not fine under Windows.

Comment 3

[Mark Banner (:standard8)]

Possibly related to bug 202858

Comment 4

[Andrew Simmons]

I have tested the scenarios in comment #1:

- when TB is not configured to use LDAP (turned off in the global prefs), local 
  searches are fine - no freeze.

- when searching against the AD in Addressbook, there's no UI freeze - there's a short (~1 second) delay then results fill the page (I searched for 'test', and it turns out we have a lot of entities with that in their name in our AD.)

- I also tested using the 'contacts' pane in a compose window; there's no freeze,  but I'm not getting results back from the search either.

Comment 5

[Mark Banner (:standard8)]

Could you try a Thunderbird 2.0 beta 2 (or rc build if its out yet) and turn on LDAP logging as detailed below:

http://wiki.mozilla.org/MailNews:LDAP_Address_Books#LDAP_Logging

I can't remember if the logging includes timestamps off hand, but it'd be useful if you could attach a log and (if its possible) point out the bit where it is hanging.

Comment 6

[hcaley]

I am having the same or similar problems with Thunderbird 1.5.0.10 as provided with Fedora Core 6.  If I try to use my local AD server for address autocompletion it hangs tbird for about 30 seconds, and never returns anything(moving the composition window during this time smears the window across the main tbird window).  If I open the Address Book it works sometimes, but sometimes that hangs too.  This doesn't happen if I autocomplete against an OpenLdap server.  It doesn't happen on Thunderbird 1.5.0 on Windows against the same AD server.

Comment 7

[hcaley]

Same LDAP options and credentials on both Windows and Linux, of course.

Comment 8

[Mark Banner (:standard8)]

(In reply to comment #6)
> I am having the same or similar problems with Thunderbird 1.5.0.10 as provided
> with Fedora Core 6.

Well it looks like there is a problem, any chance you could try what I suggested in comment 5? Without that (at a minimum) I'm not going to be easily able to reproduce/resolve this issue as I don't have an AD server to play about with.

Comment 9

[hcaley]

I tried setting the ldap logging variables and running thunderbird 2.0b2.  A log file gets created, but nothing ever gets written to it, whether I use address completion or open the Address Book and query the LDAP directories from there.

export NSPR_LOG_MODULES=protocol:5
export NSPR_LOG_FILE=/tmp/ldap.log

./thunderbird &

ldap.log is created, but nothing is written to it.

Comment 10

[Mark Banner (:standard8)]

(In reply to comment #9)
> export NSPR_LOG_MODULES=protocol:5

Thanks for trying, that line should be:

export NSPR_LOG_MODULES=ldap:5

Hopefully, that'll get the log working.

Comment 11

[hcaley]

Attachment: LDAP log when doing an autocompletion and an address book query to AD

LDAP log from Thunderbird 2.0b2 doing address autocompletion and address book query to an Active Directory server

Comment 12

[hcaley]

D'oh!  Ok, LDAP log now attached.

Comment 13

[Mark Banner (:standard8)]

Any chance you could do that without NSPR_LOG_FILE set and tell us between which lines it hangs?

Do you normally enter a password for this connection?

Comment 14

[hcaley]

Hangs here:
[hughc@joss thunderbird]$ ./thunderbird
158223248[afa57d8]: nsLDAPConnection::Run() entered
2624496[a2caeb0]: nsLDAPOperation::SimpleBind(): called; bindName = 'R&DSERV1\hughc'; 
2624496[a2caeb0]: pending operation added; total pending operations now = 1
158223248[afa57d8]: pending operation removed; total pending operations now = 0
2624496[a2caeb0]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=hq,dc=aldon,dc=com'; aFilter = '(|(cn=murr**)(mail=murr**)(sn=murr**))', aAttrCounts = 2, aSizeLimit = 100
2624496[a2caeb0]: pending operation added; total pending operations now = 1

Comment 15

[Mark Banner (:standard8)]

(In reply to comment #14)
> Hangs here:
> [hughc@joss thunderbird]$ ./thunderbird
> 158223248[afa57d8]: nsLDAPConnection::Run() entered
> 2624496[a2caeb0]: nsLDAPOperation::SimpleBind(): called; bindName =
> 'R&DSERV1\hughc'; 

Are you sure your bindName is correct, I'd have expected it more along the lines of 'cn=xyz,dc=hq,dc=aldon,dc=com'

Comment 16

[hcaley]

yes, the bindName is correct.  It's a legacy thing, but I think that is not relevant.  As I mentioned above, the identical credentials work fine on the Windows version of Thunderbird.

Comment 17

[Huub Heerink]

I am currently having a 30-sec freeze using 2RC1 (20070326) under Windows, but I am experiencing it because my LDAP server is down. It doesn't matter whether the address is in my local address book or not. 

Comment 18

[hcaley]

There's actually a very similar problem with Evolution when accessing an AD server over LDAP: 

http://bugzilla.gnome.org/show_bug.cgi?id=368877

Could both projects be hitting a problem with AD's LDAP implementation?

Comment 19

[boris]

From a user interface perspective it is most annoying that the LDAP lookup is not asynchronous in relation to the rest of the application. Is there a chance that we see a re-entrant address-lookup (meaning that the user can type in a list of names, and can choose afterwards to select the best match? The message wouldn't be sent until all conflicts are resolved, but the user can work in her/his own pace...
Alternatively would it be possible to cache the LDAP information for the addressbook?

Comment 20

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Reporter(s), does this issue still occur in the latest supported 2.0.0.14 / trunk nightlies?

Comment 21

[mephinet]

Hi,
having the same issue, I turned on LDAP debugging and compared the output of
the LDAP query in the compose-mail window to the one in the addressbook.
It looks to me as if the asterisks are misplaced in the former:

compose-mail window:
nsLDAPOperation::SearchExt(): called with aBaseDn = 'DC=lan,DC=apa,DC=at'; aFilter = '(|(cn=patric**)(mail=patric**)(sn=patric**))', aAttrCounts = 2, aSizeLimit = 1000

address book:
nsLDAPOperation::SearchExt(): called with aBaseDn = 'DC=lan,DC=apa,DC=at'; aFilter = '(|(mail=*patricia*)(cn=*patricia*)(givenName=*patricia*)(sn=*patricia*))', aAttrCounts = 64, aSizeLimit = 1000

I don't expect the double-asterisks to be here intentionally, right?
Tested with version 2.0.0.19

Comment 22

[mephinet]

Digging through MsgComposeCommands.js, I found that the filter string can be customized by setting ldap_2.servers.<NAME>.autoComplete.filterTemplate.
I set it to (|(cn=*%v1*)(mail=*%v1*)(sn=*%v1*)),
now the query is equivalent to the one executed by the address book - but the widget still hangs.
So the double asterisk is not to blame for this behavior.

Comment 23

[mephinet]

While not solving the underlying issue, this might be a good place to document the work-around, as mentioned in <http://exain.wordpress.com/2008/07/29/thunderbird-active-directory-ldap-lookups-hang-issues/>:
Instead of the standard port 389, specify port 3268, and the freezing is gone.

Successfully tested with Thunderbird 2.0.0.19 on Gentoo Linux against AD on MS Windows Server 2003.

Comment 24

[Nikolay Shopik]

Bug 533656 is describing why this happening. probably we should dupe

Comment 27

[boris]

> Instead of the standard port 389, specify port 3268, and the freezing is
> gone.
- Does not really help if LDAP cannot be reached there. It gets faster but does not look up the entries in my case. This is almost equivalent to deleting the LDAP entry itslf. (this is no workaround, but a shutdown of functionality)
Essentially the UI seems to wait for any response from the LDAP before it times out after 10 s, which is a really bad behavior for user interaction.
Whilst not knowing the code there seems to be a major misconception not to allow for asynchronous searches. -Wondering how successful Google would be if their UI would freeze for 10 s every time anything is typed into their search box.

For us it is a major problem especially when using a laptop that cannot reach an existing Server (e.g. outside a firewall) tbird stalls in mid air.

As a result currenty LDAP lookups in tbird have to be considered as broken, if one does not want to avoid tbird altogether.

Comment 28

[Ernst Sjostrand]

This issue is still present in Thunderbird 16. Using port 3268 works here so that was a nice workaround.

Comment 29

[reinaldoc]

As Ernst says, changing port from 389 to 3268 works.

Comment 30

[Wayne Mery (:wsmwk)]

Also reported by https://support.mozilla.org/en-US/questions/1007335#answer-602690

Does http://guntramblohm.blogspot.com/2012/01/thunderbird-ldap-search-is-very-slow-on.html help?

Comment 31

[Mark]

Happens in TB 38.2.0
Port 3268 fixes it, we're lucky it's opened to us.

Comment 32

[npapadonis]

I upgraded from the latest stable release to Earlybird release v43.0a2 (2015-10-12).  I was experiencing the 15 - 20 second hangs with the stable version and can confirm the issue appears resolved with 43.0a2. 

Unsure what recent code change resolves the problems.  If anyone knows, suggest it be included for backport to a stable release.

Comment 33

[[e-mail]]

Issue still persists with Earlybird v43.0a2.
OS: Fedora 22

Comment 34

[[e-mail]]

Issue persists with 45.5.1 on Windows 7 Professional, seems to happen more often since last auto upgrade. I experience a complete freeze of Thunderbird on a regular basis. I am not sure if it would recover after long enough waiting. I've waited maybe a minute. Longer wait times mean it is faster to restart and rewrite my changes since last auto-save. This is effectively a complete freeze, not a performance issue!

Comment 35

[Wayne Mery (:wsmwk)]

other ldap problem reports https://mzl.la/2iOLf22

Comment 36

[Nikolay Shopik]

Not sure I can help here, didn't use LDAP for while, but I've remember these UI lock when LDAP is slow, its just LDAP thread locking UI.

Comment 37

[Wayne Mery (:wsmwk)]

Jan 2019 Dieter reports " during "normal use", the problem occured again. I am not sure what exactly triggers the behavior, but it does seem to still occur. "

Comment 38

[Ping Chen [:rnons] (away)]

LDAP c-sdk has been removed in bug 1729862. Please file new bug if this is still a problem.