Closed
Bug 431466
Opened 17 years ago
Closed 17 years ago
tagging in imap folder makes loading next message impossible
Categories
(Thunderbird :: Mail Window Front End, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: maximilian.mehnert, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042704 Minefield/3.0pre
Build Identifier: 3.0a1pre (2008042903)
I've a saved search for an imap server, containing several "doesn't contain tag" criteria covering two folders.
When tagging a message from inside this saved search and moving to the next message, it is not loaded. In fact, until restart loading anything from the imap server does not work and thunderbird is showing a "busy" mouse pointer.
Reproducible: Always
Steps to Reproduce:
1. create an imap saved search covering at least two folders
2. tag a message inside the search
3. load next message
Actual Results:
imap communication does not work anymore
Expected Results:
should load the next message.
Reporter | ||
Comment 1•17 years ago
|
||
actually, I could reproduce this without a saved search in a normal imap folder.
Tag message, move on to next message, no more imap communication.
Reporter | ||
Updated•17 years ago
|
Summary: tagging in saved imap search makes loading next message impossible → tagging in imap folder makes loading next message impossible
Comment 2•17 years ago
|
||
Worksforme (In reply to comment #1)
> Tag message, move on to next message, no more imap communication.
Worksforme, with Gmail IMAP, with Tb trunk 2008/4/27 build on MS Win-XP SP2.
"Adding tag" has no problem, via usual IMAP folder(non offline use), and via search folder(Search Online==Off, search targets are non offline use folders.)
New problem on 4/29 build?
Get IMAP protocol log, and check real protocol level flow first.
See Bug 402793 Comment #1 for getting log.
Reporter | ||
Comment 3•17 years ago
|
||
Hanging occurs after the last line in the log attached here.
Comment 4•17 years ago
|
||
> localhost:S-all:SendData: 19 uid store 61948 +FLAGS (bvmd)
> queuing url:imap://max@localhost:143/fetch>UID>/all>61989
> considering playing queued url:imap://max@localhost:143/fetch>UID>/all>61989
> creating protocol instance to play queued url:imap://max@localhost:143/fetch>UID>/all>61989
> failed creating protocol instance to play queued url:imap://max@localhost:143/fetch>UID>/all>61989
Is this log saved after termination of Tb? (log data is buffered, so activity after above can exist)
It looks that : (if above is really last activity after "19 uid store 61948 ...")
After "19 uid store 61948 +FLAGS (bvmd)" by adding tag,
Tb tried to fetch uid 61948 via another session before OK to "19 store",
and failed to create a new session for the fetch,
and waits for OK response to "19 uid store 61948 ..." forever.
What is set as "Maximum number of server connection to cache" of Server Settings/Advanced? Is the value appropariate for your IMAP server?
Reporter | ||
Comment 5•17 years ago
|
||
Maximum number of cached connections is set to 5 which should be appropriate. However, same problem occurs when setting cached connections to 1.
Attached is the log till the end - terminating Thunderbird yields some more lines but they look as if they are just related to quitting.
Comment 6•17 years ago
|
||
If you've really attached all the interesting part of the log, it looks like the server is never responding to the store command, so we're just waiting for it to come back before issuing other commands to this folder (so nothing to do with the number of connections - we don't ever try to open two connections to the same folder). Eventually, we should time out and drop the connection to the server.
-1309676656[ba8e9c8]: bb21fa8:localhost:S-all:SendData: 19 uid store 61948 +FLAGS (bvmd)
Reporter | ||
Comment 7•17 years ago
|
||
I'm discussing that with the maintainer and will get back with the results.
Updated•17 years ago
|
Blocks: tb-tagsmeta
Reporter | ||
Comment 8•17 years ago
|
||
That was a server problem, not a thunderbird problem.
Everything works fine now.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 9•17 years ago
|
||
->INVALID (FIXED is only used when known code changes resolved the issue)
https://bugzilla.mozilla.org/page.cgi?id=fields.html#resolution
Resolution: FIXED → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•