KMail/Akonadi grief

[René J.V. Bertin]

On Tuesday November 12 2019 10:49:23 Anders Lund wrote:

> akonadi must waiting for something that never happens

Or, more likely/accurately, it missed whatever the end condition is because it was doing something else.

>So what ever action is not answering needs to be fixed. Drop it, do it later, 

Not the action itself, the "waiting for it to complete". I'd hope that the Akonadi developers know by now which operation(s) are being waited for, and if so (and it is indeed a question of having missed the end condition) it should be possible to add a timeout and do whatever it is that an offline/online cycle does. Most likely that cycle just causes the blocking request to be repeated and if all goes well the end condition is detected this time around. But the protocol may also provide a way to query the status of the operation, removing the need to repeat the entire operation.

Another solution that should avoid this whole situation: let KMail read (and possibly delete) messages from the cache directly. I'm pretty certain that the Akonadi agents use library code for that which could just as well be called from KMail directly - after all this aspect should be the same regardless of the remote server protocol.
With that approach, the agents only become responsible for communicating with the server, something that doesn't really require multitasking (each agent can have a single FIFO queue with requests for the server). Protection against concurrent database read/write ops is probably (hopefully) provided by the database backend. This should also make fetching messages faster or at least less expensive. Of course you'll still be waiting for that message that "won't fetch", but that cannot be avoided.

Or maybe something like that has already been implemented because I understand that PIM5 is much less hard on the D-Bus?

R.