Per Bug 409259, I'm having a problem where the increase in timeout after 2400 messages is not alleviating the problem for moving large messages or large numbers of messages on a slow server. The issue is that for less than 2400 messages, a move is still taking more than 60 seconds, and the move fails, the folder caches the failed command, and repeats the command on next visit to the source folder. I would like to request the following changes: 1) I would like to have the dynamic IMAP timeout code modified to account for message size (since an IMAP move is really a copy and then a delete). So for example, timeout would be the greater of 60 seconds, 40 messages/second, or 5 Mb/second. 2) Invariably some folks will have slower mail servers than others. It would be useful to have access (via preference) to be able to change these assumed values to compensate for slow servers. This could be as simple as a pulldown or checkbox for slow server (e.g. change timeout minimum to 5 minutes, dynamic at 5 messages/second, or 1Mb/second), or allow for access to each individual setting.
Component: General → Networking: IMAP
OS: Windows Server 2003 → All
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Hardware: x86 → All
Target Milestone: --- → Thunderbird 3.0b3
Version: Trunk → 1.9.1 Branch
Severity: normal → enhancement
Flags: blocking-thunderbird3? → wanted-thunderbird3?
Target Milestone: Thunderbird 3.0b3 → ---
Please ignore item 2) in the description, I've filed that as a separate enhancement request, bug 493264.
Severity: enhancement → normal
Item 1) can do nothing for "long search command" and 2many mails for fetch 1:* flags(...)" like case. Just an idea for "Dynamic IMAP Timeout Adjustment V 0.0.1", mainly for slower server than default timeout value. (1) If timeout occurred and retry is needed, mail.server.serverN.timeout = 2 * mail.server.serverN.timeout; GOTO step (3). (2) If retry is not needed, and if operation was search, fetch for many mails, copy of many mails, ..., serverN.timeout = 1.2 * mail.server.server; EXIT; (3) Executes retry. (4) If timeout again, issue dialog. "Wait for more time? Or Cancel&retry with increased timeout?, Or Cancel?", with information about operation(server,folder,command,...), retry count, and timeout value. "Dynamic IMAP Timeout Adjustment V 0.0.2". - Number of mails per uid copy command etc. - Total mail size per uid copy command etc. "Dynamic IMAP Timeout Adjustment V 0.0.3". - Calculate "Speed" or "Performance", and reflect it to parameter adjustment. "Dynamic IMAP Timeout Adjustment V 0.0.4". - Heuristic parameter adjustment, based on history.
I believe I had suggested this in the fix for Bug 409259, but in the spirit of setting a dynamic timeout, how about this idea: (5) Execute the operation on the first 100 messages and calculate performance from these. Set timeout to 2*(# of messages/calculated rate)+ X seconds and move remaining messages, where X is a minimum timeout. Even if there is an overhead on operating on larger #s of messages, this should compensate. or (6) Execute operation in blocks of 100, each with 60 second timeout.
(In reply to comment #1) > Please ignore item 2) in the description, I've filed that as a separate > enhancement request, bug 493264. Michael, If I read this correctly the bug summary is no longer accurate. please adjust the summary to match what you want in comment 0 item #1.
See Also: → bug 409259
Summary: Need way to adjust IMAP timeout to compensate for slow servers and large emails → Need to adjust IMAP dynamic timeout algorithm to compensate for both slow servers and large emails
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Depends on: 409259
Summary: Need to adjust IMAP dynamic timeout algorithm to compensate for both slow servers and large emails → Adjust IMAP timeout dynamically, using algorithm to compensate for both slow servers and large emails
You need to log in before you can comment on or make changes to this bug.