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

[Sebastian Trüg]

Hm, this is one major drawback from my Socket implementation in Soprano 
that I did not think of: the query service now uses one connection for 
all clients! That of course is not good.
But it should be rather easy to fix by manually creating a set of 
LocalSocketClients in the query service. Or by doing it the way Vishesh 
proposed: move the query service inside the storage service and avoid 
the whole socket communication altogether.

On 07/06/2012 05:46 PM, David Faure 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.
>