If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WORKSFORME

Status

MailNews Core
Networking: POP
RESOLVED WORKSFORME
9 years ago
7 years ago

People

(Reporter: Frank Griffin, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Created attachment 366107 [details]
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.
(Reporter)

Comment 2

9 years ago
Created attachment 366108 [details]
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

9 years ago
Frank, can you retest with SeaMonkey 2.0b1pre from:
<http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/>
Component: MailNews: General → Networking: POP
Product: SeaMonkey → MailNews Core
QA Contact: mail → networking.pop
(Reporter)

Comment 4

9 years ago
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

9 years ago
Thanks Frank! Confirming this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Frank could you produce strace logs with the 2.0 alpha too ?
(Reporter)

Comment 7

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

I'll attach it in 4 segments.
(Reporter)

Comment 8

9 years ago
Created attachment 366296 [details]
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.
(Reporter)

Comment 9

9 years ago
Created attachment 366297 [details]
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.
(Reporter)

Comment 10

9 years ago
Created attachment 366298 [details]
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.
(Reporter)

Comment 11

9 years ago
Created attachment 366300 [details]
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

9 years ago
Err, Frank, are you telling us that your linux box doesn't have zip/gzip?
(Reporter)

Comment 13

9 years ago
Of course, but other reporting systems prefer text as text, since not all browsers will automatically unzip.
(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

8 years ago
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.
(Reporter)

Comment 16

8 years ago
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.
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?
(Reporter)

Comment 18

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

7 years ago
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.