[Nepomuk] KMail completion spams nepomuk, which isn't parallelized

Ignacio Serantes kde at aynoa.net
Mon Jul 9 22:17:43 UTC 2012


Hi,

You don't see my last query I put in IRC before I leave because you are not
connected. Please try this one:.

SELECT DISTINCT ?email ?fullname

WHERE {

?r a nco:Contact .

{

  ?r nco:hasEmailAddress ?v0 . ?v0 nco:emailAddress ?v1 .
FILTER(REGEX(STR(?v1), "^vau", "i")) .

} union {

  ?r nco:fullname ?v . FILTER(REGEX(STR(?v), "^fau", "i")) .

} union {

  ?r nco:nameFamily ?v . FILTER(REGEX(STR(?v), "^fau", "i")) .

} union {

  ?r nco:nameGiven ?v . FILTER(REGEX(STR(?v), "^fau", "i")) .

}


 OPTIONAL { ?r nco:hasEmailAddress ?v . ?v nco:emailAddress ?email . } .

OPTIONAL { ?r nco:fullname ?fullname . } .

}
I'm not sure about the nco:hasEmailAddress relation because I'm not using
akonady but based in the original query and in our previous test this one
must work.

We could optimize the query using bif:contains() instead REGEX,
it's theoretically fast because uses indexes, but we lost the possibility
to query using only one character, three are then the minimum, and for an
incremental search in a contact list with only 500?, 1000?  records its a
big loss.

On Fri, Jul 6, 2012 at 5:46 PM, David Faure <faure at kde.org> wrote:

> Typing 10 letters in the kmail composer "To" field, leads to 10
> autocompletion nepomuk queries,
> all of which create a different thread in the nepomukqueryservice, and
> they pile up, each waiting
> for the previous one to finish, because they use the same mutex-protected
> socket for the
> connection to virtuoso...
>
> All the threads in `nepomukservicestub nepomukqueryservice` have this bt:
>
> Thread 5 (Thread 0x7fffea00e700 (LWP 23920)):
> #0  0x00007ffff4361cd9 in syscall () from /lib64/libc.so.6
> #1  0x00007ffff78f1652 in _q_futex (addr=0x7fffe4003220, op=0, val=2,
> timeout=0x0, addr2=0x0, val2=0) at thread/qmutex_unix.cpp:99
> #2  0x00007ffff78f170a in QMutexPrivate::wait (this=0x7fffe4003220,
> timeout=-1) at thread/qmutex_unix.cpp:113
> #3  0x00007ffff78ebe2a in QMutex::lock (this=0x7fffe4003038) at
> thread/qmutex.cpp:164
> #4  0x00007ffff0440b56 in Soprano::Socket::lock (this=0x7fffe4003020) at
> /d/kde/src/4/soprano/client/socket.cpp:117
> #5  0x00007ffff0441217 in Soprano::SocketStream::SocketStream
> (this=0x7fffea00d8a0, dev=0x7fffe4003020) at
> /d/kde/src/4/soprano/client/socketstream.cpp:36
> #6  0x00007ffff0444f13 in Soprano::Client::ClientConnection::executeQuery
> (this=0x7fffe40035c0, modelId=343926100, query="select distinct ?email
> ?fullname where { ?r a nco:Contact . ?r nco:hasEmailAddress ?v .  ?v
> nco:emailAddress ?email . { FILTER regex( str(?email), \"\\\\bfaure\",
> \"i\") . ?r nco:fullname ?fullname } union "...,
> type=Soprano::Query::QueryLanguageSparql, userQueryLanguage="") at
> /d/kde/src/4/soprano/client/clientconnection.cpp:227
> #7  0x00007ffff04476b7 in Soprano::Client::ClientModel::executeQuery
> (this=0x7fffe4003110, query="select distinct ?email ?fullname where { ?r a
> nco:Contact . ?r nco:hasEmailAddress ?v .  ?v nco:emailAddress ?email . {
> FILTER regex( str(?email), \"\\\\bfaure\", \"i\") . ?r nco:fullname
> ?fullname } union "..., language=Soprano::Query::QueryLanguageSparql,
> userQueryLanguage="") at /d/kde/src/4/soprano/client/clientmodel.cpp:101
> #8  0x00007ffff60b631a in Nepomuk2::MainModel::executeQuery
> (this=0x7fffe4002d60, query="select distinct ?email ?fullname where { ?r a
> nco:Contact . ?r nco:hasEmailAddress ?v .  ?v nco:emailAddress ?email . {
> FILTER regex( str(?email), \"\\\\bfaure\", \"i\") . ?r nco:fullname
> ?fullname } union "..., language=Soprano::Query::QueryLanguageSparql,
> userQueryLanguage="") at
> /d/kde/src/4/nepomuk-core/libnepomukcore/resource/nepomukmainmodel.cpp:182
> #9  0x00007fffeba31eee in Nepomuk2::Query::SearchRunnable::run
> (this=0x7a4620) at
> /d/kde/src/4/nepomuk-core/services/queryservice/searchrunnable.cpp:89
> #10 0x00007ffff78e12fd in QThreadPoolThread::run (this=0x7a4960) at
> concurrent/qthreadpool.cpp:107
> #11 0x00007ffff78f1f28 in QThreadPrivate::start (arg=0x7a4960) at
> thread/qthread_unix.cpp:307
> #12 0x00007ffff7631f05 in start_thread () from /lib64/libpthread.so.0
> #13 0x00007ffff436510d in clone () from /lib64/libc.so.6
>
> Thread 5 is looking for "faure"
> Thread 4 is looking for "faur"
> Thread 3 is looking for "fau"
> Guess what I was typing ;)
> Thread 2 is doing another query, but also waiting on the socket.
> Thread 1 is in the event loop.
>
> Is there a way to cancel such queries? Surely kmail should abort the
> running query when making another one,
> it makes no sense to keep looking for "foo" when the user has replaced it
> with "bar".
>
> The other conclusion from this is... what's the point in having threads in
> the query service
> if they all wait on each other anyway due to the shared socket?
> This can lead to a very long delay, e.g. when sending an email (again),
> because it has
> to wait for all the previous queries to finish first.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>



-- 
Best wishes,
Ignacio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120710/f83472e1/attachment.html>


More information about the Nepomuk mailing list