Closed Bug 517256 Opened 11 years ago Closed 11 years ago

Autosync sometimes quits

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0rc1

People

(Reporter: davida, Assigned: Bienvenu)

References

Details

(Keywords: qawanted, Whiteboard: [no l10n impact])

Attachments

(3 files, 2 obsolete files)

I'm finding that autosync fails after a while, and never recovers.  I have captured some IMAP logs, that I'll share with bienvenu when he's back.

If it's frequent enough (and doesn't just happen to me), I fear this may need to block.
Flags: blocking-thunderbird3?
Whiteboard: [no l10n impact]
Keywords: qawanted
BTW: The way I can tell is that I use glodaQuilla, and show the "onDisk" column, which shows a green dot for downloaded messages.  When autosync works, those green dots show up quickly (on an IDLE-enabled IMAP server).  When autosync fails (my diagnosis, so...), the green dots stay sad, small, and grey.

I'd love to hear from others about their autosync experience.
(In reply to comment #1)
> BTW: The way I can tell is that I use glodaQuilla, and show the "onDisk"
> column, which shows a green dot for downloaded messages.  When autosync works,
> those green dots show up quickly (on an IDLE-enabled IMAP server).  When
> autosync fails (my diagnosis, so...), the green dots stay sad, small, and grey.
> 
> I'd love to hear from others about their autosync experience.

I get this too. Most often when I'm composing a message and something happens in the background (new mail or otherwise). This must have occurred post b3, as I only noticed it in the past few weeks.
and also like to add that i could tell from using Glodaquilla - kudos to Wayne for letting me know about its usefulness. ;-)
As I'm not the only one...
Flags: blocking-thunderbird3? → blocking-thunderbird3+
related to imap copy/move? 

everything in my incoming bugmail folder is on disk. but stuff in at least two folders, that only get messages from that folder by me doing d&d, have many messages not on disk.
Attached file autosync log
the tail end is where there's interesting stuff, i suspect.
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
Attached patch add ImapAutoSync PRLog module (obsolete) — Splinter Review
This patch adds an PRLog module, ImapAutoSync, and fixes an issue where deleted messages could end up in the download q, with a size of 0. It has some other unrelated wip stuff - I'm mostly attaching it for davida to try out. I haven't verified that logging works in release mode, though I think it should.
Turns out this patch doesn't fix the size 0 issue...
this makes auto sync logging a pr log module so release builds can do logging, and does a bit of cleanup of the queue, but I doubt it fixes the underlying problem. It should help diagnose the underlying problem, which is why I'd like to land it relatively soon.
Attachment #403027 - Attachment is obsolete: true
Attachment #403104 - Flags: superreview?(bugzilla)
Attachment #403104 - Flags: review?(bugzilla)
Attachment #403104 - Flags: superreview?(bugzilla)
Attachment #403104 - Flags: superreview+
Attachment #403104 - Flags: review?(bugzilla)
Attachment #403104 - Flags: review+
Attachment #403104 - Attachment description: add a bit of logging, clean out deleted messages from queue → add a bit of logging, clean out deleted messages from queue - checked in, with an other change I had, don''t try to autosync no select folders
what I see from logging and a little debugging is that folders are put into the download q, and we figure out which messages to download, but they're not always put into the priority queue, and thus don't get downloaded on idle. It may be that we haven't updated the folder and thus downloaded new headers - I'm not quite sure how all these different queues work.
Attached patch possible fix (obsolete) — Splinter Review
the code seems backwards - with this patch, we download folders once we detect they have new headers, which seems to be the desired behavior, at least to me.
I'm thinking that state check just needs to go away...but I'm still trying to understand the code.
This relaxes the auto sync state checking completely...
Attachment #404327 - Attachment is obsolete: true
Comment on attachment 404605 [details] [diff] [review]
an other possible fix

davida hasn't had issues w/ this patch so far.

Besides removing the restriction on when we'll download for autosync, I also removed the silly log statement where we add 0 messages to the queue. And I added logging about the sync state transitions, and made all the code that wants to change the state go through the setter, so it'll get logged.
Attachment #404605 - Flags: superreview?(bugzilla)
Attachment #404605 - Flags: review?(bugzilla)
Whiteboard: [no l10n impact] → [no l10n impact][has patch for r/sr standard8]
Attachment #404605 - Flags: superreview?(bugzilla)
Attachment #404605 - Flags: superreview+
Attachment #404605 - Flags: review?(bugzilla)
Attachment #404605 - Flags: review+
Whiteboard: [no l10n impact][has patch for r/sr standard8] → [no l10n impact][ready to land]
Target Milestone: --- → Thunderbird 3.0rc1
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][ready to land] → [no l10n impact]
Duplicate of this bug: 522688
You need to log in before you can comment on or make changes to this bug.