Le paramétrage semble bien éviter tous ces threads.
Pour le rattrapage de l’indexation, ce sera secondaire
Pour mémoire:
Comme discuté en call, dans les adapters, il faut utiliser des getBatchObject et pas des getTmpObject pour que l’indexation fulltext soit synchrone dans un contexte de traitement en masse
Ou, comme suggéré par @Francois, inhiber le service d’indexation fulltext le temps des traitements
Parfait,
Je note tout de même un besoin d’optimisation/robustesse = ne pas créer de Thread en attente, mais uniquement des Runnable en mémoire, et de les allouer réellement qu’à l’exécution.
En 5.2 les threads seront créés au moment de leur exécution uniquement. Ca évitera ce genre de limitation en nombre de threads, par contre cela prendra de la place dans le heap Java qui va empiler les taches à venir.
On ne pourra pas reporter ce changement de fonctionnement en V4 ou 5.1.
Il reste fortement conseillé :
- de ne pas activer l’indexation fulltext USE_SEARCH_INDEX=no lors d’un import en masse (et de faire un rebuild à la fin),
- ou alors d’utiliser des instances d’objet getBatchObject uniquement qui génèrent ces indexes de façon synchrone (import plus long).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.