[Akonadi] [Bug 399167] Akonadi enters deadlock state which makes it completely unuseable
David Faure
bugzilla_noreply at kde.org
Fri Aug 16 12:04:42 BST 2019
https://bugs.kde.org/show_bug.cgi?id=399167
--- Comment #24 from David Faure <faure at kde.org> ---
Git commit 15c91a0ac93051465b37807efceb6e9fd36cb73b by David Faure.
Committed on 16/08/2019 at 09:27.
Pushed by dfaure into branch 'Applications/18.12'.
Akonadi: fix dangling transaction after itemsync failure
Summary:
TransactionSequence was emitting result() twice when rolling back.
* How did this happen?
The TransactionRollbackJob is (automatically) added as a subjob of the
TransactionSequence, so when it finishes, slotResult is called (like for
all subjobs), as well as rollbackResult().
Since the latter emits result() already [mostly for symmetry with
commitResult()], we don't need to do that in slotResult (which doesn't do
it for the case of committing, either).
* Why is it a problem to emit result() twice?
Well, first, it's against the law in KJob world. In practice,
ItemSyncPrivate::slotTransactionResult was called twice (for the same
TransactionSequence job) which made it decrement mTransactionJobs one
time too many.
As a result, checkDone() finished too early and didn't go into the
"commit transaction" branch for other transactions.
Leaving a transaction "open" is a good recipe for database deadlocks further
down the line.
* Why did the TransactionSequence roll back in the first place?
In my case because of the infamous and not-yet fixed "Multiple merge
candidates" problem, but it seems that it can also happen when having
items without a part, according to Volker's investigations.
All of these issues still need to be fixed, but at least akonadi seems
to be still usable after they happen.
Test Plan: Ctrl+L in kmail, with a folder having multiple items for the same
RID
Reviewers: dvratil, vkrause
Reviewed By: dvratil
Subscribers: kfunk, kde-pim
Tags: #kde_pim
Differential Revision: https://phabricator.kde.org/D19487
(cherry picked from commit f1281cf18f40fd69acd61c31b48f5ce43e138eea)
(cherry picked from commit 8ff596c4fe15199b66262c624d8b7c8d8ec7368f)
M +0 -2 src/core/jobs/transactionsequence.cpp
https://commits.kde.org/akonadi/15c91a0ac93051465b37807efceb6e9fd36cb73b
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Kdepim-bugs
mailing list