[Kde-pim] mailfilter does not see all incoming messages

[Andras Mantia]

Hi,

 the sprint is coming close when I hope we can look at this together. I'm 
still burried with other things to do, so I can't look at it in deep.

Guy Maurel wrote:

> Hello!
> 
> On Wednesday 13 February 2013 15:00:44 Andras Mantia wrote:
>> If indeed it doesn't receive, the problem might be how the changerecorder
>> is
> I made many debugs...
> It is not possible to follow the tasks with any dgb, because we don't know
> which message(s) are not filtered.

Right. The only way is logging and then log analysis and hoping we find the 
pattern or the logs relieve something.

> I spend lot of kDebug() in the code, send some 22 messages to my
> SMTP-Server, and get them from my POP3-Server. Around 4 of 5 groups of 22
> messages produce the bug.
> 
> But there are not any chance to know (before) how many messages are not
> filtered and which one(s) it would be. So we have to look after the bug
> occurs.
> 
> With:
> mysql --socket=/home/guy/.local/share/akonadi/socket-castor/mysql.socket
> use akonadi;
> SELECT id, remoteId, collectionId, datetime FROM pimitemtable ORDER BY id
> DESC LIMIT 22;
> 
> one get (only some lines here):
> +-------+------------------------+--------------+---------------------+
> | id    | remoteId               | collectionId | datetime            |
> +-------+------------------------+--------------+---------------------+
> | 42258 | 1361729293.R415.castor |            8 | 2013-02-24 18:08:13 |
> | 42257 | 1361729293.R247.castor |          358 | 2013-02-24 18:08:13 |
> | 42256 | 1361729293.R783.castor |          358 | 2013-02-24 18:08:13 |
> | 42255 | 1361729293.R607.castor |            8 | 2013-02-24 18:08:13 |
> | 42254 | 1361729293.R235.castor |          358 | 2013-02-24 18:08:13 |
> 
> The collectionId "8" is my inbox, 358 is the destination folder.
> 
> I grep the kdebug.dgb:
> grep "42255," kdebug.dbg | grep akonadi_mailfilter_agent > kdebug42255.dbg
> 
> and take a look at the end of the output of the run.
> 
> The last instruction reached is not always the same. BUT always in the
> code from kdepimlibs/akonadi/monitor_p.cpp
> 
> Could it be that "somebody" aborted/killed/stopped the process?

Not really, I can't imagine. The processes in question here are the Akonadi 
server and the resources. Communication between them is in two ways: socket 
and dbus. Notifications are sent by dbus.

What you could try is the following:
- debug the notification sending in the akonadi server (it is in the 
akonadi/server/src/notificationmanager)
- debug the notification receiving inside the Akonadi monitor (the file 
you've found, kdepimlibs/akonadi/monitor - slotNotify)
- debug the dbus traffic 

Compare what happens. Is the notification sent? Does it reach all resources? 
Does it show up in the dbus log?

All these will generate a large amount of logging, so it will not be easy to 
process them. Actually akonadiconsole's debugger could be used for it.

Also AFAIK only two resources check the inbox for new mails: the filter and 
the nepomuk indexer (other folders are monitored e.g by the kolab resource). 
Can you try to stop (kill 3 times) the nepomuk indexer and see if we still 
lose messages?

All this are with the assumption that indeed the message notification 
doesn't reach the resource at all, and that it is not the resource not 
processing the message.

Andras
_______________________________________________
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/