Le dimanche 15 mars 2009 à 13:49 +0100, Philip Van Hoof a écrit :
On Sun, 2009-03-15 at 10:20 +0000, Martyn Russell wrote:
It should be said that the current solution of looking into the database
and trying to deduce what Evolution sees is a really bad idea. This is a
temporary solution and we are asking for pain if we stick with it.
Agreed
Currently, this problem is very easy to reproduce :
1/ Run tracker (in fact, the culprit is tracker-indexer)
2/ Run Evolution
3/ If Evolution did not try to download e-mails by itself, ask for it
and it will block.
4/ Kill tracker-indexer to unblock Evolution.
Evolution can do whatever they want here with the database schema (i.e.
change it).
Are you able to debug this at all and give us any indication of where
the problem is?
Probably at the point where we are doing a rather large SELECT, and
SQLite not allowing Evolution's sqlite3_open itself to interfere with
our process' SELECT until it's finished. Or something like that.
Maybe because Evolution uses large transactions, just like we do for our
non-Evolution database stuff, to increase their performance? ie. while
we are in SELECT is Evolution's TRANSACTION waiting for us to be
finished.
I ran Evolution with CAMEL_DEBUG=all.
I saw many lines like:
DB SQL operation [SELECT vuid FROM 'Non lus' WHERE vuid LIKE 'SfJKInFK
%'] started
or (another one but of the same type):
camel_db_select:
SELECT * FROM folders WHERE folder_name = 'INBOX/Canal+'
===========
DB SQL operation [SELECT * FROM folders WHERE folder_name = 'INBOX/Canal
+'] started
IMHO, Evolution runs many "selects" to retrieve data from its database
but they never return anything.
It is only recently that I found that tracker-indexer is guilty. In
fact, Evolution stops to loop forever when I kill tracker-indexer.
"evolution-imap-db.c" uses sqlite3_open(). Perhaps SQLite3 opens
Evolution's databases as read-only databases? Or, is Fedora 10 SQLite3
that uses particular parameters?
I think it's caused by use of large transactions in Evolution vs. a
large SELECT in Tracker on the same database.
There might be some issues here. We haven't received many/any? reports
of anything like this yet. Maybe it hasn't been used by many people yet.
I certainly haven't had any issues with it yet but I am not a heavy user.
Except if some parameters are available to use SQLite, many users of Evo
2.24 and Tracker 0.6.9x will grumble! :-)
I use latest Tracker version of trunk.
We have another solution in TRUNK too, which allows evolution to push
the data to Tracker instead of Tracker dipping in and pull data from
Evolution's database. This was done by Philip. Unfortunately the change
requires a newer version of Evolution and to be configured to enable in
Tracker (since Evolution hasn't been released yet? with these changes).
Right.
As soon as possible, we will use this method since it is much more
reliable than the current solution.
Very much agree. So distributions should as soon as possible start
shipping Evolution > 2.25.2 and enable the feature in Tracker.
More information here: http://live.gnome.org/Evolution/Metadata
To me, it sounds like: currently, indexing of Evolution e-mails cannot
work with Evo 2.24.x.
So, perhaps indexing should be turned off by default in this case.
Laurent.
_______________________________________________
tracker-list mailing list
tracker-list gnome org
http://mail.gnome.org/mailman/listinfo/tracker-list
