On 02/07/2014 03:04 PM, Timo Sirainen wrote:
On 3.2.2014, at 17.19, Gedalya <gedalya@gedalya.net> wrote:
I think I'm having a problem with simultaneous pop3 connections on the same mailbox with one connection deleting a message. .. Jan 29 14:36:33 imap1 dovecot: pop3(riki@domain.com): Error: Message ordering changed unexpectedly (msg #1: storage seq 1 -> 2) Jan 29 14:36:33 imap1 dovecot: pop3(riki@domain.com): Disconnected: POP3 UIDLs couldn't be listed top=3/2662, retr=0/0, del=0/1227, size=51548362
Running Dovecot 2.2.10+hg-6018854c8c91 Mailboxes were migrated recently using dsync with pop3 migration plugin. What mailbox format is this with? I can only reproduce this by forcibly making sure that pop3.order field doesn't go into dovecot.index.cache field. Anyway .. this should help: http://hg.dovecot.org/dovecot-2.2/rev/59decc957b39 Ah sorry, yes. All mailboxes are maildir. Forgot to include the SQL configs. I guess I can send you the uidlist. This is happening when she is deleting a message that is still from the old server, i.e. a migrated message, which has the O field set in dovecot-uidlist. Presumably it would stop happening when the last of those is gone.
I'll read through that commit now..
So also add something like "uidls=%u" to your pop3_logout_format. This will use up a little bit more memory by storing all the UIDLs in memory. The %u output can sometimes be used to debug why POP3 clients are redownloading messages.
Your commit message says: "..can be completely avoided by using either pop3_lock_session=yes or adding %u to pop3_logout_format." If I understand you correctly, this is a setting for formatting the entry in the log file, and by using %u I'm forced to save the UIDLs in memory and as a side effect I circumvent the problem of colliding with another simultaneous pop3 client? So using %u would not help troubleshoot the problem but actually fix it?