[Akonadi] [Bug 322321] with maildir, emails eventually stop loading

Aaron J. Seigo aseigo at kde.org
Mon Jul 15 12:34:06 BST 2013


https://bugs.kde.org/show_bug.cgi?id=322321

Aaron J. Seigo <aseigo at kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |general
            Version|Git (master)                |GIT (master)
            Product|kmail2                      |Akonadi

--- Comment #1 from Aaron J. Seigo <aseigo at kde.org> ---
Did some poking today with akonadiconsole, which also hangs on loading, so this
seems to be an akonadi thing not an kmail thing as I originally filed this
against.

I started taking note of folders in which the problem was visible, and started
noticing some  patterns. Accessing those same folders with akonadiconsole gives
the same problems. In the debug output, while moving between emails I get
output like this prior to the hang:

19 SEARCH "SELECT DISTINCT ?person ?reqProp1 WHERE { ?person
<http://akonadi-project.org/ontologies/aneo#akonadiItemId> ?reqProp1 . ?person
nco:hasEmailAddress ?email . ?email nco:emailAddress
\"REDACTED\"^^<http://www.w3.org/2001/XMLSchema#string> . }" FULLPAYLOAD
EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) 
19 OK SEARCH completed 
20 UID FETCH 45047 FULLPAYLOAD ALLATTR EXTERNALPAYLOAD (UID REMOTEID
REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) 
* 45047 FETCH (UID 45047 REV 2 REMOTEID "" MIMETYPE "message/rfc822"
COLLECTIONID 60 SIZE 8985 DATETIME "03-Jul-2013 08:44:30 +0000" FLAGS (\SEEN)
ATR:MDNStateAttribute {1} I ATR:pop3resourceattribute {50} 
20 OK UID FETCH completed 
21 UID FETCH 45047 FULLPAYLOAD ALLATTR EXTERNALPAYLOAD (UID REMOTEID
REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) 
* 45047 FETCH (UID 45047 REV 2 REMOTEID "" MIMETYPE "message/rfc822"
COLLECTIONID 60 SIZE 8985 DATETIME "03-Jul-2013 08:44:30 +0000" FLAGS (\SEEN)
ATR:MDNStateAttribute {1} I ATR:pop3resourceattribute {50} 
21 OK UID FETCH completed 
22 SEARCH "SELECT DISTINCT ?person ?reqProp1 WHERE { ?person
<http://akonadi-project.org/ontologies/aneo#akonadiItemId> ?reqProp1 . ?person
nco:hasEmailAddress ?email . ?email nco:emailAddress
\"REDACTED\"^^<http://www.w3.org/2001/XMLSchema#string> . }" FULLPAYLOAD
EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) 

Note how there is no "OK SEARCH completed". I'm unsure why it is doing a search
on the email address when accessing the email (I'm sure there's a good reason
:), but this is where it hangs. The search never returns and from that point
forward no email bodies will be shown while the search hangs. Restarting the
client resolves the matter immediately, so at least the akonadi server
process(es) are not hanging .. but something in the client communication is. It
also happens on the exact same email addresses every time.

Eventually after an ~5 minute timeout, this returns:

22 NO Unable to fetch item from backend (collection 0) : Unable to retrieve
item from resource: Did not receive a reply. Possible causes include: the
remote application did not send a reply, the message bus security policy
blocked the reply, the reply timeout expired, or the network connection was
broken. 

It can't be the security policy as it works with other messages and email
address lookups; it can't be the network (it's all local) .. so either the
application (nepomuk?) did not send a reply or took too long and the reply
timeout expired.

When I run the query in nepomukshell, I get a return with elapsed query time 
of 122 ms. 

The queries that do not cause problems return zero hits from nepomuk.

So, in summary:

* the akonadi<->client communication hangs on the "SELECT DISTINCT ?person .."
queries
* nepomukshell responds ~immediately on all of the queries made
* when results are returned from the query, the communication hangs
* after a 5 minute timeout, things work again until another bad person by email
address query is made

-- 
You are receiving this mail because:
You are the assignee for the bug.



More information about the Kdepim-bugs mailing list