MDOSEQ per Mailbox setting

[lst_hoe02 at kwsoft.de]

Zitat von Bron Gondwana <brong at fastmail.fm>:

> On Tue, Jul 9, 2013, at 12:53 AM, lst_hoe02 at kwsoft.de wrote:
>> Ok, so i can tell the wiki maintainer that the information should
>> mention that this only applies to Cyrus <2.4.
>
> Correct.  Maybe I should have left the annotation in, just forced on!
>
>> One more related question:
>>
>> I have got this warning in the logfile which also pointing to MODSEQ
>> problems, no?
>>
>> "Jul  8 16:40:19 mailer cyrus/imap[32155]: inefficient qresync (1472 >
>> 1) user.xxxxxx"
>
> Why on earth would you send a MODSEQ of 1 and ask for all changes  
> since then?  That's crazy.  Seems like a bogus client.
>

Maybe it was an attempt to get in sync again because its ActiveSync  
e-Mail trouble which pointed to this error.

>>  From what i have read here
>> http://git.kolabsys.com/cyrus-imapd.git/commit/?id=e3f72960b1349f1dffea0160d7bc7478f429cc54 it looks like syncronisation based on MODSEQ does not work as expected for this client? Any idea where to debug or what the actual problem could be. The warning appears on any sync attempt as far as i  
>> can
>> tell.
>
> Well - it works fine.  The client is just being stupid.  What a  
> client is SUPPOSED to do is make an initial request for the data it  
> wants, and then note the HIGHESTMODSEQ in the response.  Next time  
> it connects, it can "resync" by asking for changes since the last  
> value it saw.
>
> But asking for changes since '1' - obviously that's everything.  The  
> reason we log that it's "inefficient" is that we don't have full  
> information for every deleted message any more, so we have to assume  
> every gap in the UID listing is a deleted message.
>
> It's still fine - the response from Cyrus is correct, and the client  
> will work correctly too.  I guess maybe I should make that message  
> not be logged if the request is "since modseq == 1", since clients  
> do that.  Then it will only happen if you reconnect after a week and  
> the expunged messages have been expired.
>
> Regards,
>
> Bron.

I see, thanks for explaining. But i found out that additionally most  
of the time the warning is followed by a "signaled to death" from  
master like this:

Jul  8 07:39:04 mailer cyrus/imap[28235]: inefficient qresync (1364 >  
1) user.xxxxxx
Jul  8 07:39:04 mailer cyrus/master[23881]: process 28235 exited,  
signaled to death by 6

This shouldn't happen, no?

Regards

Andreas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6144 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20130709/536ee54f/attachment.bin