Bug 318558 - Endless loop fetching ICAL file from HTTPS when created read-only
Summary: Endless loop fetching ICAL file from HTTPS when created read-only
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: ICal file resource (show other bugs)
Version: 1.9.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL: http://pastebin.com/5sjafzez
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-18 15:44 UTC by David M.
Modified: 2017-01-07 22:29 UTC (History)
4 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 David M. 2013-04-18 15:44:58 UTC
I just tried creating a new calender in KOrganizer, selecting "ICal calendar file" option.

As filename, I specified "https://tiss.tuwien.ac.at/events/ical.xhtml?locale=de&token=my-top-secret-calendar-token" with my real calendar token for the web service. I gave it a name, selected "Read only" for "Access rights" and clicked OK.

After the procedure described below, there is a lot of disk and network I/O and the appointments are "blinking" (appearing and disappearing) in KOrganizer. Task manager shows akonadi and its mysql minions are responsible.

Somehow somewhere Google said

$ kcmshell4 kcm_akonadi

and that output a whole train of debug stuff with parse errors, it's in the URL attached.

Checks that are OK:
Upon manual HTTPS request, the file looks like a regular ICAL text format and has 1603 lines.
Upon ICal import of the saved file, all entries seem to get imported without trouble.
If I import without selecting "Read only", the import works without trouble (no extensive disk or network I/O).


Reproducible: Always

Steps to Reproduce:
1. Open KOrganizer
2. Settings -> Configure KOrganizer...
3. General page -> Calendars tab
4. Add...
5. pick "ICal calendar file"
6. As filename, specify "https://tiss.tuwien.ac.at/events/ical.xhtml?locale=de&token=my-top-secret-calendar-token" with my real calendar token for the web service.
7. (Give it a name)
8. select "Read only" for "Access rights"
9. Click OK
Actual Results:  
Calendar is created. There is a lot of disk and network I/O and the appointments are "blinking" (appearing and disappearing) in KOrganizer. Task manager shows akonadi and its mysql minions are responsible.

Expected Results:  
Create a calendar based on the remote ICAL file from HTTP, hopefully update it in some time interval. Not request the ICAL file every second and parse it over and over.

Needs a web service which provides ICAL files via HTTP.
Comment 1 Sergio Martins 2013-06-12 17:51:30 UTC
I can't reproduce with the above steps, but i've seen this happening once
Comment 2 auxsvr 2014-03-28 16:26:37 UTC
This occurs all the time here with https://www.google.com/calendar/ical/26p990fpjg60pjilas7npjlv7g@group.calendar.google.com/public/basic.ics . After I disabled "read-only", akonadi tried many times to upload a cached file, which is weird, because I couldn't possibly have made any changes to it. This endless loop causes all sorts of trouble: 
1.high CPU use of akonadi and plasma-desktop,
2.non-stop notifications about the calendar being offline, when I set it offline in an attempt to make it stop,
3. non-stop notifications about the calendar not being loaded, after I set it online.

This is on KDE 4.12.97.
Comment 3 redcap 2014-07-05 21:46:38 UTC
I can also confirm this bug on Version 4.12.5
Comment 4 Thiago Jung Bauermann 2014-12-11 15:54:19 UTC
This is possibly a duplicate of bug 275573.
Comment 5 Denis Kurz 2016-09-24 20:38:49 UTC
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.
Comment 6 Denis Kurz 2017-01-07 22:29:05 UTC
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.