Re: [sdx-users] Unable to get a searcher object

[Martin Sevigny]

Salut,

> En redémarrant une application SDX qui donnait l'erreur
> java.lang.NullPointerException, on obtient dans les logs
> l'erreur suivante:
>
>   ConfigurationException:
>   Unable to get a searcher object for the Lucene index
>   located at ... (suit l'adresse de l'index)
>
> J'ai l'impression qu'il y a eu une "optimization" lancée
> qui s'est mal terminée; est-ce que cette opération peut
> corrompre les index?

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.

En général, ces fichiers ont les caractères "lock" dans leur nom et sont 
situés dans le dossier temp de tomcat, voir dans le work (je ne me 
rappelle plus très bien).

On arrête Tomcat, on les supprime, on redémarre et ça devrait marcher. 
Une prochaine optimisation devrait permettre de retrouver un index normal.

> Voici la liste des fichiers d'index:
>
> _2w2l.fdt       42 Mo
> _2w2l.fdx        0,5 Mo
> _2w2l.fnm        0,0003 Mo
> _2w2l.frq        9,7 Mo
> _2w2l.prx       12,4 Mo
> _2w2l.tii        0,015 Mo
> _2w2l.tis        1,14 Mo
> _30zj.cfs       88 Mo
>
> Le fichier .cfs est le fichier composé; quel est le
> rôle des autres?

Temporaires, pendant une indexation/optimisation je crois.

> Par ailleurs, qu'est-ce qui lance l'optimisation,

Du code Java ;-) Dans SDX, après chaque "batch".

> et
> que fait-elle?

Elle... optimise les index! Cuisine interne Lucene. Accélère les recherches.

> 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".

Martin Sévigny