EntityTreeModelPrivate::monitoredItemChanged

[Daniel Vrátil]

On Saturday, April 22, 2017 9:27:48 AM CEST Martin Koller wrote:
> Hi Daniel,

Hi Martin,

> 
> first question: should I address questions about the core of akonadi
> directly to you or do you like it better when I send messages to
> kde-pim at kde.org (but I have the feeling you're the only one who can answer
> this type of questions) ?

I think if it's PIM related, it should go to the mailing list. As you said, it 
will very likely be me who will reply anyway, but just for the sake of future 
reference.

> The question:
> In EntityTreeModelPrivate::monitoredItemChanged it issues a warning when a
> received item is not known in the internal QHash.
> However I think it does not make sense to issue this warning, since a mail
> fetching resource (like my test or a POP resource, etc.)
> will not have the items it receives from the server in the hash ever. Am I
> right ?

The way the "flow" is, is:

1) POP3 Resource runs ItemCreateJob
2) Akonadi server creates the PimItem, sends ItemCreated notification to all
3) All email agents, applications and their ETMs that watch emails get the new 
Item
4) Some agent or client changes the Item through ItemModifyJob
5) Akoandi server processes the changes, sends ItemModified notification to all
6) All email agents, applications and their ETMs that watch emails get the 
notification

Expected: ETMs process the change
Reality: ETMs complain about the "stale notification"

This leads me to believe that the real problem is either in step 2 or step 3. 
In case of step 2 the problem would be in server-side filtering of the 
notification. Each client connected to the Akonadi Server uploads their 
Akonadi::Monitor (Akonadi::ChangeRecorder)  "notification filter" to the Server. 
When Server generates a new notification it runs it through each subscriber's 
filter to see if the subscriber is interested in the notification. If the bug is 
here, it would be either in the notification missing some data or in the 
filtering code that cause the notification to be discarded rather than sent to 
the subscribers. That way the subscribers don't find out about the new item and 
only get "ItemChanged" afterwards, which confuses them (and rightly so).

If the bug is in step 3, the bug would likely be in ETM, which would, for any 
reason, decide not to store the newly created Item and intead ignores it or 
throws it away.

These are my two main candidates for where the issue comes from.

> E.g. I created a simple test resource which just produces a testmail and
> sends it to the akonadi server (attached), and this resource now always
> issues this warnings.
> 
> Why does every resource have the EntityTreeModel at all ?
> Can I disable it or is this essential ?

As you found out, ETM is only used by some agents, specifically agents that use 
MailCommon::Kernel, which has an internal ETM instance. Whether they *really* 
need to use the ETM is another question.

> 
> I see the same warnings coming from other resources, e.g.
> akonadi_archivemail_agent and I'd say it is due to the same reason.
> 
> Also the message it prints is misleading since the item was not "already
> removed" but "never inserted".

True, although the ETM does not remember if it "saw" the Item before or if it 
never heard of it. Technically, the second case should not ever happen (that's 
where the bug is), so the message is actually correct. 

Dan

-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20170422/b520de55/attachment.sig>