Bonjour,
nous sommes plusieurs à rencontrer des problèmes sur Gchange depuis 3 jours, les annonces ne se chargent pas ou seulement une vingtaine puis plus rien, ça mouline…
Rencontrez-vous aussi ce genre de soucis ?
@kimamila ton pod est-il synchronisé ?
Amicalement, Francis
1 Like
J’avais le même soucis en effet.
Je viens de redémarrer le pod gchange, ça semble mieux de mon côté.
(Je sais que Kimamila n’est pas disponible en ce moment, c’est pour ça que j’interviens)
1 Like
Je viens d’y aller et je n’ai pas de soucis. Au lancement, l’appli m’a demandé si je voulais changer le noeud de données pour gchange.data.presles.fr mais à part ça tout va bien de mon côté.
1 Like
Alors je viens d’y aller, effectivement maintenant il me dit que le pod n’est pas joignable et d’utiliser celui de Bertrand, il y a donc du mieux, merci 
Le problème était que le pod gchange par defaut était configuré en dur sur le noeud g1.librelois.fr qui lui est down.
J’ai donc remplacé par le noeud g1.duniter.org.
Le pod est en train de synchroniser, il sera up bientôt.
3 Likes
Merci !
C’est bon, tout est fonctionnel.
Cool, merci !!
1 Like
Bonjour,
Ça semble à nouveau en panne.
@poka ^^
J’ai redémarré le pod, ça semble mieux, mais je ne saurais dire pourquoi …
Dans les logs je repère notamment ce genre d’erreur que je ne sais pas interpréter:
[2022-04-04 15:33:16,486][ERROR][duniter.rest.user ] [gchange-pod-1][[user]] Document contains at least one immense term in field="content" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[104, 71, 73, 83, 86, 68, 98, 54, 102, 48, 109, 69, 69, 108, 121, 79, 111, 112, 76, 77, 112, 109, 73, 114, 70, 68, 65, 102, 108, 48]...', original message: bytes can be at most 32766 in length; got 57004
java.lang.IllegalArgumentException: Document contains at least one immense term in field="content" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[104, 71, 73, 83, 86, 68, 98, 54, 102, 48, 109, 69, 69, 108, 121, 79, 111, 112, 76, 77, 112, 109, 73, 114, 70, 68, 65, 102, 108, 48]...', original message: bytes can be at most 32766 in length; got 57004
at org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:692)
at org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:365)
at org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:321)
at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:234)
at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:450)
at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1477)
at org.elasticsearch.index.engine.InternalEngine.innerIndex(InternalEngine.java:538)
at org.elasticsearch.index.engine.InternalEngine.index(InternalEngine.java:454)
at org.elasticsearch.index.shard.IndexShard.index(IndexShard.java:605)
at org.elasticsearch.index.engine.Engine$Index.execute(Engine.java:836)
at org.elasticsearch.action.index.TransportIndexAction.executeIndexRequestOnPrimary(TransportIndexAction.java:236)
at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:157)
at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:66)
at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryPhase.doRun(TransportReplicationAction.java:657)
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryOperationTransportHandler.messageReceived(TransportReplicationAction.java:287)
at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryOperationTransportHandler.messageReceived(TransportReplicationAction.java:279)
at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:77)
at org.elasticsearch.transport.TransportService$4.doRun(TransportService.java:378)
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.lucene.util.BytesRefHash$MaxBytesLengthExceededException: bytes can be at most 32766 in length; got 57004
at org.apache.lucene.util.BytesRefHash.add(BytesRefHash.java:284)
at org.apache.lucene.index.TermsHashPerField.add(TermsHashPerField.java:150)
at org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:682)
... 22 more
Je met ça là pour garder une trace pour @kimamila, même si je ne pense pas que ce soit bloquant, ni que ce soit la cause du problème.
Chez moi il me propose de changer de noeud pour celui de Bertrand car le celui de Benoit est injoignable.
Le pod resynchronise et ça devrait être bon.
1 Like