[dev] Question about problem with VANISHED CHANGEDSINCE requests.

[Michael M Slusarz]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> We've discussed this issue before, and I realize it is most likely  
>>> a problem with the dovecot server. I want to verify this before I  
>>> start a discussion on the dovecot@ list though.
>>>
>>> The problem is VANISHED queries sometimes seem to return ALL UIDs  
>>> that ever existed in the mailbox. It follows no pattern that I can  
>>> detect - though I had a thought that it might happen if the the  
>>> email that was associated with the particular MODSEQ value being  
>>> used in the CHANGEDSINCE query is no longer present in the  
>>> mailbox. Anyway, once it happens it *always* happens with the  
>>> given MODSEQ value.
>>>
>>> I used to work around it in code by checking if a UID returned was  
>>> below the expected minimum, but this no longer works due to recent  
>>> changes in the imap code - it now hits against the server memory  
>>> limit before I get a chance to check the UIDs.
>>
>> Can you expand on this?  You shouldn't be running into any memory  
>> limit with the new code.
>
> Currently, when I get the incorrect results from the  
> $imap_ob->vanished() call, I hit against a memory limit in  
> Horde_Imap_Client_Ids on line 160 during array_flip operation. It  
> could be coincidence, or maybe the results I'm getting now are much  
> larger than when I was getting this error previously, but I was not  
> getting this earlier.

Ahh, yes.  array_keys(array_flip()) is much faster than  
array_unique(), but it uses twice as much memory.

I made a change to use the slower, but more memory efficient,  
array_unique() when ids() becomes sufficiently large.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]