Re: [Tracker] Ready for merge

[Martyn Russell <martyn imendio com>]

Laurent Aguerreche wrote:
> Le vendredi 08 aoÃt 2008 Ã 02:11 +0200, Philip Van Hoof a Ãcrit :
> > On Fri, 2008-08-08 at 01:10 +0200, Laurent Aguerreche wrote:
> > > Le jeudi 07 aoÃt 2008 Ã 22:06 +0200, Philip Van Hoof a Ãcrit :
> > > > On Thu, 2008-08-07 at 19:40 +0100, Martyn Russell wrote:
> > > > > Martyn Russell wrote:
> > > > > > Laurent Aguerreche wrote:
> > > > > Phillip has a patch we can try for this. There are other means we use
> > > > > in the indexer too which I will play with.
> > > > Laurent, can you try the patch that I have attached?
> > > I applied it after I modified it a little bit:
> > >
> > > In tracker-crawler.c around line 608, I have this line :
> > >   g_list_foreach (files, (GFunc) g_object_unref, NULL);
> > >
> > > You do not seem to have it in your patch so I removed it:
> >
> > Note that the patch is older than the current code. It sounds likely
> > that the g_list_foreach is necessary unless you want a quite immense
> > memory leak.
> >
> > I'll let Martyn comment on this, though.
>
> Ok.
>
> > > +   }
> > > +   
> > >       >>>>  No g_list_foreach(...) here?  <<<<<<<<<<<<<<<<<<<<<
> > >     g_list_free (files);
> > >  
> > > -   /* Get next file */
> > > +   /* Get next files */
> > >     file_enumerate_next (enumerator, ed);
> > >  }
> > >
> > > > The more people test this kind of patches, the more sure we are of the
> > > > performance impact.
> > > This patch seems to give me better results  :-)
> > That's good!
> >
> > > But while I'm writing this e-mail, I see Evolution getting frozen.
> > > Perhaps a strange behavior of this software (as usual...).
> > Perhaps not, perhaps yes. We better make sure not ;-)
>
> Indeed, I was a little bit too enthusiastic because Firefox is also
> getting frozen from time to time but I can switch from an application to
> another so it is still better.
>
> I noticed that tracker-indexer has not an idle priority for I/O. The
> program written in configure.ac does not correctly check whether I can
> set I/O priorities on my system. IMHO it misuses the AC_LANG_PROGRAM
> macro, and I do not understand why it uses exit() instead of return!? I
> propose a patch (but, to be honest, I only fixed the use of M4 macros).
> This fix works on my Fedora 9 x64. I can commit in trunk and
> indexer-split branches if this patch is assumed to be correct.
>
>
> And a question, why do I see this message often:
>
> Tracker-Message: Items could not be processed by the indexer, Did not
> receive a reply. Possible causes include: the remote application did not
> send a reply, the message bus security policy blocked the reply, the
> reply timeout expired, or the network connection was broken.
>
> All around it, I get this message:
> Tracker-Message: Still waiting for response from indexer, not sending
> more files yet
> It appears 12 times, then I get the previous message! It's like a loop.
>
>
> > > > Please remove all of tracker's caches before testing:
> > > >
> > > >
> > > > svn co http://svn.gnome.org.svn/tracker/branches/indexer-split
> > > > cd indexer-split
> > > >
> > > > patch -p0 < crawler-more-than-one-file.diff
> > > >
> > > > ./autogen.sh --pr... && make && sudo make install
> > > >
> > > >
> > > > killall -9 tracker
> > > > killall -9 tracker-indexer
> > > > rm -rf $HOME/.cache/tracker
> > > > rm -rf $HOME/.local/share/tracker
> > > > rm -rf /tmp/*tracker*
> > > >
> > > > trackerd -v 3
> > > I saw something strange after I removed the caches: trackerd only found
> > > a few directories in my home. I removed caches twice and I ran trackerd
> > > each time with the following command:
> > >
> > >    trackerd -s 0 -v 3
> > > Then, I decided to run trackerd with this command:
> > >    trackerd -v 3
> > > and trackerd acted correctly by indexing the content of my home. Now it
> > > seems I can run trackerd with, and without, "-s 0" without any problem!
> >
> > No idea, tbh

Actually, you should try using trackerd -r, this reindexes everything.
This will remove all the databases for you. Removing the directories as
Phillip illustrates above is just as good (and a "to be sure" way).

Thanks for the patch, I have committed it! ;)

-- 
Regards,
Martyn