Closed
Bug 482040
Opened 15 years ago
Closed 14 years ago
DNS lookup of POP mailserver takes way longer than it should (7-8 seconds)
Categories
(MailNews Core :: Networking: POP, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: ftg, Unassigned)
Details
Attachments
(6 files)
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•15 years ago
|
||
Attaching strace output as per above, in two pieces due to bugzilla size limitations.
Reporter | ||
Comment 2•15 years ago
|
||
Attaching strace output as per above, in two pieces due to bugzilla size limitations.
Comment 3•15 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•15 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•15 years ago
|
||
Thanks Frank! Confirming this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•15 years ago
|
||
Frank could you produce strace logs with the 2.0 alpha too ?
Reporter | ||
Comment 7•15 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•15 years ago
|
||
Attaching strace output as per above, in four pieces due to bugzilla size limitations.
Reporter | ||
Comment 9•15 years ago
|
||
Attaching strace output as per above, in four pieces due to bugzilla size limitations.
Reporter | ||
Comment 10•15 years ago
|
||
Attaching strace output as per above, in four pieces due to bugzilla size limitations.
Reporter | ||
Comment 11•15 years ago
|
||
Attaching strace output as per above, in four pieces due to bugzilla size limitations.
Comment 12•15 years ago
|
||
Err, Frank, are you telling us that your linux box doesn't have zip/gzip?
Reporter | ||
Comment 13•15 years ago
|
||
Of course, but other reporting systems prefer text as text, since not all browsers will automatically unzip.
Comment 14•15 years ago
|
||
(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•15 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•15 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.
Comment 17•15 years ago
|
||
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•14 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
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•