[Kde-pim] fixing mbox - general Akonadi problem ?

[Daniel Vrátil]

On Tuesday 11 of February 2014 23:10:13 Martin Koller wrote:
> As far as I understand, the Akonadi server has the remoteIds in its
> database, so every other client is free to ask the akonadi server for it.
> How can you make sure that the mbox resource can change atomically a bunch
> of remoteIds and making sure no other client has already the now invalid
> ones ?

This should not be a problem as RIDs are internal to the resource that owns 
the items. Client applications and other agents ignore RIDs (and if they 
don't, they are broken). There's an option to disable fetching RID in 
ItemFetchJob, but it's disabled by default for backwards compatibility, but it 
will change in KF5.  Also the only client that can modify item's RID is the 
resource that owns it, anyone else will get an error.

> If you'd like to look at the sequence of what happens, take a look at
> the attached logfile (I included some more debug print statements in the
> code)
> 
> Starting at line 42 the items are removed.
> MboxResource::itemRemoved() is called with a remoteId with offset 0.
> the reource then compacts the file (note: compacting every 1 msg)
> And the next call it already receives is to delete the item with offset 645
> which is the second mail, but that should already be 0 again as the first
> was deleted.

When you delete a mail from MboxResource::itemRemoved() and there are more 
items waiting for deletion in ChangeRecorder's pipeline, it's necessary to 
modify RIDs of all emails affected by the compaction BEFORE changeProcessed() 
is called. This should cause all other items pending deletion in 
ChangeRecorder's pipeline to be refetched from Akonadi with updated RID.

Porting MBox resource to ObserverV3 which supports batch deletions and flags 
changes could help too. It should speed up the resource notably, because it 
could do compaction after the entire batch is processed, preventing 
ChangeRecorder from flushing and refetching the entire cache for pipelined 
notifications after every single item being processed.

Dan

> Note however that this log is without my trial to change the remoteIds.
> But even with my code it did not work and I assume it is due to the fact
> that there are the messages traveling from the filter agent to akonadi
> and back to my resource before I even have a chance to change all
> old remoteIds

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140212/6a6dcf7e/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/