215371 - long freeze when Mozilla Mail loses connection to IMAP server and reconnects memory is leaked in stairway to heaven pattern

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Aleksander Slominski]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

freezez and leaks around 100MB during 60 seconds
when IMAP/SSL conneciton is lost

Reproducible: Always

Steps to Reproduce:
1. use IMAP server over SSL with 10+ folders and thousands of messages
2. waituntil mozila loses connection
3. when reconnecting by doing offline/online mozilla freezes for dozen seconds
(around 40-60secnds inmy case)

Actual Results:  
memory usage increased by about 100MB

Expected Results:  
do not leak memory

after restarting mozilla memory is reclaimed
thesameproblemis in current Thunderbird 0.1

Comment 1

[Aleksander Slominski]

Attachment: example of stairway to heaven effect

captured on windows XP SP1 after  mozilla froze for 40 seconds
when reconnecting to IMAP server

Comment 2

[David :Bienvenu]

I'll look into it. Why does Mozilla lose the connection? And you shouldn't need
to go offline+online again to re-establish the connection, because I put in some
code that 99% of the time should detect when the server has dropped the
connection...

Comment 3

[Aleksander Slominski]

i am at remote location accessing my univesity email 
account using SSL but i think i had the same problem 
in past when i was at university. i am surprised nobody has
reported this problem before - i waited until mozilla 1.4 is
final bit nothing chnaged and moreover i checked that the
same problem is with thunderbird 0.1.

also sometimes switching mozilla mail online/offline 
will lead to the same behavior: mozilla mail client freezes
and memory increase in stairway pattern.

Comment 4

[David :Bienvenu]

Attachment: proposed fix

I believe the bloat is from opening all the mail db's for folders that might
have offline events to try to playback offline events, but not closing them.
The locking up of the UI is probably because we were opening the db's for
folders that were merely configured for offline use, but didn't have a flag set
saying they had offline events. If there were several large folders like that,
we'd end up opening them synchronously, because it's the playing back of
offline events that introduces asynchronicity.

I need to convince myself that it's OK to only look at folders with the
OFFLINE_EVENTS flag set. I believe it is, and it would be a performance win if
you have lots of large folders configured for offline use, but don't often have
offline events in them.

Comment 5

[David :Bienvenu]

Attachment: proposed fix, v2

No need to clear the msg database in two places.

Comment 6

[(not reading, please use [e-mail] instead)]

Comment on attachment 129369 [details] [diff] [review]
proposed fix, v2

r/a=sspitzer for 1.5 beta

Comment 7

[David :Bienvenu]

fix checked in.

Comment 8

[Aleksander Slominski]

that is great! 

thanks!