Constructeur ExcelPOITool à partir d'un DocumentDB au format XLSx

Bonjour,

je souhaite pouvoir utiliser un fichier fourni par le métier (possiblement au format XLS ou XLSx) via un DocumentDB (field de type Document) mais le constructeur me renvoi l’erreur suivante:
InternalError: Java constructor for "com.simplicite.util.tools.ExcelPOITool" with arguments "java.io.ByteArrayInputStream,boolean" not found.

Voici le code utilisé:

var doc = DocumentDB.getDocument(otmp_res.getFieldValue("ITProjectResFile"),this.getGrant());
var xls = new ExcelPOITool(doc.getInputStream(), doc.getContentType().startsWith("application/vnd.openxmlformats"));

J’ai essayé d’utiliser les autres constructeurs sans plus de succès…

Merci beaucoup pour votre support.

NB: Plateforme Version=4.0.P20 BuiltOn=2018-07-13 20:42 (revision 5d7751543ceb62ff8a1ac684ded2c0abeea814d3)

Le constructeur: ExcelPOITool(java.io.InputStream in, boolean openxml) a été ajouté en P21, il n’est donc pas disponible en P20.

Seul le ExcelPOITool(java.io.InputStream in) existait en P20 et ne savait donc gérer que les formats XLS legacy (pas les XLSX), c’est d’ailleurs pour cela que ça a été refactoré et que ce constructeur est désormais deprecated.

Bnojour David, merci beaucoup pour ta réponse rapide.
En effet, nous avions commencé à tester sur la P21b puis nous sommes revenus en P20(dernière stable CentOs)… d’où ma confusion…
Je ressayerai en P21 dès que possible.

Bonsoir David,

j’ai un autre problème que je n’arrive pas à résoudre…
Lorsque je lance une action (lancement en crontab piloté par un paramètre), l’action s’exécute semble-t-il bien mais la CPU continue de mouliner sans fin et les performances sont de ce fait de plus en plus dégradées. Il faut que je procède à un restart de tomcat (je redéploie mon conteneur docker; seule procédure connue de mon coté) pour que l’instance Simplicité refonctionne normalement. Ce comportement et obtenu systématiquement lorsque l’action est déclenchée…

J’ai chargé ma config dans l’instance renault-dev.simplicite.io.
J’ai lancé l’action et la CPU mouline… Je ne comprends pas pourquoi le(s) thread(s) continue(nt) de consommer des ressources; la log système n’affiche plus rien concernant cette action…

Il s’agit de l’objet métier BCSISAVAM (domaine Projets IT), action importSAVAM (méthode BCSISAVAM.importSAVAM) déclenchée par le cron si le flag BCSI_ITP_SAVAM_STATUS=RUNNABLE.

J’avais initialement fait les choses plus simplement en lançant cette action en mode synchrone depuis la liste BCSISAVAM (sans passer par cron) et j’avais déjà ce problème de CPU => j’ai tenté de faire comme pour nos chaînes d’import quotidiennes via cron qui n’ont pas ce problème).

Encore merci pour ton aide.

ps: la CPU de https://renault.dev.simplicite.io/ui/ mouline sans fin depuis ~17h20… désolé…

pps: autre problème qui ne se pose que sur l’instance cloud (et pas chez nous) l’utilisation de l’évaluateur de formules de ExcelPOITool fait planter le code sans aucune erreur… j’ai commenté les lignes correspondantes:

//var evaluator = wb.getCreationHelper().createFormulaEvaluator();
...
var savamReelTotalDB = 0;//evaluator.evaluate(datarow.getCell(69)); var savamReelTotalDB = datarow.getCell(69).getNumericCellValue();
var savamReelTotalDN = 0;//evaluator.evaluate(datarow.getCell(70)); var savamReelTotalDN = datarow.getCell(70).getNumericCellValue();

EDIT de 19h30: j’ai redéployer à nouveau sur notre docker intranet et il semble que l’action se termine à présent bien sans que la CPU ne mouline après…
Ce qui a changé: j’ai espacé dans le temps les cron JobXXX (toutes les 5 minutes au lieu de toutes les minutes) et j’ai purgé la liste des jobs asynchrones (plusieurs dizaines de jobs LogMemory au statut initialisé depuis plusieurs jours et non purgés)…
Sur l’instance cloud, il y a ~39000 jobs mais ils sont tous à l’état “terminé”… pas de job “initialisé” comme j’avais sur mon instance docker intranet…

