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.

_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk

Reply via email to