[Dovecot] 1.0-stable update
Just a note, I backported some larger mbox changes from 1.0-test67. Hopefully works, but if you're going to try it test it well first :)
Should fix some issues related to X-IMAP/X-IMAPbase header handling and maybe some other mbox related problems as well.
I've not seen the UIDVALIDITY issue in the last few days since using dovecot-stable-20050422 but I've noticed it takes much longer to open a message. Looking at protocol dumps, it's taking 3 seconds to do "UID FETCH xxx (UID RFC822.SIZE BODY[])" and another 3 seconds to do "UID STORE xxx +Flags (\Seen)" (using Thunderbird). Is this expected as a result of changing the sync code? Has anybody noticed this with 1.0-test67/68? (I might try and build test68 and see!)
Best Wishes, Chris
Timo Sirainen wrote:
Just a note, I backported some larger mbox changes from 1.0-test67. Hopefully works, but if you're going to try it test it well first :)
Should fix some issues related to X-IMAP/X-IMAPbase header handling and maybe some other mbox related problems as well.
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
On Mon, Apr 25, 2005 at 03:51:23PM +0100, Chris Wakelin wrote:
I've not seen the UIDVALIDITY issue in the last few days since using dovecot-stable-20050422 but I've noticed it takes much longer to open a message. Looking at protocol dumps, it's taking 3 seconds to do "UID FETCH xxx (UID RFC822.SIZE BODY[])" and another 3 seconds to do "UID STORE xxx +Flags (\Seen)" (using Thunderbird). Is this expected as a result of changing the sync code? Has anybody noticed this with 1.0-test67/68? (I might try and build test68 and see!)
I've noticed the same with the latest 1.0-stable.
--
Dominik 'Rathann' Mierzejewski
On Mon, 2005-04-25 at 15:51 +0100, Chris Wakelin wrote:
I've not seen the UIDVALIDITY issue in the last few days since using dovecot-stable-20050422 but I've noticed it takes much longer to open a message. Looking at protocol dumps, it's taking 3 seconds to do "UID FETCH xxx (UID RFC822.SIZE BODY[])" and another 3 seconds to do "UID STORE xxx +Flags (\Seen)" (using Thunderbird). Is this expected as a result of changing the sync code? Has anybody noticed this with 1.0-test67/68? (I might try and build test68 and see!)
I did some changes to it and updated the tarball, maybe it works better now?
Also 1.0-test67/68 problems fixed in CVS / latest nightly tarball.
On Tue, 26 Apr 2005 12:57:26 +0300 Timo Sirainen tss@iki.fi wrote:
On Mon, 2005-04-25 at 15:51 +0100, Chris Wakelin wrote:
I've not seen the UIDVALIDITY issue in the last few days since using dovecot-stable-20050422 but I've noticed it takes much longer to open a message. Looking at protocol dumps, it's taking 3 seconds to do "UID FETCH xxx (UID RFC822.SIZE BODY[])" and another 3 seconds to do "UID STORE xxx +Flags (\Seen)" (using Thunderbird). Is this expected as a result of changing the sync code? Has anybody noticed this with 1.0-test67/68? (I might try and build test68 and see!)
I did some changes to it and updated the tarball, maybe it works better now?
It seems worse. It's getting into a sync_loop (logging "sync_loop XX" where XX increases) for 20 minutes with my 7191-message INBOX (I believe in giving it a thorough test!). Then when a new message arrived, it's doing it again :o
Best Wishes, Chris
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
On Tue, 2005-04-26 at 12:01 +0100, Chris Wakelin wrote:
On Tue, 26 Apr 2005 12:57:26 +0300 Timo Sirainen tss@iki.fi wrote:
On Mon, 2005-04-25 at 15:51 +0100, Chris Wakelin wrote:
I've not seen the UIDVALIDITY issue in the last few days since using dovecot-stable-20050422 but I've noticed it takes much longer to open a message. Looking at protocol dumps, it's taking 3 seconds to do "UID FETCH xxx (UID RFC822.SIZE BODY[])" and another 3 seconds to do "UID STORE xxx +Flags (\Seen)" (using Thunderbird). Is this expected as a result of changing the sync code? Has anybody noticed this with 1.0-test67/68? (I might try and build test68 and see!)
I did some changes to it and updated the tarball, maybe it works better now?
It seems worse. It's getting into a sync_loop (logging "sync_loop XX" where XX increases) for 20 minutes with my 7191-message INBOX (I believe in giving it a thorough test!).
Oops, I forgot the debug message in there :) It's slow because master process starts slowing down the log writing and causing imap process to block on log output.
You could grep for i_info line in src/lib-storage/index/mbox/mbox-sync.c and remove it. I'll update the tarball also.
Then when a new message arrived, it's doing it again :o
Do you have mbox_dirty_syncs = yes, or did you change mailbox before that? Within same SELECT, it should normally just read just the first and last two messages when new mail arrives..
On Tue, 26 Apr 2005 14:17:35 +0300 Timo Sirainen tss@iki.fi wrote:
On Tue, 2005-04-26 at 12:01 +0100, Chris Wakelin wrote:
On Tue, 26 Apr 2005 12:57:26 +0300 Timo Sirainen tss@iki.fi wrote:
On Mon, 2005-04-25 at 15:51 +0100, Chris Wakelin wrote:
I've not seen the UIDVALIDITY issue in the last few days since using dovecot-stable-20050422 but I've noticed it takes much longer to open a message. Looking at protocol dumps, it's taking 3 seconds to do "UID FETCH xxx (UID RFC822.SIZE BODY[])" and another 3 seconds to do "UID STORE xxx +Flags (\Seen)" (using Thunderbird). Is this expected as a result of changing the sync code? Has anybody noticed this with 1.0-test67/68? (I might try and build test68 and see!)
I did some changes to it and updated the tarball, maybe it works better now?
It seems worse. It's getting into a sync_loop (logging "sync_loop XX" where XX increases) for 20 minutes with my 7191-message INBOX (I believe in giving it a thorough test!).
Oops, I forgot the debug message in there :) It's slow because master process starts slowing down the log writing and causing imap process to block on log output.
You could grep for i_info line in src/lib-storage/index/mbox/mbox-sync.c and remove it. I'll update the tarball also.
OK done, and it seems better. Mind you, I had mail delayed (and now delivered in random order) while it was syncing, which proves the locking works, I guess :)
It still seems to have the delay, though :(
Then when a new message arrived, it's doing it again :o
Do you have mbox_dirty_syncs = yes, or did you change mailbox before that? Within same SELECT, it should normally just read just the first and last two messages when new mail arrives..
I've left it at the default, so I guess that means mbox_dirty_syncs = yes.
Best Wishes, Chris
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
participants (3)
-
Chris Wakelin
-
Dominik 'Rathann' Mierzejewski
-
Timo Sirainen