Tests sur le problème de mémoire actuel
Bonjour, J'ai effectué différents test concernant le problème de mémoire qui paralyse Cantharella. Le problème "semble" venir dans page de liste qui: - soit charge trop d'entité (toutes la liste d'un seul coup) - soit ne libére pas les listes chargées (mecanisme wicket de serialisation des pages) - soit quelque chose d'autre n'est pas libéré C'est forcement lié au pièce jointe dans le sens où le contenu des pièces jointe étant dans les entités, le contenu binaire est chargé, même s'il ne sert pas tant qu'on ne visualise ou modifie pas une fiche (specimen, molecules...). Il se produit plus vite avec les pièces jointes, mais ce n'est pas la cause d'origine. J'ai testé: - de détacher les listes dans les modèles de liste : la liste est rechargé à chaque fois, ca rend l'application très lente, mais au final, ca ne résoud pas le problème (peut-être qu'il arrive plus tard, mais c'est pas sûr - de déplacer le contenu binaire dans une nouvelle entité non navigable depuis le document. Cela ne charge jamais le contenu binaire sauf quand on a vraiment besoin. Par contre, cela change trop le fonctionnement pour l'edition/ajout/suppression/modification des documents avec le mecanisme de wicket (usecase). C'est wicket qui sauvegarde le contenu des entités modifiées, et on ne peut pas se permettre de faire des appels service 'autre' que celui de sauvegarde final de l'entité (specimen). - de désactiver le mecanisme de serialisation des page dans wicket (pas pris le temps de pousser vraiment car c'est compliqué). - de mettre à jour wicket (et toutes les autres librairies). C'est fait, mais cela ne corrige pas le problème. Je ne trouve pas de bonnes solutions à la gestion des contenus binaires dans wicket. Et je ne suis même pas certains que le problème soit là non plus: - il est possible que hibernate n'aime pas que l'on charge plein de byte[] d'affilé, et à force, il sature. En surchargeant le setter su contenu binaire pour ne pas le stocker (il est chargé quand même, mais pas stocké dans wicket, et donc non serialisé), le problème se produit quand même. Voilà où j'en suis. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
participants (1)
-
Eric Chatellier