Closed Bug 221023 Opened 21 years ago Closed 21 years ago

IMAP connection seem unreliable over wan connection

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla06b, Assigned: Bienvenu)

Details

(Keywords: dataloss)

Attachments

(15 files)

log of IMAP mail session
119.84 KB, text/plain
Details
IMAP log file part 1
213.01 KB, text/plain
Details
IMAP log file part 2
281.10 KB, text/plain
Details
patch to generate more logging
6.28 KB, patch
Details | Diff | Splinter Review
imapLog.2003:10:10:10:21:56.part1
253.67 KB, text/plain
Details
imapLog.2003:10:10:10:21:56.part2
249.61 KB, text/plain
Details
IMAP log
269.77 KB, text/plain
Details
new log with the starting sequence of Mozilla Mail
28.09 KB, text/plain
Details
log when urls are "doomed"
314 bytes, patch
Details | Diff | Splinter Review
new IMAP log 10-13-2003
245.99 KB, text/plain
Details
more logging, and potential fix for monitor problem
1.46 KB, patch
Details | Diff | Splinter Review
IMAP log using 10-18-2003 build
281.38 KB, text/plain
Details
part one of imap log
217.79 KB, text/plain
Details
part two of IMAP log
221.47 KB, text/plain
Details
potential fix
2.55 KB, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5; MultiZilla v1.5.0.3c) Gecko/20030925 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5; MultiZilla v1.5.0.3c) Gecko/20030925 I have two IMAP accounts that I connect to. One is on our LAN and one is on the Internet. When I delete an email either by selecting and deleting it or having the junk mail controls delete it when I mark it junk, I get different performance from Mozilla. On the LAN everything seems to work just fine; a very occational hang when there is heavy traffic. On the Internet server, deletes and loads often hang; mozilla just sits there. The only way I have found to clear it is to completely exit Mozilla, not just mail, and start again. When the IMAP email hangs, it reports that it is loading message, but it does nothing. The size of the message does not seem to matter. What seems to matter is the amount of activity on the network. It acts like the connection is dropped and never reestablished. I have a broadband Internet connections. The LAN is 100baseT. Both the LAN and WAN IMAP servers are running the same version UW_IMAP server. I also have two POP accounts and they are not affected. This was not happening when I was using Mozilla 1.3.1. This only started when I started using 1.5rc1 and 1.5rc2. I never used 1.4, so I don't know if the problem was in that branch. Reproducible: Sometimes Steps to Reproduce: 1. Open email 2. Open LAN IMAP account read, delete, and mark as junk emails 3. Open WAN (Internet) IMAP account, read, delete, and mark as junk emails Actual Results: Ususally performs as expected on the LAN, but very infrequently, there is a hang. On the WAN account, email often hangs. Reports that it is loading message, but it does nothing. The message it is trying to load or delete may be small (1k or so). Expected Results: IMAP should delete, load, and move mail as expected without dropping out and having to restart Mozilla.
Can you attach or e-mail me an imap protocol log of the failure by following these instructions: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap You're running 1.5, not the 1.6 trunk builds, is that right? You might try a recent 1.6 build if only because the LAN performance of IMAP is about twice as fast with 1.6 - also, do you have Mozilla configured to check all or some folders other than the INBOX for new msgs?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm running the 1.5rc2 available on the front page of mozilla.org. I'll send you the info as soon as I collect it. IMAP on the WAN has been working well for the last 10 minutes. Of course it would.
Comment on attachment 132552 [details] log of IMAP mail session I have email configured to check all my accounts for new mail at startup and every 10 minutes but only the INBOXes. Attached is a log file. The sort is newest message at top; The failure wasn't too bad this time. I marked an email as junk, but it was not deleted as it should have been. It was the first message in the list of emails. I tried to load the next (2nd) message; it would not load. I tried to load the message the 3rd message and it loaded even though it was the largest of the bunch. The forth message would not load but the fifth one did. Then I got the forth one to load. By going back and forth between the messages, I can sometimes get to read all my email without haveing to exit mozilla and start again.
this part of your log is very odd. It looks like we're trying to create a bunch of different protocol objects/connections to the server after the create of the trash failed. I don't know if it's related or not. We shouldn't be trying to create the trash folder but I think we get confused because we're getting back .mail/Trash/ instead of .mail/Trash. Do you have other imap accounts on the same server? Is your LAN account different from your WAN account? 7173[8f14d28]: 9007990:mail.grifent.com:A:CreateNewLineFromSocket: 5 OK LIST completed 7173[8f14d28]: 9007990:mail.grifent.com:A:SendData: 6 create ".mail/Trash" 7173[8f14d28]: ReadNextLine [stream=8f15428 nb=0 needmore=1] 7173[8f14d28]: ReadNextLine [stream=8f15428 nb=78 needmore=0] 7173[8f14d28]: 9007990:mail.grifent.com:A:CreateNewLineFromSocket: 6 NO CREATE failed: Can't create mailbox .mail/Trash: mailbox already exists 9222[8545b00]: ImapThreadMainLoop entering [this=9459680] 1024[80ae868]: 9459680:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 9222[8545b00]: 9459680:mail.grifent.com:NA:ProcessCurrentURL: entering 9222[8545b00]: 9459680:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 9222[8545b00]: 9459680:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 9459680:mail.grifent.com:NA:TellThreadToDie: close socket connection 10248[93e6a48]: ImapThreadMainLoop entering [this=94675a8] 1024[80ae868]: 94675a8:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 10248[93e6a48]: 94675a8:mail.grifent.com:NA:ProcessCurrentURL: entering 10248[93e6a48]: 94675a8:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 10248[93e6a48]: 94675a8:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 9459680:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 94675a8:mail.grifent.com:NA:TellThreadToDie: close socket connection 11273[9412d30]: ImapThreadMainLoop entering [this=9469660] 1024[80ae868]: 9469660:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 11273[9412d30]: 9469660:mail.grifent.com:NA:ProcessCurrentURL: entering 11273[9412d30]: 9469660:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 11273[9412d30]: 9469660:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 9459680:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 94675a8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 9469660:mail.grifent.com:NA:TellThreadToDie: close socket connection 12298[945bdf0]: ImapThreadMainLoop entering [this=946b3f8] 1024[80ae868]: 946b3f8:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 12298[945bdf0]: 946b3f8:mail.grifent.com:NA:ProcessCurrentURL: entering 12298[945bdf0]: 946b3f8:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 12298[945bdf0]: 946b3f8:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 9459680:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 94675a8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 9469660:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 946b3f8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 9459680:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 94675a8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 9469660:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 946b3f8:mail.grifent.com:NA:TellThreadToDie: close socket connection 9222[8545b00]: ReadNextLine [stream=945beb8 nb=0 needmore=1] 10248[93e6a48]: ReadNextLine [stream=9411680 nb=0 needmore=1] 11273[9412d30]: ReadNextLine [stream=93a31a8 nb=0 needmore=1] 12298[945bdf0]: ReadNextLine [stream=93a4d40 nb=0 needmore=1]
I looked at the .mailboxlist file in my home directory on the Internet server. It had two Trash entires, Trash and .mail/Trash/ . .mail/Trash is a plain file, so it should not have had the trailing slash. I hand edited the file removing the Trash entry and removing the trailing slash from the .mail/Trash entry. I had tried to have Trash be a directory so that I could trash directories, but either I did something wrong or the uw_imap server is compiled to not allow plain files and folders with the "same" name to accept both plain files and directories. When I changed it back to a plain file, appaerntly .mailboxlist didn't get cleaned up. No, my LAN and WAN accounts are different accounts on different servers.
yes, it sounds like the UW server isn't allowing folders to both contain messages and sub-folders - that's its default behaviour, I believe. But you should be able to tell that from your normal folders as well...I couldn't quite tell, did editing your .mailboxlist make any difference in Mozilla's behaviour? Could you attach another protocol log of a session with .mailboxlist having .mail/Trash?
Yeah, normal folders act that way too. I think there is a run time switch to change the behavior, but I haven't really researched it yet. Editing the .mailboxlist did not help. I had already started this session of mozilla and read the mail before I read your request for another log file. I'll get you one next session.
Attached file IMAP log file part 1 —
I have noticed that the problem seems to manifest itself primarily when deleting the first message in the list. That is not a "scientific" analysis, but an observation. I had to break the file into two attachments since Bugzilla said the file is too big.
Attached file IMAP log file part 2 —
Attachment #132628 - Attachment description: IMAP log file → IMAP log file part 1
once you get stalled, does clicking get new msgs for that account unstall the delete/load msgs? I believe what's happening is you are running into a problem in the code that prevents multiple connections to the same folder - when you attempt an operation on a folder that is "busy", we queue the operation, and play it back when the previous operation is finished. It seems like that play back can get missed, effectively stalling. Get new msgs runs a new url and when it's finished, plays the next queued operation. I'll try to add some logging that indicates when an operation gets queued, and when a queued operation is played back.
this weirdness is still happening - if I add some more logging to 1.6 that helps me figure out what's going on, will you be able to try a 1.6 build? 10247[92de950]: ImapThreadMainLoop entering [this=94c71d8] 1024[80ae868]: 94c71d8:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 10247[92de950]: 94c71d8:mail.grifent.com:NA:ProcessCurrentURL: entering 10247[92de950]: 94c71d8:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 10247[92de950]: 94c71d8:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 94c71d8:mail.grifent.com:NA:TellThreadToDie: close socket connection 11272[9632ac8]: ImapThreadMainLoop entering [this=946b4d0] 1024[80ae868]: 946b4d0:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 11272[9632ac8]: 946b4d0:mail.grifent.com:NA:ProcessCurrentURL: entering 11272[9632ac8]: 946b4d0:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 11272[9632ac8]: 946b4d0:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 94c71d8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 946b4d0:mail.grifent.com:NA:TellThreadToDie: close socket connection 12297[93cbbf0]: ImapThreadMainLoop entering [this=96297c8] 1024[80ae868]: 96297c8:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 12297[93cbbf0]: 96297c8:mail.grifent.com:NA:ProcessCurrentURL: entering 12297[93cbbf0]: 96297c8:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 12297[93cbbf0]: 96297c8:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 94c71d8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 946b4d0:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 96297c8:mail.grifent.com:NA:TellThreadToDie: close socket connection 13322[96390d0]: ImapThreadMainLoop entering [this=9633048] 1024[80ae868]: 9633048:mail.grifent.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 13322[96390d0]: 9633048:mail.grifent.com:NA:ProcessCurrentURL: entering 13322[96390d0]: 9633048:mail.grifent.com:NA:ProcessCurrentURL: creating nsInputStreamPump 13322[96390d0]: 9633048:mail.grifent.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 1024[80ae868]: 94c71d8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 946b4d0:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 96297c8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 9633048:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 94c71d8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 946b4d0:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 96297c8:mail.grifent.com:NA:TellThreadToDie: close socket connection 1024[80ae868]: 9633048:mail.grifent.com:NA:TellThreadToDie: close socket connection 10247[92de950]: ReadNextLine [stream=90b9998 nb=0 needmore=1] 11272[9632ac8]: ReadNextLine [stream=9638a08 nb=0 needmore=1] 12297[93cbbf0]: ReadNextLine [stream=9298a20 nb=0 needmore=1] 13322[96390d0]: ReadNextLine [stream=9628e08 nb=0 needmore=1]
I can try a 1.6 build, but with 1.5 on the way to final this would be a fairly serious bug to get into a final build.
yes, I agree, but we have to find a fix at this point, and that can only happen in 1.6
Status: NEW → ASSIGNED
Let me know when you have the debug in a build. I'll pick it up and install it.
Sorry. I have not built Mozilla from source. As much as I would like to help, I really can not take the time to do the build. If you can put this into a nightly build binary install, then I will be more than glad to test the new build. I know this is not what you want to hear, but it my reality.
John, I don't need to you to build mozilla from scratch. I'm sorry if I gave that impression. I've checked that patch in and you can download tomorrow's build and generate a log.
I can help too - I've seen some of this stalling...
Here's what I expect to learn from the new logging: 1. What kind of url is being run when you get all those goofy connections that get shut down immediately. 2. Whether urls are getting queued but not dequeued. I added a log entry for every url that gets queued, and for every url that gets taken off the queue and run.
the only patterns I've noticed so far are: 1) certain junk (spam) mail seems to cause the connection to drop 2) the connection seems to get slower over time - and once or twice I've gotten errors about having too many connections - almost as if we're not closing connections, or opening multiple connections to the same mailbox? The error is quite rare (maybe 2x in the last 3 months), but the slowdown is common for me...
Alec, you're going to turn on logging, right? It will tell us if the connection is dropped, and if it's the client that's dropping the connection, why. As far as connections are concerned, we will keep open/cache up to 5 connections, but you can change that in your imap server account settings.
This happens to me too. I didn't keep track when it started, but it's not a recent regression. I'll try to generate some logs later today.
Bogdan, unless you're going to download and build the source yourself, it would be better if you could download tomorrow's bits and generate a log with them.
I can do that! I'll get tomorrows build and collect the log.
I use nightly builds, so I'll check the latest builds tomorrow. And I use Mozilla on WinXP, so the OS flag should be changed from Linux to All.
OS: Linux → All
I believe that behavior started in the 1.4 nightlies. It happens to me quite a lot while working with fastmail.fm through a ADSL connection. This most commonly happens while mozilla is checking new messages for junk. Many times it marks part of the junk messages as junk and then just hangs, never moving them to the junk folder. Following this it is impossible to use the IMAP account until I exist and reopen mozilla.
Loaded 1.6 nightly. Sorry for the day delay. The performance seems much improved in this version, but it also was a different time of day. No kids on the Internet in our area since it was during school hours when I did the testing. Log file is in two parts. I am reverting back to 1.5rc2 for now. Mozilla 1.6 and MultiZilla, which I like are not playing nicely together. I think it is a bug in MultiZilla which I will report, but that is a different topic. I will be glad to try 1.6 again at any time; same version or a new one.
Part 2.
Attached file IMAP log —
During the session that is logged here the following events happened: - first message is shown; - I move to the next message (e-mail from eCost); - it took a long time (tens of seconds) until this e-mail was shown; if I click another message meanwhile nothing happens (it should cancel the current operation and show me the message I selected); - after this I have another two new messages that I cannot see; if I click on them nothing happens: it doesn't show that is downloading anything (in download bar, or in the upper right Mozilla icon); if I doubleclick on them an empty window is opened; the messages remain marked as un-read; if I close and start again Mozilla Mail the problem persists; sometimes I can solve it by exiting Mozilla altogether and starting it again; sometimes I just have to use another mail reader;
Bogdan, thx for the log. It looks to me like this is a race condition in the url queuing stuff - the message fetch got queued, but the delete operation for that message got to go first, and the message fetch had to wait for several other operations to happen before getting run. I don't know what kind of imap server you're using (that info is at the top of the log, but you've left that out to focus on the problem area). Also, when we're fetching the deleted e-cost message, we are fetching it in chunks, and it could be the server is very slow fetching deleted messages in chunks, or it could just be that the url queue is stalled. I might need to put time stamps in the log so I can get a better idea of how long it's taking between commands.
Here is the log with the ID of the server. I don't think the server is slow, but I will try to test this somehow.
I'm seeing some of the same stuff. Sometimes deleting or just viewing an mail is impossible since Mozilla Mail seems to be buzy. I have 5 IMAP account in my profile.
from Bogdan's log, it looks like we're queueing urls but never playing them back - otherwise there would be an entry in the log starting off with "playing" when we playback a url. I'll need to add more logging to figure out why we're not playing back queued urls, or try to reproduce it on my end. Henrik, you could generate a log and see if the same thing is happening to you.
I have the same kind of trouble, especially when using WiFi (clearly, it's all packet loss related; doesn't IMAP work over TCP?). (message display, mark unread, delete, move silently failing). I'm pretty sure I never saw these problems when I first started using Mozilla around v 1.1. I'm running nightly/latest-1.5 from a few days ago. Server is Cyrus (fastmail.fm - free IMAP test accounts available). I have logging turned on, if anyone wants more dumps/extracts. Adding dataloss, because copying Sent Items to INBOX.Sent Items on send often fails, and even the send itself sometimes silently fails. (Well, actually, the latter should probably be a separate bug, as it's not IMAP related!)
Keywords: dataloss, nsCatFood
if anyone wants to try tomorrow's build, I've added a logging statement when urls are doomed - i.e., queued urls are removed from the queue because we think there has been an error on the channel. I don't believe this should be happening in normal circumstances, but if it does show up in the log, then I know where to drill down.
From some debugging, I see that we will doom a url if we load a message in the doc shell while another message is getting loaded - I remember this being a problem before. I don't know if that's what's happening to the users who are having problems, because from some little testing, it doesn't seem to cause problems here.
in this session I open my inbox, I see and delete the first message (id = 101), then it moves to the next one, which I never get to see; it shows "downloading" status and nothing happens; I mark it as deleted and the focus is moved to the next message (99) which I cannot see; I go to another message (94) and then back to 99 which I can see now; then I try again to see message 100, no luck this time either;
I thought I would pass this along. This was not happening in Mozilla 1.3.1. It does happen in Mozilla 1.4, and of course, I reported this against Mozilla 1.5rc2. Not having delved into the code, I don't know whether this is a complete rewrite or incremental changes. If it is incremental, this should help. If it was a rewrite in 1.4, then I am sure this is of little value. Also, the problem is much, much worse when there is a lot of email and numerous folders.
Clarification: I'm seeing message display, mark unread, delete, move SILENTLY FAILING; the reporter is seeing mozilla HANG. John G: What hangs exactly? The browser and mail windows become completely unresponsive (so even File | Exit is impossible), or something less severe? It seems Heinrich, Bogdan Stroe (in comment 39) are also seeing silent failures, not hangs. What IMAP server software (Cyrus? UW? Novell? Courier) are folks using? (UW for JohnG, Cyrus for me.) I couldn't find this info in the logs; not sure what I should be looking for.
Less severe. The email for the imap accounts, once the connection hangs, just sits there with a message. Sometimes it is moving message to trash and sometimes it is loading message. The connection can often be cleared by trying to load a different message and coming back to the one that did not load later. Sometimes I have to exit Mozilla completely in order to clear the connection. My wife uses Mozilla 1.4. Her IMAP account got so hung she could not delete any messages. She would delete some or the system would delete some as junk and they would come right back to her inbox. It was very strange. I finally switched her from an imap account to a pop account because she was so frustrated. I even had problems with the pop account; it could not get a lock. Even when I exited Mozilla completely, there was still an imapd process on the server servicing her imap account. I know because I run the mail server too. It is my domain. After I killed the process, the pop account was able to log in. I just loaded Mozilla 1.5 final and it, obviously, still has the bug. What ever was done to the code between 1.3.1 and 1.4 seems to be the culprit as 1.3.1 worked just fine. I understand the new code is supposed to be faster, but when it hangs it is actually slower. Speed is good. Reliable is better. Just my opinion.
the faster code is only in 1.6, not 1.5, so it's not directly related to this problem. I think Ere and I are augering in on where it's failing. I'm going to check in yet more logging and once more ask those of you that can reproduce this easily to generate a new log with the next build.
I've checked in some more logging, so a build from tomorrow will have more informative logs.
Just had something weird happen. I marked an email as junk. Even though the junk control is set to delete a message when I mark it junk, it did not delete which is often the case with the new IMAP. Then I used the menu item delete all message marked as junk. The message was deleted from the list of email, but the next email header came up in the message disply window, but the deleted message body displayed instead of the one for the header. Of course I did not catch this on a log since I am waiting for a new nightly after 10/17. The latest as of this morning 10 EDT 10/18 is a nightly from 10/16.
Another log using the 10-18-2003 build. The server I connect to is sometimes slow, but this shouldn't make Mozilla to have these problems. In this session I still have problems moving from a message to another; I also marked some messages as "deleted", and I saw them after a couple of seconds as "read", but not "deleted". The good part is that I didn't have any messages that I couldn't see at all. I don't know if the last patch addressed this issue, or I was just lucky.
The build from 10-18-2003 hangs when I close Mozilla Mail; the other browser windows do not respond, and I have to kill the process; no talkback is generated.
Attached file part one of imap log —
Using this build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031019 I had no apparent problems. That may be due to the lack of Internet traffic because of the Redskins footbal game and the World Series on TV. Or, it may be that the bug is fixed. Did notice that the Junk mail controls did not mark or move any mail to Junk although there was a lot of Junk mail. When I marked them junk, they were deleted as they should have been. The log is in two parts.
Attached file part two of IMAP log —
If there were changes to the code to fix the problem, I hope they get rolled into a 1.5.1 build. It will also be interesting to see if the problem is still fixed when all the logging is off. I know that timing issues are often not found when there is a lot of logging since it changes the timing of the code segment.
Attached patch potential fix — — Splinter Review
I think this patch should help - I believe we were killing off new protocol threads as quickly as we could make them in some race conditions. The code that I added to see if transports were still alive before re-using them was responsible for adding this race condition: PRBool isAlive; rv = m_transport->IsAlive(&isAlive); + // if the transport is not alive, and we've ever sent a command with this connection, kill it. + // otherwise, we've probably just not finished setting it so don't kill it! if (NS_FAILED(rv) || !isAlive) { TellThreadToDie(PR_FALSE); I think we'd get a transport, but it wouldn't be "alive" yet. So I added a check that we'd actually used this protocol object by checking if m_currentServerCommandTagNumber > 0. Actually, != 0 is probably a better check but this will work in normal situations.
I've checked in this patch - Ere has run with it and not had any problems so far. His protocol log looks a lot better too. If you want to try tomorrow's 1.6 build, it might have this fixed. If this fix is good, I'd like to try to get this into a 1.5.1 build, whenever plans for that start.
I can confirm that my tip build works w/o any problems now. Thanks David!
Another 'Confirm' on a current (yesterday's) Linux CVS trunk build: none of the IMAP lockup problems I have seen before, and no new difficulties so far.
marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
20031020 works much better for me too, IMAP-wise. Still, I just selected "File|Offline|Download/Sync now..." and Mozilla is just sitting there displaying "Connected to mail.messagingengine.com..." It hasn't hung, it just didn't do a sync; network monitoring confirms this. This bug isn't new to this build. I tried "Download/Sync now..." again and this time it started working, but didn't finish - it didn't go offline. Looking for a pattern. There are no errors in the log (a grep (err find, actually - on windows) for "NO" turns up no errors; windows editors (word/notepad/wordpad/edit) are lousy at handling 50 or 250mb log files. I tried "Download/Sync now..." a third time and this time it started working, but didn't get far and didn't finish - it didn't go offline. A fourth try worked fine. Anyone mind if I reopen? Or should I verify and start a new bug?
please open a new bug for the offline stuff - there's no compelling evidence that it's the same problem, yet. And please attach an imap protocol log to the new bug (or e-mail it to me if it's too big or too private :-) )
I created Bug 223115 but then I marked it a duplicate of Bug 142278. Hope the new log from the last build I just emailed to Bienvenu helps. Copying messages to sent items folder seems more reliable too, though it's so hard to know with these intermittent bugs.
It looks good for me too. If I'll see any more problems I'll report them here. Good work, I think this was an important issue.
Looks good here too. Thanks for the effort.
thx for everybody's help with the protocol logs and testing new builds.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: