Bug 117326 - run kio_http_cache_cleaner when user is idle
Summary: run kio_http_cache_cleaner when user is idle
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: http (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 205931 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-11-30 04:57 UTC by Michiel de Bruijne
Modified: 2010-01-30 23:34 UTC (History)
3 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 Michiel de Bruijne 2005-11-30 04:57:51 UTC
Version:            (using KDE KDE 3.4.1)
Installed from:    Gentoo Packages
OS:                Linux

When kio_http_cache_cleaner runs it consumes all disk time and therefor has bad influence on other programs and makes the system less responsive. I would like to request to run kio_http_cache_cleaner when the user is idle (e.g. user hasn't used mouse/keyboard x time).
Comment 1 Kevin Lamonte 2007-05-23 15:20:43 UTC
I am the Debian user who is mentioned at the end of bug 130862 ("kio_http_cache_cleaner starts every few minutes and causes extreme disk I/O or thrashing").  I was recently digging through http_cache_cleaner.cpp again and was wondering if there is a good justification for its complexity.

In my version of http_cache_cleaner.cpp it looks like readEntry()'s purpose is to ensure that all files in the cache are at the correct cache version, that they include a URL, and that their "creation date" is less than KProtocolManager::maxCacheAge seconds old.  I feel like the first two checks properly belong to the code that directly writes and reads the cache entries (http.cc ?), and the last check could go off filesystem time, avoiding the fopen() in readEntry() entirely.  If that is really feasible in the larger design then kio_http_cache_cleaner could execute in just a few seconds even on systems with large (> 1 GB) cache sizes.
Comment 2 Christoph Feck 2009-12-09 00:00:30 UTC
*** Bug 205931 has been marked as a duplicate of this bug. ***
Comment 3 Andreas Hartmetz 2010-01-30 09:04:50 UTC
I have fixed this in trunk. The most important (most used) data about cache entries is duplicated in one big central file so we can avoid reading hundreds or thousands of small files. Filesystem metadata (which is orders of magnitude faster to read) is used for a consistency check. Seems to work well.
Comment 4 Christoph Burgmer 2010-01-30 10:21:42 UTC
If it's gone, you've solved the for me worst bug in KDE4. Thank you very much!
Can this be ported to 4.4.1?
Comment 5 Andreas Hartmetz 2010-01-30 23:34:12 UTC
Yeah, I'm planning to backport this.