Bug 245265 - Long IMAP downloads cause mysql lock wait timeouts
Summary: Long IMAP downloads cause mysql lock wait timeouts
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: 1.3.50
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Kevin Ottens
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-20 23:57 UTC by Leo Franchi
Modified: 2010-12-28 16:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leo Franchi 2010-07-20 23:57:52 UTC
Version:           1.3.50
OS:                Linux

Trying to sync my 13000 email IMAP inbox with disconnected imap, over a slow-ish connection. After trying for a while, I get this in the console:


[akonadiserver] Error during executing query "UPDATE PimItemTable SET atime = :0 WHERE ( ( PimItemTable.id >= :1 ) AND collectionId = :2 )" :  "Lock wait timeout exceeded; try restarting transaction QMYSQL3: Unable to execute statement"


from this point on, the imap resource stops downloading, until I manually restart the server, and it will start again from 0.

Reproducible: Always
Comment 1 Volker Krause 2010-07-21 10:02:15 UTC
Just for the record, the suggestions at the end still need to be tested AFAIK:
[Monday 19 July 2010] [15:36:38] <lfranchi>	krake_: i still have the PimTable timeout issues, but I don't think it's related to your specialcollections fix anymore
[Monday 19 July 2010] [15:36:50] <lfranchi>	my internet is just super flaky and akonady apparently really doesn't like that
[Monday 19 July 2010] [15:37:52] <krake>	lfranchi: you could check if some other session shows similar behaviror, i.e. lots of BEGIN commands but no COMMIT or ROLLBACK ending the transactions
[Monday 19 July 2010] [15:38:01] <krake>	lfranchi: this is how I found the one I fixed
[Monday 19 July 2010] [15:40:18] <lfranchi>	ok
[Monday 19 July 2010] [15:42:59] <krake>	lfranchi: of course there could be other things than open transactions which might be causing this.
[Monday 19 July 2010] [15:43:46] <krake>	another option might be to use lxr.kde.org to check for use and subclassing of Akonadi::TransactionSequence
[Monday 19 July 2010] [15:44:15] <lfranchi>	it might be related to the slow/hanging internet/imap resource
[Monday 19 July 2010] [15:44:21] <lfranchi>	apparently it just got faster, problem went away
[Monday 19 July 2010] [15:47:40] <volker|office>	ah, ItemSync (used internally by the resource) can use a single transaction sequence indeed, and when used in streaming mode it can stay open for quite some time
[Monday 19 July 2010] [15:48:45] <volker|office>	lfranchi: you could try to change mTransactionMode in kdepimlibs/akonadi/itemsync.cpp from Single to Chunkwise or None, and see if that helps
Comment 2 Leo Franchi 2010-07-21 14:08:25 UTC
Ah right, my bad. I forgot about it. Testing now.
Comment 3 Kevin Ottens 2010-08-03 12:19:11 UTC
Should this report be marked as fixed now?
Comment 4 Volker Krause 2010-12-28 16:54:44 UTC
Suggestions from comment #1 have been implemented some time ago already.