NPE durant la reindexation
Bonjour, La reindexation ne fonctionne pas et se termine par une NPE : java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.nuiton.util.ObjectUtil.call(ObjectUtil.java:327) at org.nuiton.util.ApplicationConfig$Action.doAction(ApplicationConfig.java:556) at org.nuiton.util.ApplicationConfig.doAction(ApplicationConfig.java:943) at com.jurismarches.vradi.VradiServiceMain.main(VradiServiceMain.java:52) Caused by: org.nuiton.wikitty.WikittyException: Can't store wikitty at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.store(WikittySearchEngineSolr.java:322) at org.nuiton.wikitty.services.WikittyServiceStorage$1.scan(WikittyServiceStorage.java:960) at org.nuiton.wikitty.jdbc.WikittyStorageJDBC.scanWikitties(WikittyStorageJDBC.java:473) at org.nuiton.wikitty.services.WikittyServiceStorage.syncSearchEngine(WikittyServiceStorage.java:947) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceSecurity.syncSearchEngine(WikittyServiceSecurity.java:539) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.WikittyProxy.syncSearchEngine(WikittyProxy.java:1069) at com.jurismarches.vradi.VradiServiceAction.reIndexSolr(VradiServiceAction.java:94) ... 8 more Caused by: java.lang.NullPointerException at org.nuiton.wikitty.storage.solr.SolrUtil.copySolrDocument(SolrUtil.java:220) at org.nuiton.wikitty.storage.solr.SolrUtil.copySolrDocument(SolrUtil.java:271) at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.addTreeIndexField(WikittySearchEngineSolr.java:574) at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.store(WikittySearchEngineSolr.java:320) ... 18 more J'ai regardé vite fait le code, mais je ne sais pas si le code peut fonctionner en gerant cette valeur null, ou si c'est une erreur. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
On Mon, 21 Feb 2011 11:05:23 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Bonjour,
La reindexation ne fonctionne pas et se termine par une NPE : ... Caused by: java.lang.NullPointerException at org.nuiton.wikitty.storage.solr.SolrUtil.copySolrDocument(SolrUtil.java:220) at org.nuiton.wikitty.storage.solr.SolrUtil.copySolrDocument(SolrUtil.java:271) at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.addTreeIndexField(WikittySearchEngineSolr.java:574) at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.store(WikittySearchEngineSolr.java:320) ... 18 more
J'ai regardé vite fait le code, mais je ne sais pas si le code peut fonctionner en gerant cette valeur null, ou si c'est une erreur.
En fait, dans notre cas, on reindexe tout. Et tout ne peut pas passer dans une seule transaction. Donc on fait des commits regulier. Avec seulement une partie des données. Il y a donc plusieurs probleme qu'il faut regler: 1) on sauve un TreeNode mais tous ses parents ne sont pas encore dans SolR 2) on sauve un TreeNode mais les attachments ne sont pas encore dans SolR Pour le 1 normalement, ce n'est pas un problème, à un moment donné, on va enregistrer les parents manquant et l'indexation des fils se fera a ce moment la. Pour le 2 c plus compliqué, il faut lors de la sauvegarde du TreeNode passer sous silence les attachments manquant. Mais dès qu'un de ces attachments se fait indexer il faut aussi ajouter les champs d'indexation d'arbre. Il faut donc rechercher si l'objet est un attachment pour un ou plusieurs TreeNode. Ce qui n'est pas fait actuellement :(. Je corrige et je commit. Avec cette base de données, on a un bon jeu de test de migration, Mais ce serait bien de faire un test unitaire tout de meme, je vais ajouter un ticket car je n'ai pas le temps de faire le test :( -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Mon, 21 Feb 2011 15:11:56 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Pour le 2 c plus compliqué, il faut lors de la sauvegarde du TreeNode passer sous silence les attachments manquant. Mais dès qu'un de ces attachments se fait indexer il faut aussi ajouter les champs d'indexation d'arbre. Il faut donc rechercher si l'objet est un attachment pour un ou plusieurs TreeNode.
Ce qui n'est pas fait actuellement :(. Je corrige et je commit.
Corrigé dans le trunk, tu peux relancer une reindexation avec le nouveau trunk stp. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le 21/02/2011 19:05, Benjamin POUSSIN a écrit :
Corrigé dans le trunk, tu peux relancer une reindexation avec le nouveau trunk stp J'ai lancé une reindexation, mais ca fait maintenant 6heures qu'elle est en cours. Je commence a me demander s'il n'y aurait pas une boucle infinie.
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 22/02/2011 15:27, Eric Chatellier a écrit :
Le 21/02/2011 19:05, Benjamin POUSSIN a écrit :
Corrigé dans le trunk, tu peux relancer une reindexation avec le nouveau trunk stp J'ai lancé une reindexation, mais ca fait maintenant 6heures qu'elle est en cours. Je commence a me demander s'il n'y aurait pas une boucle infinie. Je l'ai arrêté et relancé avec ton commit pour la progression.
Maintenant j'ai une erreur étrange dûe à common-dbcp dès le lancement :( org.nuiton.wikitty.WikittyException: Can't sync searchable index with data at org.nuiton.wikitty.services.WikittyServiceStorage.syncSearchEngine(WikittyServiceStorage.java:1005) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceSecurity.syncSearchEngine(WikittyServiceSecurity.java:539) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.WikittyProxy.syncSearchEngine(WikittyProxy.java:1074) at com.jurismarches.vradi.VradiServiceAction.reIndexSolr(VradiServiceAction.java:94) ... 8 more Caused by: java.lang.NullPointerException at org.apache.commons.dbcp.managed.ManagedConnection.close(ManagedConnection.java:147) at org.nuiton.wikitty.jdbc.WikittyJDBCUtil.closeQuietly(WikittyJDBCUtil.java:321) at org.nuiton.wikitty.jdbc.WikittyStorageJDBC.scanWikitties(WikittyStorageJDBC.java:480) at org.nuiton.wikitty.services.WikittyServiceStorage.syncSearchEngine(WikittyServiceStorage.java:953) ... 15 more -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
On Wed, 23 Feb 2011 11:11:14 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Caused by: java.lang.NullPointerException at org.apache.commons.dbcp.managed.ManagedConnection.close(ManagedConnection.java:147) at org.nuiton.wikitty.jdbc.WikittyJDBCUtil.closeQuietly(WikittyJDBCUtil.java:321) at org.nuiton.wikitty.jdbc.WikittyStorageJDBC.scanWikitties(WikittyStorageJDBC.java:480) at org.nuiton.wikitty.services.WikittyServiceStorage.syncSearchEngine(WikittyServiceStorage.java:953) ... 15 more
Je regarde ca. Mais je pense qu'il faut modifier la facon de faire (apres grosse cogitation pour trouver comment faire pour ameliorer les choses :)) Ici, pour prevenir le cas ou le TreeNode est index avant l'attachment, des qu'on ajoute un objet on verifie qu'il ne serait pas aussi un attachment (ce qui semble tres couteux). Je pense qu'il faut proceder autrement. Que l'attachment soit present ou non on cree l'enregistrement solr pour cette attachment avec l'indexation arbre (si l'attachment n'est pas present, dans le doc solr, il n'y aura que l'indexation arbre et l'id) Ensuite lorsque l'objet est reellement indexer, il recuperer ces infos deja construite pour son indexation (comme il faisait avant) Normalement, on devrait revenir a environs 2h pour la reindexation de 300000 documents. Je corrige ca cet apres midi -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le 23/02/2011 13:35, Benjamin POUSSIN a écrit :
Je regarde ca.
Mais je pense qu'il faut modifier la facon de faire (apres grosse cogitation pour trouver comment faire pour ameliorer les choses :))
Ici, pour prevenir le cas ou le TreeNode est index avant l'attachment, des qu'on ajoute un objet on verifie qu'il ne serait pas aussi un attachment (ce qui semble tres couteux).
Je pense qu'il faut proceder autrement. Que l'attachment soit present ou non on cree l'enregistrement solr pour cette attachment avec l'indexation arbre (si l'attachment n'est pas present, dans le doc solr, il n'y aura que l'indexation arbre et l'id)
Ensuite lorsque l'objet est reellement indexer, il recuperer ces infos deja construite pour son indexation (comme il faisait avant)
Normalement, on devrait revenir a environs 2h pour la reindexation de 300000 documents. Après maintes corrections, elle a fonctionné. Effectivement en 2 heures.
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
participants (2)
-
Benjamin POUSSIN -
Eric Chatellier