Bonjour,
Depuis hier, lorsque je me connecte à la plate-forme de formation et que je suis sur la page d’accueil, des erreurs apparaissent dans les logs et lorsque je clique sur notre application, j’ai aussi le problème, vous trouverez ci-joint les screens.
Version=5.0.0-beta
BuiltOn=2020-11-28 19:15
En complément :
Merci d’indiquer la révision Git, le numéro de version et la date du build pour les branches “alpha/master” et “beta/prerelease” n’est pas suffisant.
Quelles options de démarrage Docker utilisez vous ? Je pose la question notamment vis à vis des paramètres de “cleansing”
Avez vous tenté de forcer une recompilation globale en faisant un “save all” dans l’éditeur de code ?
Aucune idée, mais les classes des modules sont absentes, ou ne se chargent pas (cause d’erreur d’instanciation non visible dans le screen-shot).
Simplicité instancie des objets par défaut pour dépannage temporaire (pour le designer uniquement, les autres accès utilisateur sont refusés), mais du coup il n’y a pas de règles métier/hooks chargés.
Voici les informations de la plateforme Simplicité :
Simplicité version5.0.0-beta
Built on2020-11-28 19:15
Git infoprerelease/44d4dbc090b1e4b75a5e2bb2b293725bfecc6a42
Database level5;P00b;272d9f1587bd886d22499c1b21dcd0ee
les seuls paramètres utilisés hormis ceux pour l’accès BDD: -Xms256m -Xmx1024m
Les logs vous le trouverez en pièce joint.
logs.log (38.7 KB)
OK vous n’avez pas répondu à la question de @Francois sur le fait que les sources sont toujours accessibles dans l’éditeur de code
Ni à ma suggestion de forcer une recompilation globale par un “Save all” sur l’éditeur de code
Sinon cette révision est en retard de 25 commits sur sa branche, y compris des modifications allant dans le sens de plus de robustesse vs vos cas de pertes de ressources ou de code. Ce serait donc bien de commencer par upgrader cette instance afin d’être sûr que ce n’est pas un symptôme d’un pb résolu par ces modifications
Nous allons procéder a la maj des serveurs. Pour info les sources sont toujours accessibles et le save ALL n’a pas eu plus d’effet.
OK cela ressemble au symptôme que j’ai eu pendant le webinar sur l’usage des IDE qu’un clear cache n’avait pas résolu et que je n’ai pas réussi à reproduire ensuite (ni à investiguer car j’avais été obligé de supprimer le container et redémarré from scratch)
Pour la petite histoire, c’est suite à ce pb et à titre conservatoire que j’ai ajouté les mécanismes de cleaning au démarrage dans les images Docker (cf. https://docs.simplicite.io/documentation/90-operation/docker.md#tomcatcleaning) comme cela se fait sur le SIM (où je n’avais jamais eu un pb comme celui là). Visiblement le pb doit être ailleurs.
Merci pour ces précisions mais on est toujours dans le noir.
avez vous accès au logs de tomcat / catalina ? il y a des exceptions bas niveau qui ne remontent pas toujours au niveau de Simplicité, genre problème de JDK, ou disk full…
Comme indiqué dans un ancien post, il faut aller fouiller sur le serveur pour voir si les sources que vous voyez via l’éditeur (correspondant au fichier dans le DBDOC = donc ce n’est pas un pb de perte de code source) sont bien transformés lors du “SAVE ALL” ou clear-cache : sérialisés en .java, compilés en .class et zippés en .jar dans les répertoires de la wepapp tomcat WEB-INF/src /bin et /build.
Sinon il faudra nous envoyer votre image tomcat+db pour qu’on puisse passer tout ça au debugger car par ce forum on y arrivera pas.
Bonjour,
nos conteneur tourne dans AWS donc il faudrait pas mal de manipulations de notre coté pour pouvoir aller trifouiller de le conteneur.
La mise à jour de la version de simplicité n’a rien donné en tout cas. On doit transférer nos développements sur cette plateforme dans les prochains jours, peut être que ça règlera le problème.
Je ne sais pas si c’est possible/simple avec le produit AWS que vous utilisez mais peut être est il envisageable de cloner l’instance qui a un pb sur un (sous)réseau qui nous soit accessible et de la démarrer avec -e JPDA=true ? Ca nous permettrait de nous mettre en remote debug dessus (par défaut le JPDA utilise le port 8000 qu’il faut donc autoriser)
Bonjour,
Votre cas est suffisamment bloquant pour qu’on investigue rapidement votre problème que nous ne reproduisons pas sans plus d’éléments.
On verra ainsi si cela est reproductible dans un autre environnement, si ça vient d’un problème d’infra, ou d’un problème de paramétrage / compilation à résoudre…
Pour moi ce n’est pas bloquant dans la mesure on ça n’a pas l’air d’impacter les fonctionnalités que nous avons développé et par conséquent, malheureusement, ça ne place pas cette investigation dans nos priorités.
D’autre part le fait que ce problème se soit produit sur notre plateforme de formation me laisse penser qu’il s’agit vraiment d’un problème isolé suite a une manipulation dont on pourra difficilement remonter la trace.
D’autre part, je vous fournirais les sources dans la mesure du possible et quand j’en aurai obtenu l’autorisation de ma hiérarchie.
Quid de la possibilité de nous donner accès à cette instance (ou à un clone de cette instance) en remote debug ?
En ce qui concerne la fourniture ou l’exposition de notre code, il s’agit aussi d’un point juridique. J’attends la confirmation que je peux vous le transmettre. Je devrais avoir un retour cette semaine.
Ok je comprends, si ce n’est pas bloquant tant mieux, si vos modules fonctionnent correctement ailleurs, c’est qu’il y a effectivement un problème sur cette instance, mais qui pourrait arriver à d’autre si on ne comprends pas la cause.
On peut signer un NDA si vous le souhaitez, l’objectif étant de vous apporter du support et pas de nouvelles contraintes.
Merci de votre compréhension.
La démarche de NDA est en cours chez nous, vous devriez avoir des nouvelles d’ici peu.
Bonjour,
Je met ce message pour ajouter quelques élément a analyser :
pour cette version :
Simplicité version5.0.0-beta
Built on2020-12-07 22:52
Git infoprerelease/e5ef18f8323431530722689aef4dd2c02687f1e7
Database level5;P00b;a0f7c392eeb5e1ab2dd2a64ba93e96da
Hier sur notre instance de dev partagé je ne voyais pas les modification je faisais dans le BO NamContratAvenant, j’ai finis par faire un ‘Save all’ dans l’éditeur qui a résolut le problème.
Ensuite quand j’ai enregistré de nouvelles modifications en cliquant sur enregistrer puis en vidant le cache local, j’ai eu l’erreur de la MethodNotFound sur la méthode java qui sert d’action dans l’objet NamJeune et cette méthode devait me rediriger vers une formulaire de création de l’objet NamContratAvenant.
Suite a cela, les clearCache global / local n’ont rien fait, seul un reboot du serveur me permettait de faire appel à l’action mais si je refais un enregister sur NamContratAvenant l’erreur revient systématiquement.
Quelques précision :
NamJeune fonctionnait avant et elle n’as pas été modifiée.Bonjour,
Oui vous devez toujours être dans un cas où vous rechargez un class-loader avec votre nouvelle classe modifiée et qui pointe sur une méthode (ou objet) statique déjà chargée dans un autre class-loader utilisé par d’autres.
Les autres utilisateurs ont déjà instancié leurs objets, donc pour eux ça fonctionne avec l’ancienne définition. Il n’y aucun contournement possible sauf à redémarrer tomcat si vous utilisez des objets/méthodes statiques = chargés une seule fois par la JVM (par construction du langage java, ce n’est pas un défaut de Simplicité) = inadapté à un développement agile car pas de GC possibles pour eux.
Si vous n’avez plus aucun “static” dans le code alors c’est un autre problème inconnu à date.
Cette analyse est faite dans le noir le plus complet puisque nous n’avons pas accès à vos logs complètes, ni à votre code pour reproduire le problème.
Mais, comment se fait-il que nous autres utilisateurs ne parvenons pas a reproduire ce comportement en faisant les mêmes manipulations ? A un moment donné on doit bien se retrouver avec la nouvelle définition des objets ?
Nous n’avons plus aucune méthode statique et on a enlevé la majorité des variables statiques. En tout état de cause, il ne me semble pas qu’on ait été averti, ni nos prédécesseurs, de limitations liée a l’usage de déclaration/conventions basique java qui nuiraient au bon fonctionnement de l’application, contexte agile ou non.