Salut,
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.
C'est vrai, t'as raison, ça fait longtemps que j'avais eu le problème, j'avais oublié...
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?
Ouf, deux Java sur le même jeu d'index? C'est possible, mais il faut qu'il y en ait un seul qui soit "en écriture". Le problème, c'est que rien n'est prévu dans SDX pour empêcher toute opération d'écriture. C'est du moins mon impression...
On avait déjà eu l'idée de faire un <sdx:documentBase read-only="true"/> et blinder un peu le code, mais le besoin n'est jamais venu...
Martin Sévigny _______________________________________________ sdx-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sdx-users
