Bonsoir, Merci; réponses ci-dessous...
> -----Message d'origine----- > De la part de Martin Sevigny > Envoyé : jeudi 31 août 2006 21:48 > > Corrompre, probablement pas. Mais les rendre inutilisables > temporairement, définitivement oui. > > En général, lorsque cela arrive, c'est parce qu'il y a un > fichier "lock" car Lucene a été interrompu pendant une > opération d'écriture. Non, quand il y a un problème avec un fichier .lock non supprimé, c'est signalé en clair dans les logs, y compris avec l'adresse du fichier .lock, et quand ça arrive c'est en effet simple à corriger. Mais là ce n'était pas le cas, il n'y avait pas de fichier .lock, c'est vraiment l'index qui semblait corrompu, puisqu'en le déplaçant vers une autre installation de la même application on avait la même erreur, ainsi qu'une autre, complémentaire, qui disait que Lucene avait essayé de lire après la fin du fichier (...?) Bref, on a réindexé. > > Est-ce qu'en supprimant l'élément > > sdx:optimization on évite toute intervention > > "automatique" sur les index? > > Au contraire. On rétablit le comportement par défaut qui > consiste à optimiser à la fin de chaque "batch". En fait notre problème vient du fait qu'il y a deux Tomcat qui attaquent le même ensemble de fichiers d'index; dans le cas de sdx:optimization j'ai l'impression que c'est l'un ou l'autre des Tomcat qui lance l'optimization -- tandis que dans le cas ancien "par défaut" c'est nécessairement le Tomcat qui indexe qui optimise? (ce qui est bien préférable dans notre configuration) Est-ce bien ça? Cdt, EB _______________________________________________ sdx-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sdx-users