Nous ne pouvons pas vraiment investiguer ce genre de choses. Il faudrait déjà s’assurer que le traitement lancé toutes les 5 min ne dure pas plus de 5 minutes. S’il y a le moindre doute là dessus il faut impérativement mettre l’attribut “Unique” du cron job à “Oui” (cela évite de lancer un job alors que le précédent n’est pas terminé). Ensuite un CPU qui tourne à 100% dans le vide ça signifie en général du code qui part en boucle (genre une boucle infinie ou des boucles imbriquées qui se mélangent les pinceaux entre les variables d’indice de boucle etc.)

Pour ce qui est de l’autre sujet (le pps), c’est peut être lié à l’upgrade de la lib Apache POI sur la branche master (4.0 vs 3.17 précédement). Il faudrait s’assurer que les APIs POI utilisées sont bien toujours supportées par cette nouvelle version (cf. https://poi.apache.org/changes.html il y a des changements qui visiblement cassent la compatibilité avec la 3.x)

Je comprenais pas pourquoi toutes mes actions mettaient du temps sur un autre projet…
ssh top => J’ai du killer un process renault sur dev qui prennait 100% de CPU.

  • vous avez une boucle infinie dans votre code

  • de notre côté il faudrait qu’on ait un agent qui surveille les process long trop longtemps sur dev / ou isoler/limiter les tomcat en prise de CPU globale

Bonjour François, David,
merci beaucoup pour vos retours.
a priori, pas de boucle infinie car les logs de la méthode indiquent que le traitement est bien terminé (il dure moins d’une minute avec les données de test constituées).
L’action déclenchée par cron indique elle aussi se terminer normalement.

Je viens d’aller voir sur l’instance https://renault.dev.simplicite.io et la CPU est jrs chargée (thread Simplicité à 50%). Le cron est activé, il lance l’action toutes les minutes; l’actio nrend la main tout de suite car le test du flag positionné n’est pas vérifié.

2018-09-17 10:14:01,765 INFO [com.simplicite.util.engine.CronManager] SIMPLICITE|https://dev.simplicite.io:10353||INFO|system|com.simplicite.util.engine.CronManager|run||Evénement: Next cron job: BCSI-importSAVAMCron at Mon Sep 17 10:15:00 CEST 2018

2018-09-17 10:14:01,630 INFO [com.simplicite.util.CronJob] SIMPLICITE|https://dev.simplicite.io:10353||ICORECM005|system|com.simplicite.util.CronJob|run||Résultat de la tâche BCSI-importSAVAMCron :

2018-09-17 10:03:00,735 INFO [com.simplicite.util.engine.CronManager] SIMPLICITE|https://dev.simplicite.io:10353||INFO|system|com.simplicite.util.engine.CronManager|run||Evénement: Next cron job: BCSI-importSAVAMCron at Mon Sep 17 10:04:00 CEST 2018
2018-09-17 10:03:00,725 INFO [com.simplicite.util.CronJob] SIMPLICITE|https://dev.simplicite.io:10353||ICORECM005|system|com.simplicite.util.CronJob|run||Résultat de la tâche BCSI-importSAVAMCron :
2018-09-17 10:03:00,725 INFO [com.simplicite.util.ScriptInterpreter] SIMPLICITE|https://dev.simplicite.io:10353||INFO|a068181|com.simplicite.util.ScriptInterpreter|BCSISAVAM/job_BCSISAVAM||Evénement: [IN BCSISAVAM.importSAVAM] BCSI_ITP_SAVAM_STATUS<>RUNNABLE(LOAD SUCCESS); CANCEL
2018-09-17 10:03:00,724 INFO [com.simplicite.util.CronJob] SIMPLICITE|https://dev.simplicite.io:10353||ICORECM004|system|com.simplicite.util.CronJob|run||Execute la tâche BCSI-importSAVAMCron à la date 2018-09-17 10:03:00
2018-09-17 10:02:01,359 INFO [com.simplicite.util.engine.CronManager] SIMPLICITE|https://dev.simplicite.io:10353||INFO|system|com.simplicite.util.engine.CronManager|run||Evénement: Next cron job: BCSI-importSAVAMCron at Mon Sep 17 10:03:00 CEST 2018
2018-09-17 10:02:01,340 INFO [com.simplicite.util.CronJob] SIMPLICITE|https://dev.simplicite.io:10353||ICORECM005|system|com.simplicite.util.CronJob|run||Résultat de la tâche BCSI-importSAVAMCron :
2018-09-17 10:02:01,339 INFO [com.simplicite.util.ScriptInterpreter] SIMPLICITE|https://dev.simplicite.io:10353||INFO|a068181|com.simplicite.util.ScriptInterpreter|BCSISAVAM/job_BCSISAVAM||Evénement: [IN BCSISAVAM.importSAVAM] BCSI_ITP_SAVAM_STATUS<>RUNNABLE(LOAD SUCCESS); CANCEL
2018-09-17 10:02:01,339 INFO [com.simplicite.util.CronJob] SIMPLICITE|https://dev.simplicite.io:10353||ICORECM004|system|com.simplicite.util.CronJob|run||Execute la tâche BCSI-importSAVAMCron à la date 2018-09-17 10:02:01
2018-09-17 10:01:00,951 INFO [com.simplicite.util.engine.CronManager] SIMPLICITE|https://dev.simplicite.io:10353||INFO|system|com.simplicite.util.engine.CronManager|run||Evénement: Next cron job: BCSI-importSAVAMCron at Mon Sep 17 10:02:00 CEST 2018

le code de la méthode concernée:

BCSISAVAM.importSAVAM = function() {
	var sts = Grant.getSystemAdmin().getParameter("BCSI_ITP_SAVAM_STATUS");
	if ( sts == "RUNNABLE" ) {
		console.log("[IN BCSISAVAM.importSAVAM] BCSI_ITP_SAVAM_STATUS="+sts+"; GO ON");
		try {...}
		} catch(e) {
			console.error(e);
			this.getGrant().setSystemParam("BCSI_ITP_SAVAM_STATUS","LOAD FAILURE (get resource)",true);
		}
		
	} else {
		console.log("[IN BCSISAVAM.importSAVAM] BCSI_ITP_SAVAM_STATUS<>RUNNABLE("+sts+"); CANCEL");
	}
};

