482040 - DNS lookup of POP mailserver takes way longer than it should (7-8 seconds)

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: POP, defect)

Description

[Frank Griffin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081216 SeaMonkey/1.1.14
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081216 SeaMonkey/1.1.14

The DNS lookup of the POP server hostname in the mail client takes much longer than it should, according to the length of time the "Looking up xxx" crawl stays visible.  The DNS server is on the same gigabit LAN, and hostname resolution in Seamonkey Navigator and other apps is quite fast by comparison.  Moreover, the DNS is a caching nameserver that forwards all requests not in the cache to my ISP's mailserver, yet the delay occurs on every check for mail, not just the first after the client is started.  So the bug doesn't seem to be affected by any caching done by either seamonkey or the nameserver.

I've seen this for quite some time, on several different systems, both desktop and laptop, both fast and slow.

The lookup never fails; there are no error or timeout messages.  

To diagnose this, I brought up the mail client, attached strace with the -t flag, and then clicked Get Messages.  I will attach the resulting trace file.  It is quite large, and very repetitive.  There are no significant gaps in the timestamps, and the continuous activity seems to be communication over pipes. 

Reproducible: Always

Steps to Reproduce:
1. Start the mail client, and click Get Messages
Actual Results:  
DNS lookup (or activity associated with "Looking up xxx") takes 7-8 seconds.

Expected Results:  
Lookup should be subsecond, based on results for hostname resolution from the Navigator on hostnames not previously looked up either during the particular execution of seamonkey or that of the nameserver.

Comment 1

[Frank Griffin]

Attachment: strace of "Get Messages" processing via strace -t -p, part one

Attaching strace output as per above, in two pieces due to bugzilla size limitations.

Comment 2

[Frank Griffin]

Attachment: strace of "Get Messages" processing via strace -t -p, part two

Attaching strace output as per above, in two pieces due to bugzilla size
limitations.

Comment 3

[Philip Chee]

Frank, can you retest with SeaMonkey 2.0b1pre from:
<http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/>

Comment 4

[Frank Griffin]

Yes, it does.

However, both with 2.0 and 1.1.14, reproducing this isn't 100%.  I installed 2.0 and started it, and got no "Looking up xxx" that I could see, just "Connecting", which went quite fast.  But then I shut it down and brought up 1.1.14, and saw the same behavior.

I should mention that most of this testing is running seamonkey -mail via ssh from a laptop, with the application actually running on my desktop machine, although I've seen the same problem running directly on the desktop machine.

Anyway, I rebooted the laptop (the ssh client) and retried the test, and got the problem behavior with both 1.1.14 and 2.0.  Moreover, I got it repeatedly, as in the original description.

So "Reproducible:" for this should be "much of the time", not "always".

I'm hoping that if someone who knows the code reviews the strace, the cause of the race (or whatever this is) will be apparent.

Comment 5

[Philip Chee]

Thanks Frank! Confirming this bug.

Comment 6

[Ludovic Hirlimann [:Usul]]

Frank could you produce strace logs with the 2.0 alpha too ?

Comment 7

[Frank Griffin]

You'll be sorry you asked.  The 2.0 trace is about twice as large. :-)

I'll attach it in 4 segments.

Comment 8

[Frank Griffin]

Attachment: strace of "Get Messages" processing in 2.0 via strace -t -p, part one

Attaching strace output as per above, in four pieces due to bugzilla size
limitations.

Comment 9

[Frank Griffin]

Attachment: strace of "Get Messages" processing in 2.0 via strace -t -p, part two

Attaching strace output as per above, in four pieces due to bugzilla size
limitations.

Comment 10

[Frank Griffin]

Attachment: strace of "Get Messages" processing in 2.0 via strace -t -p, part three

Attaching strace output as per above, in four pieces due to bugzilla size
limitations.

Comment 11

[Frank Griffin]

Attachment: strace of "Get Messages" processing in 2.0 via strace -t -p, part four

Attaching strace output as per above, in four pieces due to bugzilla size
limitations.

Comment 12

[Philip Chee]

Err, Frank, are you telling us that your linux box doesn't have zip/gzip?

Comment 13

[Frank Griffin]

Of course, but other reporting systems prefer text as text, since not all browsers will automatically unzip.

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> I should mention that most of this testing is running seamonkey -mail via ssh
> from a laptop, with the application actually running on my desktop machine,
> although I've seen the same problem running directly on the desktop machine.
> 
> Anyway, I rebooted the laptop (the ssh client) and retried the test, and got
> the problem behavior with both 1.1.14 and 2.0.  Moreover, I got it repeatedly,
> as in the original description.

what's needed to move this bug forward?

Comment 15

[Philip Chee]

Some POP/networking person needs to look at the attached logs. In retrospect we should have asked for a NSPR log or wireshark log of network traffic as well.

Comment 16

[Frank Griffin]

I'll try to get one for my current version of 1.1.14.  Mandriva hasn't packaged 2.0 yet, and I uninstalled the version I had installed for the test.  Since the error occurs in both versions, that should do for a start.

Comment 17

[WADA:World Anti-bad-Duping Agency]

Frank Griffin(bug opener), when problem started to occur?
Started from day you upgraded to 1.1.14 from 1.1.13?
Was there any event around day problem started to occur?
  - OS version up, network module version up, network change, ...
  - ISP started to support IPv6, Mail server started to support IPv6, ...
Will network.dns.disableIPv6=true reduce frequency of problem?

Comment 18

[Frank Griffin]

Sorry, I must have missed comment 17.  This had been happening for a while before I reported it, and there was no "smoking gun" event associated.

In any event, it appears to be fixed now (2.0.6), so I'm closing this.