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

Digging through the code, it is something in this bit in Search::parseStream in akonadi/server/src/handler/search.cpp:

  // create imap query
  QVector<ImapSet::Id> imapIds;
  Q_FOREACH ( const QString &uid, uids )
    imapIds.append( uid.toULongLong() );

  ImapSet itemSet;
  itemSet.add( imapIds );
  Scope scope( Scope::Uid );
  scope.setUidSet( itemSet );

  FetchHelper fetchHelper( connection(), scope );
  fetchHelper.setStreamParser( m_streamParser );
  connect( &fetchHelper, SIGNAL(responseAvailable(Akonadi::Response)),
           this, SIGNAL(responseAvailable(Akonadi::Response)) );

so after fiddling with the above akonadiserver code and the the akonadi-kde library in kdepimlibs, akonadiconsole is now working properly. i am not sure what changed (perhaps a newer akonadi server, as that was the last thing i built before it started working?) .. but now kmail can't access any email body, though it is listing folders. am rebuilding the whole pim stack from akonadi through the kdepim again now to see if that resolves itself as well; if it does, i'll close this report otherwise i will return with more harrowing details ;)

p.s. the code snippet from search.cpp was only run when any UIDs were returned from the nepmukquery, explaining why it was triggering the problems under those conditions. still, not sure why it now works in akonadiconsole properly

So with the bit of code patched out of search.cpp, getting mail bodies seems pretty reliable .. but then the mailfilter agent hangs. With an unpatched search.cpp, kmail perpetually shows "Local folders" at 0% in the progress area. With a patched search.cpp (where offending code is just commented out), kmail perpetually shows "Mail filter agent" at 0% in the progress area and very quickly no email bodes can be fetched.

The behaviour in akonadiconsole is similar. With the unpatched search.cpp, I see the stall during the email search (debug output in the relevant code paths shows that the response does come back from nepomuk just fine, it just hangs in search.cpp when looking  up the results). With a patched search.cpp it eventually also stop fetching email bodies though the debug tabs show no obvious problems. So I am assuming it also the mail filter agent interfering at this point.

If there is anything I can do to help sort this out, I'm happy to do so. Right now, kontact for email is next to unusable for  me. :/

When a resource "hangs" (be it the IMAP resource with search or the local mail resource), right-click the resource in Akonadi Console, click  "Show Task List" and paste content of the dialog here please.

here's a task list from a stuck Google resource. help at all?

ResourceScheduler: Online
 current task: 3589 FetchItem item 344340 
 queue 0 is empty
 queue 1 is empty
 queue 2 is empty
 queue 3 4 tasks:
  3592 FetchItem item 349180 
  3596 FetchItem item 349488 
  3604 FetchItem item 349524 
  3611 FetchItem item 349388 
 queue 4 2 tasks:
  3590 SyncAll 
  3591 SyncCollectionTree 

IMAP tasks:

I've seen it too in past few days, so settings to confirmed.

In my case it seemed to be a problem with EntityListCache.

ResourceScheduler: Online
 current task: 3598 FetchItem item 420862 
 queue 0 is empty
 queue 1 1 tasks:
  3599 ChangeReplay 
 queue 2 is empty
 queue 3 is empty
 queue 4 is empty


... similar to Allen, I have a FetchItem task. there's also a ChangeReplay in queue.

i believe the FetchItem task would be related to the FetchHelper in comment #2, so it starts to line up nicely.

This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.