https://bugs.kde.org/show_bug.cgi?id=384309
Daniel Vrátil <dvra...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit|https://invent.kde.org/pim/ |https://invent.kde.org/pim/
|kdepim-runtime/-/commit/a4e |kdepim-runtime/-/commit/d13
|290c26d98278f729073b909cc96 |6c91ace0f6e52089004221c0aab
|3e3331c0a8 |b696bdee63
--- Comment #8 from Daniel Vrátil <dvra...@kde.org> ---
Git commit d136c91ace0f6e52089004221c0aabb696bdee63 by Daniel Vrátil.
Committed on 28/02/2024 at 21:42.
Pushed by dvratil into branch 'master'.
Fix endless sync loop with some remote iCal sources
The sync in SingleFileResource implementations (iCal, vCard and MBox
resources) is implemented in a little strange way for remote files:
1) Akonadi (or someone) requests sync of the resource's collection
2) The resource starts a download of the new file
3) In the meantime, it syncs content of the current version of
the file with Akonadi
4) When the file is downloaded, hash of the file is compared with
previous hash and if they differ, goto 1
Some remote sources (e.g. Google Calendar) generate the iCal on-demand
and as such the file always contains a different DTSTAMP. Thus, whenever
the iCal resource completes the download, the hash will always differ
compared to the previous one, and so it will again re-schedule sync
over and over. While the data are actually available in Akonadi and
to the user, it causes a high CPU load as the iCal is constantly being
re-parsed, Akonadi database update, the Indexing agent is triggered
over and over again. And the bigger the calendar, the worse it is.
This fix changes the behavior by downloading the file, running the
parser (iCal/vCard/mbox/...) and after that performing a regular
sync, so basically:
1) Akonadi (or someone) requests sync of the resource's collection
2) The resource starts a download of the new file
3) When the file is downloaded, the resource syncs the content of the
file with Akonadi.
I have opted for using QPromise+QFuture combo to perform the async
chaining of download->sync. It's the only solution that requires the
last amount of code refactoring and reorganization in order to properly
sequence the operations. This would be the perfect place for using
coroutines, but I don't want to introduce coroutines as part of a
regular bugfix. I might do an experimental port at some point later.
FIXED-IN: 24.02.1
(cherry picked from commit a4e290c26d98278f729073b909cc963e3331c0a8)
M +15 -6 resources/ical/shared/icalresourcebase.cpp
M +42 -35 resources/mbox/mboxresource.cpp
M +14 -6 resources/shared/singlefileresource/singlefileresource.h
M +31 -28 resources/shared/singlefileresource/singlefileresourcebase.cpp
M +8 -2 resources/shared/singlefileresource/singlefileresourcebase.h
M +17 -13 resources/vcard/vcardresource.cpp
https://invent.kde.org/pim/kdepim-runtime/-/commit/d136c91ace0f6e52089004221c0aabb696bdee63
--
You are receiving this mail because:
You are watching all bug changes.
