239802 - Trouble with IDLE and readonly mailboxes with uw-imapd

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Ere Maijala (slow)]

I haven't really has time to investigate this enough, but I have a bad feeling
IDLE support is breaking uw-imapd kiss of death. Since the IDLE support landed,
I've had trouble with seen flag not sticking. Now I have Mozilla running at home
and work, and at work uw-imapd can't get a mailbox lock at all and opens the
mailboxes read-only. 

The fact that Mozilla doesn't handle read-only mailbox makes it even worse as
there's no way to see that whatever I do now will be forgotten.

I'm running uw-imapd 2003.338rh on RedHat Linux 9.

Comment 1

[Ere Maijala (slow)]

If this isn't just something in my setup, it will cause a lot of trouble for
users. Nominating for 1.7.

Comment 2

[David :Bienvenu]

Ere, does your UW server support IDLE, and if so, can you try turning off the
Mozilla flag that makes us use IDLE? I believe there's UI for it in the advanced
imap server prefs. Also, a protocol log from both machines might be interesting.
But if it's really just broken on the server, I'm not sure what the client can
do, other than give you an option not to use IDLE 

Comment 3

[Ere Maijala (slow)]

Yes, it does support IDLE. I'll play around a bit to see if it happens every time.

Comment 4

[Ere Maijala (slow)]

Imap logs sent via private mail. If there is one connection IDLE on the server,
another can't gain read-write access (the kiss of death is not issued). Turning
of IDLE support from Mozilla helped, but as it's on by default, it might cause
some trouble for many. 

Comment 5

[David :Bienvenu]

If I undersand correctly, this would seem to be a UW IMAP IDLE behaviour, and we
should definitely release note it. From what I can tell, this is not a client
bug, per se. We should try to put up an error message. But, I don't think we
should turn off IDLE support by default for all users because UW IMAP users who
use IMAP on two different machines simultaneously will have this problem..

Just so I understand, in the log you sent me, it looks like you'd already turned
off client-side IDLE support for that server, since we never went IDLE with it,
and we had our connection kicked off several times.

The release note would read something like:

If you access a UW IMAP server that supports the IDLE extension from two
different clients/machines simultaneously, and you start having problems with
flag changes not sticking (e.g., deleted messages come back, and read messages
become unread again), then you should turn off IDLE support in the Mozilla
client. Go into the client advanced imap server settings and turn off IDLE support. 

Comment 6

[Ere Maijala (slow)]

I probably sent the wrong log, sorry. Anyway, the behavior was consistent. I
guess relnote is ok. 

Comment 7

[Ere Maijala (slow)]

Whoops, I probably missed the real problem in the logs. I think it's not really
uw imapd's problem. The problem is that while Mozilla is IDLE and it receives
the line "* BYE Lost mailbox lock", it tries to issue DONE. Then the connection
dies and Mozilla reopens it immediately. The other connection that tried to get
the mailbox lock either doesn't have time to even get it or loses it immediately
again. In the worst case this could cause a serious race issue. 

I think Mozilla shouldn't try to reconnect if the connection is closed while
IDLE before it's biff time.

Comment 8

[David :Bienvenu]

Can you send me a log that shows that? I think we issued the DONE because we had
a url to run but the log will show for sure.

Comment 9

[Ere Maijala (slow)]

Log sent via email. I don't think it's a coincident as it happens every time the
server closes the connection.

Comment 10

[David :Bienvenu]

The log just shows that we reconnect to the inbox at some point after we get
kicked off - but for all I can tell, that could just be "check for new mail"
firing at some point in the future. If you turn off check for new mail, does
this still happen?

Comment 11

[Ere Maijala (slow)]

The reconnection happens _immediately_ after the disconnection. I watched the
log with 'tail -f' for quite a few times. I'll try to disable new mail check to
see if it makes any difference, but it's not a solution..

Comment 12

[Ere Maijala (slow)]

Didn't help, Mozilla still reconnects immediately. 

Comment 13

[Ere Maijala (slow)]

Attachment: Patch v1

I took the liberty to check what's happening in the code. I noticed that after
handling the idle response in nsImapProtocol::HandleIdleResponses(),
|m_imapMailFolderSink->OnNewIdleMessages();| is called unconditionally. Adding
a check to see if we're still connected seems to help. At least the comment
says that OnNewIdleMessages() must run an url, which would cause the connection
to be re-established.

Comment 14

[Ere Maijala (slow)]

Comment on attachment 145679 [details] [diff] [review]
Patch v1

David, what do you think?

Comment 15

[David :Bienvenu]

Comment on attachment 145679 [details] [diff] [review]
Patch v1

d'uh, of course! That's what's happening.

Comment 16

[chris hofmann]

Comment on attachment 145679 [details] [diff] [review]
Patch v1

a=chofmann for 1.7

Comment 17

[David :Bienvenu]

fix checked in, thx!

Comment 18

[David :Bienvenu]

fixed.

Comment 19

[Ere Maijala (slow)]

Very good, thanks :)

Comment 20

[David :Bienvenu]

*** Bug 238915 has been marked as a duplicate of this bug. ***