Ok merci, je regarde ça ce matin.
Il faut vérifier votre objet “com.simplicite.objects.CrbForpro.CrbFopSession”
car simplicité cherche sa classe (voir si le document script est un fichier .java et le contenu du script).
Ensuite c’est peut être aussi votre mise à jour du SIM qui a eu un pb.
oui, com.simplicite.objects.CrbForpro.CrbFopSession a un script java.
et je n’y ai pas touché depuis pas mal de temps.
c’est clairement depuis le pb d’accès au formulaire que vous avez réglé que le pb existe.
notre maj de sim, j’ai fait un sim refresh et un sim up des instances, comme préconnisé. rien de plus
Le problème d’accès au formulaire depuis une liste fille était un pb de la UI donc purement javascript front, qui n’a aucune incidence sur le cache ou l’auto-upgrade en back.
On va regarder de nouveau ce qu’il y avait d’autre dans les dernières livraisons de patch correctif qui pourrait poser pb chez vous à 2h du matin.
Après vérification, les derniers patchs sont uniquement de la robustesse de code ou des correctifs mineurs suite à des remontées sur le forum :
Bref à priori rien a voir avec vos erreurs d’upgrade.
On va se mettre en condition V4 + postgreSQL pour voir si on reproduit votre problème.
(et sinon je n’ai pas encore reçu vos logs par mails)
je suis réunion toute la matinée … je fais ça dés que je sors
Les logs commencent à 2:02 au redémarrage de Tomcat.
=> Il faudrait donc aussi nous fournir les logs de la veille (enfin après minuit avant le démarrage tomcat).
il y a le module Markdown en auto-update, qui se met à jour à 4h sans soucis :
2021-01-14 04:00:24,441 INFO [com.simplicite.objects.System.Module] SIMPLICITE|https://Prod-sim-3:10038/gdr|/gdr|INFO|system|com.simplicite.objects.System.Module|updateModules||Evénement: Module Markdown auto-updated
2021-01-14 07:44:49,643 ERROR [com.simplicite.util.Tool] SIMPLICITE|https://Prod-sim-3:10038/gdr|/gdr|ECORED0001|system|com.simplicite.util.Tool|streamToObject||Erreur Error during deserialization: com.simplicite.extobjects.CrbGdr.CrbGdrResaAgenda
java.lang.ClassNotFoundException: com.simplicite.extobjects.CrbGdr.CrbGdrResaAgenda
Résolu par un clear-cache forcé = qui recompile tout sans pb.
Il faut donc voir si votre redémarrage Tomcat arrive trop tôt = avant la fin de l’upgrade.
On dirait qu’il n’a pas pu ou eu le temps de recompiler les classes car absente du classloader.
Bref je ne pense pas que le problème soit dans le runtime/socle, mais dans le processus de mise à jour qui ne doit pas se terminer correctement ou redémarrer tomcat avant d’avoir terminé.
Avez vous des taches cron vers 2h du matin en dehors du SIM sur vos serveurs, comme forcer un restart tomcat à 2:02, une sauvegarde… ?
crontab –l
nous ne faisons rien de particulier, pas de cron, pas de sauvegarde.
nous n’avons rien changé.
Ok mais il n’y a pas d’auto-patch sur cette instance au démarrage de tomcat (par exemple les instances sans SIM peuvent se mettre à jour toute seule au démarrage).
C’est donc le SIM qui fait la mise à jour avant de redémarrer tomcat.
Il faut donc regarder les logs durant cette étape.
J’essaye de reproduire votre pb, mais pour l’instant ça ne donne rien sur une instance V4 postgreSQL.
Si je résume :
Et
A titre préventif : il faut retirer l’auto-upgrade des instances la nuit, via la UI SIM ou par ligne de commande pour chaque instance (préférable de toute façon durant la période où tu seras absente, si jamais il y a un soucis de livraison comme lundi).
A titre curatif : on pourra mettre en place un “clear-cache forcé” à ton retour
En parallèle, il faut qu’on arrive à reproduire le problème qui existait peut être d’avant mais restait invisible (l’auto-upgrade ne se lançait peut être pas avant, la mise à jour du SIM a peut-être réactivé le traitement…) :
je retire l’auto-upgrade des instances
le pb est aussi sur les sim de recette, dev, je n’ai pas vérifié
Les instances sont en mode “autopatch” = application si nécessaire (= si les fichiers ont changés) des patches SQL/XML système au démarrage de la webapp.
Fondamentalement l’upgrade SIM (manuel ou en automatique la nuit) ne fait que:
Le SIM n’a pas évolué depuis des mois sur ce point.
NB1: Avant de démarrer Tomcat, le SIM supprime tous les fichiers de travail Tomcat et Simplicité (y compris les éventuels fichiers sérialisés) pour être certain de partir sur des “bases saines”
NB2: Il ne serait pas évident de mettre en place un “clear cache forcé après upgrade” piloté par le SIM (ou même par une crontable) car, comme je l’ai expliqué précédemment, le démarrage Tomcat rend la main au SIM tout de suite, il n’est donc pas souhaitable de solliciter la webapp (ex: pour un clear cache via curl sur /io) alors que celle-ci est encore en train de démarrer (et le temps de démarrage n’est pas déterministe)
PS: je pense comme @Francois qu’il convient de n’avoir aucun module marqué “Auto-update” car l’import planifié (dans la cron Simplicité) de ces modules est peut être de nature à perturber l’upgrade si ça se passe à un mauvais moment.
En curatif au CRB, je pensais plus à un clear-cache forcé via tache crontab à 2:15 du matin (puisque ça corrige à 8h à la main).
Je n’ai pas vu de suppression des modules compilés dans WEB-INF/build/*.jar qui aurait pu expliquer la disparition des classes.
Mais visiblement le SIM supprime les fichiers “.ser” donc le cache sérialisé “core.ser”.
Dans les logs du démarrage ça indique qu’il est bien désérialisé !?!
2021-01-14 02:02:44,914 INFO [com.simplicite.util.engine.CoreCache] SIMPLICITE|https://Prod-sim-3:10038/gdr|/gdr|INFO|system|com.simplicite.util.engine.CoreCache|deserialize||Param:(Deserialization success from dbdoc/cache/core.ser)
Ca n’a pas de sens, en tout cas il n’est pas reconstruit à cette étape (recopié d’ailleurs ?), ce qui explique peut être le pb.
Voici exactement ce que fait le SIM, en fait ça se passe dans le upgrade.sh après l’arret de Tomcat et avant de synchroniser la webapp:
(...)
echo "Removing serialized cache files"
find /home/$USER/tomcat/webapps/${SERVICE_CONTEXT:-ROOT}/WEB-INF -name \*.ser -exec rm -f {} \;
echo "Done"
(...)
echo "Clean dbdoc"
rm -fr /home/$USER/tomcat/webapps/${SERVICE_CONTEXT:-ROOT}/WEB-INF/cache
rm -fr /home/$USER/tomcat/webapps/${SERVICE_CONTEXT:-ROOT}/WEB-INF/dbdoc/cache
rm -fr /home/$USER/tomcat/webapps/${SERVICE_CONTEXT:-ROOT}/WEB-INF/recyclebin
rm -fr /home/$USER/tomcat/webapps/${SERVICE_CONTEXT:-ROOT}/WEB-INF/dbdoc/recyclebin
rm -fr /home/$USER/tomcat/webapps/${SERVICE_CONTEXT:-ROOT}/WEB-INF/tmp
rm -fr /home/$USER/tomcat/webapps/${SERVICE_CONTEXT:-ROOT}/WEB-INF/dbdoc/tmp
echo "Done"
(...)
NB: a ce stade on est sûr que Tomcat est bien totalement arrêté car on checke le fichier “lock” (catalina.pid) que Tomcat n’efface qu’à la fin de son processus d’arrêt.
Donc comment on peut expliquer que le core.ser est supprimé, puis présent quand tomcat redémarre ?
Si le cache est absent, il est normalement reconstruit et resérialisé au démarrage de tomcat.
Cette étape a disparue dans les logs fournies.
il va falloir relire les hooks.
Je vais faire des tests pour m’assurer que les *.ser sont bien supprimés par la commande ci-dessus, je vois pas pourquoi ce ne serait pas le cas…
Par contre si après l’upgrade il y a un arret/relance planifié d’une manière ou d’une autre sur ce serveur (j’ai le vague souvenir que quelque chose dans le genre avait été mis en place au CRB à une époque) ça peut peut être expliquer la présence du core.ser au démarrage le plus récent dans les logs
Oui mais Rosanne dit qu’il n’y a pas de cron… j’ai aussi d’abord pensé un “restart tomcat” en plein upgrade qui met plus de temps que d’habitude.
Le vidage de cache se fait tout seul si et seulement si le core.ser est absent au démarrage.
(j’ai rien vu non plus dans les hooks sim)
(j’ai demandé les logs de la veille ou d’avant 2:00)
Autre spécificité sur CRB : ils sont les seuls à utiliser des contextes non ROOT (genre /monappli), du coup je vois qu’il y a un pb dans le upgrade.sh : le .simplicite n’est pas pris en compte et donc ${SERVICE_CONTEXT:-ROOT} renvoie systématiquement “ROOT” ce qui ne va pas dans leur cas, du coup le core.ser n’est pas effacé (la commande de suppression a été modifiée récemment, avant elle supprimait tout *.ser dans /home/$USER/tomcat, c’était trop violent, on l’a rendue plus “locale”)
PS: J’ai fait la modif sur le upgrade.sh je vais y ajouter aussi la purge d’autres répertoires “de travail” de Simplicité dans WEB-INF : src, bin et jar notamment.
Comme ça on sera iso avec ce qu’on fait dans les images Docker. Enfin pas tout à fait iso car dans les images Docker ce ménage est fait avant tout démarrage de Tomcat
Oui c’est ça le problème et ça coïncide avec l’apparition du problème au CRB.
Mais bon il reste préférable de désactiver l’auto-upgrade en attendant le retour de Rosanne.
Oui sans doute, j’avais oublié leur cas particulier de contexte non ROOT… ce sera poussé ce soir et donc recupéré sur leur SIM avant les upgrades auto de cette nuit