Here's a new try build for my latest proposed fix: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=844778fe36027adeb1c6f672e392f1ca20f43234 I found a way to not check for and possibly trigger a discovery on every URL but instead cause the discovery to occur in its own URL and (usually) in its own thread. Every IMAP connection to a mailbox (folder) begins with the select URL. This triggers a chain of imap commands that occur before the actual imap select (capability, starttls, id, select and eventually list) and, if this is the first select, the discovery occurs from parsing imap list command responses. My proposed change is to trigger a discovery URL right after the first select url. This causes the discovery to occur in parallel with the select and fetch, avoiding the delay in downloading the message that Richard sees. I've kept the lock-outs so that a discovery URL is not done after the select if a discovery for the account has already occurred or if one is already in progress from another select to avoid redundant list responses and parsing. This seems to work as I hoped and and a message can be fetched and read while the discovery is in progress on my 5000 folders/mailboxes, unlike before. I haven't tried it yet, but this change should also work on initial folder discovery after a new account is created. This is because an initial imap select on Inbox will occur and, since no discovery has occurred yet, the discovery URL should occur at this time on a new thread/connection as it does on TB startup with my change. One possible issue for users who change the default number of cached imap connection from default 5 down to 1 is that it won't be possible for the discovery URL triggered after the initial select URL to obtain its own thread. It will have to wait for the select chain of commands to complete on the single thread before it can become active. So subsequent activity on the single imap thread will be blocked while discovery completes. I haven't tried or tested this yet either. Richard, if you could test the new try build on your setup it would be great. Thanks!
Bug 163964 Comment 46 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Here's a new try build for my latest proposed fix: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=844778fe36027adeb1c6f672e392f1ca20f43234 I found a way to not check for and possibly trigger a discovery on every URL but instead cause the discovery to occur in its own URL and (usually) in its own thread. Every IMAP connection to a mailbox (folder) begins with the select URL. This triggers a chain of imap commands that occur before the actual imap select (capability, starttls, authenicate, id, select and, with the original code, list) and, if this is the first select, the discovery occurs from parsing imap list command responses. My proposed change is to trigger a discovery URL (list) right after the first select url and no longer trigger a list (discover) from the select URL. This causes the discovery to occur in parallel with the select and fetch, avoiding the delay in downloading the message that Richard sees. I've kept the lock-outs added in the previous try build so that a discovery URL is not done after the select if a discovery for the account has already occurred or if one is already in progress from another select to avoid redundant list responses and parsing. This seems to work as I hoped and and a message can be fetched and read while the discovery is in progress on my 5000 folders/mailboxes, unlike before where the message would only appear after the discovery finished. I haven't tried it yet, but this change should also work on initial folder discovery after a new account is created. This is because an initial imap select on Inbox will occur and, since no discovery has occurred yet, the discovery URL should occur at this time on a new thread/connection as it does on TB startup with my change. One possible issue for users who change the default number of cached imap connection from default 5 down to 1 is that it won't be possible for the discovery URL triggered after the initial select URL to obtain its own thread. It will have to wait for the select chain of commands to complete on the single thread before it can become active. So subsequent activity on the single imap thread will be blocked while discovery completes. I haven't tried or tested this yet either. Richard, if you could test the new try build on your setup it would be great. Thanks!
Here's a new try build for my latest proposed fix: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=844778fe36027adeb1c6f672e392f1ca20f43234 I found a way to not check for and possibly trigger a discovery on every URL but instead cause the discovery to occur in its own URL and (usually) in its own thread. Every IMAP connection to a mailbox (folder) begins with the select URL. This triggers a chain of imap commands that occur before the actual imap select (capability, starttls, authenicate, id, select and, with the original code, list) and, if this is the first select, the discovery occurs from parsing imap list command responses. My proposed change is to trigger a discovery URL (list) right after the first select url and no longer trigger a list (discover) from within the select URL chain. This causes the discovery to occur in parallel with the select and fetch URLs, avoiding the delay in downloading the message that Richard sees. I've kept the lock-outs added in the previous try build so that a discovery URL is not done after the select URL if a discovery for the account has already occurred or if one is already in progress from another select to avoid redundant list responses and parsing. This seems to work as I hoped and and a message can be fetched and read while the discovery is in progress on my 5000 folders/mailboxes, unlike before where the message would only appear after the discovery finished. I haven't tried it yet, but this change should also work on initial folder discovery after a new account is created. This is because an initial imap select on Inbox will occur and, since no discovery has occurred yet, the discovery URL should occur at this time on a new thread/connection as it does on TB startup with my change. However, this change probably does not affect the new account creation time. One possible issue for users who change the default number of cached imap connection from default 5 down to 1 is that it won't be possible for the discovery URL triggered after the initial select URL to obtain its own thread. It will have to wait for the select chain of commands to complete on the single thread before it can become active. So subsequent activity on the single imap thread will be blocked while discovery completes. I haven't tried or tested this yet either. Richard, if you could test the new try build on your setup it would be great. Thanks!