[Bug 307807] Insane abuse of nepomuk causes power abuse and makes the system unusable

[Christian Mollekopf]

https://bugs.kde.org/show_bug.cgi?id=307807

--- Comment #6 from Christian Mollekopf <chrigi_1 at fastmail.fm> ---
(In reply to comment #4)
> Of course it is very good to ensure that the right nepomuk code is used.
> 
> But it is equally importnat that ALL aspects of this area is optimized. For
> example there is a patch waiting that should prevent reindexing when flags
> are changed. 
> 
> On my system, my owncloud resources are often dropped, and judging from the
> virtuoso-t activity when they are rediscovered, they are also reindexed
> again. Quite absurd, for my calendars  + contacts! Let me know if I can help
> investigate or if my log files can help!
> 

Not sure what you mean by the resources are "dropped", but if they go offline
and come online again, and there is no new data, there should also be no
indexing happening.

> What happens with new mail? Receiving a few mails costs minutes of
> virtuoso-t activity > 30-50% CPU here, and that can not be reasonable, even
> given virtuoso-t or nepomuk inefficiency - indexing many times the amount of
> images or documents is barely visible. So I can't help wondering if messages
> are indexed more than once, for example when moved by a filter. If that is
> the case, there is a low-hanging fruit to pick!
> 

As long as the ID of the akonadi-item doesn't change there shouldn't be any
reindexing going on.

> Mail that is set as spam by my bogofilter should NEVER be indexed, so can
> trust that mail in trash folders are never indexed right? But that is not
> enough, as long as filtering is not always trustworthy itself, often spam
> messages are left in the inbox, and it is still silly to index it. Is there
> a header I can add to prevent that from happening? (and that the spam
> filtering wizard could add to the filters it creates!)

The feeder looks for a $JUNK flag to filter spam, not sure where this flag is
set exactly.

-- 
You are receiving this mail because:
You are the assignee for the bug.