NB: le kill du process Renault n’a pas réglé le pb semble-t-il…

Merci beaucoup pour votre aide.
Cdlt

oui c’est revenu, il y a qq chose qui boucle pas nécessairement à ce niveau. que contient le try/catch ?
s’il invoque une action asynchrone elle lance un autre thread à part et rend la main à l’appelant, l’action est invokée dans ce nouveau thread (pool de 10 jobs en // max par défaut)

je vais faire un java heap dump de votre instance, puis la re-killer, merci de pas la redémarrer tant qu’on a pas analyser le thread ou trouvé la cause dans le code.

J’ai redémarré votre instance et le cron s’exécute sans repartir en boucle.
Etes vous sûr que c’est ce job qui boucle ?

Je n’ai rien vu de spécial dans le heap dump, à refaire si cela recommence.

Merci beaucoup pour ton intervention.

Le try/catch contient une boucle while bouclant sur les lignes classeur Excel scanné par ExcelPOITool (avec instanciation d’un évaluateur de formule). Je ne sais pas si l’ExcelPOITool et l’évaluateur de formule sont eux-mêmes multi-threadés. Notre code ne l’est pas et aucune autre action n’est exécutée depuis cette boucle.

Nous refaisons des tests en interne sur nos instances en ayant désactivé toutes les tâches cron “Log*” sauf LogSystem (pour mesurer l’activité des threads). Nous avons pour l’instant testé sur un jeu de données de taille très réduite (2 lignes dans l’excel) et n’avons relevé aucune activité CPU suspecte après l’exécution de notre action. Un deuxième jeu de test avec 20000 lignes est en cours d’exécution et nous observons bien une activité CPU pendant cette exécution (~10%). Nous attendons la fin de cette action pour constater si une activité CPU persiste au delà ou pas.

Nous relancerons ensuite ce scénario (jeu de test réduit puis complet) en réactivant successivement les actions systèmes Log* pour revenir progressivement à la configuration nominale. Nous pensons en effet que
l’une de ces actions Logxxx auto-génère de la charge (LogMemory est le principal suspect avec la complicité du Garbage Collector).

Parfait,
j’ai été voir le code de votre objet sur notre dev et je ne vois rien de spécial.

En cas de CPU à 100%, si vous pouviez faire un dump des threads depuis l’ihm (bouton sur le monitoring qui exporte un dump dans les répertoire des exports) ou directement sur la VM via commande `jstack -l [pid java] > [dump file]

ensuite on pourra analyser les stacks des threads et voir si c’est une classe Excel/POI qui boucle.

Sinon le monitoring liste les threads et si on click dans la liste, on voit la stack d’appel java à droite.

Pour en revenir au sujet POI, on a décidé de revenir en arrière sur l’upgrade de 3.17 en 4.0.0 en P21, en effet il y a des deprecation d’APIs dans cette nouvelle version de la lib qui posent qques problèmes à nos wrappers, or la résolution de ces pb n’est pas compatible avec l’objectif de release à court terme de la P21

OK, merci David pour l’info.
On reste pour l’instant sur les POI au format legacy XLS…

NB: dans le cas des XLSx Office 2007 ou Strict OpenXML, nous avions les erreurs suivantes avec la P21b:

2018-09-17 16:18:04,821 ERROR [com.simplicite.util.ScriptInterpreter] SIMPLICITE|http://c003913adc37:8080||ECORESC001|a068181|com.simplicite.util.ScriptInterpreter|BCSISAVAM/job_BCSISAVAM||Erreur script: JavaException: org.apache.poi.POIXMLException: Strict OOXML isn't currently supported, please see bug #57699
2018-09-17 16:02:00,415 ERROR [com.simplicite.util.ScriptInterpreter] SIMPLICITE|http://c003913adc37:8080||ECORESC001|a068181|com.simplicite.util.ScriptInterpreter|BCSISAVAM/job_BCSISAVAM||Erreur script: JavaException: org.apache.poi.poifs.filesystem.OfficeXmlFileException: The supplied data appears to be in the Office 2007+ XML. You are calling the part of POI that deals with OLE2 Office Documents. You need to call a different part of POI to process this data (eg XSSF instead of HSSF)
Version=4.0.P21b
BuiltOn=2018-09-06 12:12 (revision da25768f5f502de0209d51adaf00a88711400f7b)

Ok vous êtes calés sur la P21 branche prerelease ?

Bonjour David, je pense que Marouane a installé la dernière P21 mise à dispo dans le conteneur Renault sur le dockerhub. Je ne sais pas s’il s’agit d’une prerelease…

Nous avons déroulé notre protocole de test jusqu’au bout et les problèmes de performance sont réapparus après avoir réactivé l’ensemble des tâches cron de l’objet AppLoggerMemory (en particulier les actions Log*Memory; les actions LogSession, LogSQL et LogSystem ont été réactivées avant et n’ont pas posé de problème).

Lorsque les performances se sont dégradées à nouveau, je suis allé voir dans la liste des AsyncJob et j’ai retrouvé comme vendredi dernier des jobs à l’état Initialisé (plusieurs dizaines) ou En cours d’exécution (qques occurrences) pour toutes les actions AppLoggerMemory.

Le problème semble plus du être côté de l’empilement des actions Log*Memory à l’état Initialisé (le cron les lance toutes les minutes). Le problème semble être résolu en modifiant la fréquence à 5 minutes et en purgeant la table AsynJob.

Il y a peut-être un problème de performances global sur nos env de DEV en ce moment. Mais dans ce cas là, il faudrait éviter que la plateforme puisse se surcharger elle-même en empilant des jobs de monitoring qui seraient lancés en parallèle. La conf actuelle des actions Log*Memory indique “-3” jours de profondeur (je comprends qu’on va conserver jusqu’à 3 jours de traces des exécutions) et la propriété “Unique” est à Non (je comprends que tous les noeuds/serveurs peuvent exécuter cette action en parallèle). Rien ne semble limiter à une seule instance sur un même noeud/serveur à un instant donné…

Je tiens à ta disposition une copie d’écran de la vue AsyncJob aunsi qu’un export XML des records concernés réalisé avant la purge de la table.

NB: Lors de la dernière “surcharge”, l’instance Tomcat a été killée (automatiquement je pense) => il est tout à fait possible que les actions “En cours d’exécution” aient été laissées en l’état lors du kill… Lors de cette surcharge, l’action instanciant ExcelPOITool n’avait pas été lancée depuis hier. Nous étions 2 connectés avec des activités de paramétrage tout à fait usuelles (config d’objets métier et de champs).

La P21 n’est pas encore releasée mais a été plusieurs fois prereleasée.

Quelle image Docker utilisez vous ?

Si vous utilisez la “alpha” c’est la P21 branche master (donc mise à jour au moins une fois par jour et pas toujours très stable), si c’est la “beta” c’est la P21 branche prerelease (poussée une fois par semaine en moyenne et relativement stable).

Cf. Branches and Docker images

Pour le reste nous avons constaté que votre instance renault mise à dispo sur notre serveur de dev est elle aussi partie en vrille, nous l’avons arrêtée à titre conservatoire pour ne pas pénaliser les autres instances déployées sur ce serveur.

Du coup nous pensons que le pb se situe dans votre paramétrage… Pour moi, comme je l’ai déjà indiqué je pense qu’on est sur une boucle infinie (ou très longue)

Bonjour David,

merci pour ton retour.

Nous n’avons pas réactivé la fameuse méthode instanciant l’ExcelPOITool depuis lundi et ne nous sommes pas reconnectés sur la plateforme depuis mardi non plus.
La CPU mouline sans fin depuis ~6h ce matin (enfin c’est ce qu’indiquent les mesures).

Nous avons détecté un pb sur un objet métier inaccessible depuis le menu (objet BCSIITProject accessible par le menu Projets IT; pas de réponse au clic sur le menu de gauche pour afficher l’objet ni en passant par une recherche d’objet métier par le menu administration pour afficher la configuration de l’objet). Le problème a été résolu en supprimant l’objet depuis une recherche d’objet métier (il est bien trouvé) et en le recréant manuellement.

Cet objet avait été créé en utilisant le modeleur en mode responsive. Cette création a été faite pendant que nous testions la nouvelle méthode ExcelPOITool et que nous commencions à observer des problèmes de temps de réponse (et de bad gateway). Du coup, je pense que cet objet est configuré de manière bancale.

La suppression/création a résolu semble-t-il le pb d’accessibilité par le menu et nous n’avons plus de pb de perf sur le DEV désormais.

Je resynchronise les modules concernés pour voir si ça règle le pb de CPU qui mouline…

Bon, je n’ai pas eu le temps de resynchroniser le principal module concerné (BCSIModule_ITProject).
L’instance est tombée en “Bad Gateway” dès que j’ai lancé l’import du patch XML…

J’espère que c’est toi qui a stoppé l’instance…

Je vais supprimer l’objet manuellement avant de relancer le patch dès que l’instance est de nouveau disponible.

Ou c’est nous qui l’avons stoppé car ça pénalisait trop les perfs du serveur.
Je peux la redémarrer si besoin mais plutôt ce midi.

L’ideal serait peut être que vous disposiez d’un serveur “bac à sable” dédié c’est ce qui se fait avec d’autres clients…

OK pour midi…

Je ne sais pas si le serveur “bac à sable” est plus indiqué.

Cette instance nous sert essentiellement pour reproduire des comportements observés sur nos env en nous appuyant sur une version le plus à possible. Elle sert du coup très rarement mais pour tester des cas “douteux” pour la plupart ou pour reproduire des bugs potentiels ou pour illustrer des cas abordés dans nos échanges (ergonomie, pb d’IHM, question de config particulière, …).

PS: j’ai oublié de répondre à ta question sur la branche: il s’agit a priori bien de la branche “beta”.