Closed Bug 436774 Opened 16 years ago Closed 16 years ago

Hang when accessing IMAP account after a while

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 476960

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(1 file)

Attached file imap:5 log
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9pre) Gecko/2008053100 SeaMonkey/2.0a1pre (has happened for quite some time, at least with trunk builds for the last year)

When waking up my machine out of APM sleep I frequently notice that the UI hangs for a few seconds when I access an IMAP account afterwards. When I access the IMAP account as the first thing after waking up the hang is long (up to ~30s) when I first use the browser (so that getting a webpage establishes a new DSL connection) the hang is usually short (about 5s), but still annoying.

Not sure what more information I can or should provide at this stage, for now I attach the excerpts of the NSPR imap:5 log that related to output I get when the hang occurs. (I noted which lines where there before the hang and then cut-and-pasted the first few lines after that.)
Hmm, I tried a few times more on Linux and there was no hang. The first two lines after the wakeup are

-1222063632[804a548]: f722260:imap.variomedia.de:NA:SetupWithUrl:
                      clearing IMAP_CONNECTION_IS_OPEN
-1469244528[11266838]: ImapThreadMainLoop entering [this=f722260]

so there is no "TellThreadToDie: close socket connection" and no rv value is mentioned after IMAP_CONNECTION_IS_OPEN.

Not sure if this tells me that this is an OS/2-only problem or if the difference is APM wakeup (on my Desktop) versus ACPI (on my Linux laptop).
OK, so I could finally reproduce this hang a few times with SeaMonkey trunk on Linux (currently 2008063001). The NSPR imap:5 log has this after wakeup:

-1368183920[d8b8f50]: ImapThreadMainLoop leaving [this=e151810]
-1222796816[804a548]: ReadNextLine [stream=d16d068 nb=0 needmore=1]
-1222796816[804a548]: d631090:imap.variomedia.de:
                      S-INBOX_Mozilla:CreateNewLineFromSocket:
                      clearing IMAP_CONNECTION_IS_OPEN - rv = 804b000e
-1222796816[804a548]: d631090:imap.variomedia.de:
                      S-INBOX_Mozilla:TellThreadToDie: close socket connection
-1410147440[dfb3e30]: ImapThreadMainLoop leaving [this=d631090]
-1222796816[804a548]: d631090:imap.variomedia.de:
                      S-INBOX_Mozilla:CreateNewLineFromSocket: (null)
-1222796816[804a548]: d631090:imap.variomedia.de:
                      S-INBOX_Mozilla:TellThreadToDie: close socket connection
-1222796816[804a548]: e128e68:imap.variomedia.de:NA:SetupWithUrl:
                      clearing IMAP_CONNECTION_IS_OPEN

So it's esentially the same as on OS/2. I haven't caught this with TB yet, but as the IMAP backend is shared, I don't see why this should be SM specific.

The thing that I changed since last month was to deactivated IDLE mode on my IMAP accounts (i.e. set mail.server.serverX.use_idle to false), mainly because of bug 362941.
OS: OS/2 → All
Hardware: PC → All
The log excerpts shown in bug 434642 show the same that I see here. Maybe it's a dupe, but as long as I don't know for sure, I mark it as dependent on that bug.
Depends on: 434642
Product: Core → MailNews Core
Peter, do you still see this in more recent builds?
xref Bug 479773
Severity: normal → critical
Component: Backend → Networking: IMAP
QA Contact: backend → networking.imap
Wayne, sorry that it took so long to react here. Because I had changed some settings in my different setups (and actually am running on new computers now) compared to when I saw this bug, I had to try several possibilities and that took a while.

By now I think I have tried all relevant options and can say that indeed this bug seems fixed. I guess that this was done by the work in bug 476960. Not sure what to mark this one now, dupe?
dupe sounds good. Thanks Peter
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: