Erreur récurrente sur CronJob deadlockTimestamp

Support
1

Bonjour,
On a une erreur récurrente et on sait pas ça vient d’où :

2021-06-24 13:25:00,006 ERROR [com.simplicite.util.CronJob] SIMPLICITE|http://mla-api-7f54d69b58-rlss7:8080||ECORECM002|system|com.simplicite.util.CronJob|run||deadlockTimestamp
    com.simplicite.util.exceptions.ActionException: Cannot invoke "com.simplicite.util.ObjectField.getValue()" because the return value of "com.simplicite.util.Action.getConfirmField(String, String)" is null
     at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:4340)
     at com.simplicite.util.ObjectDirect.invokeAction(ObjectDirect.java:623)
     at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:2110)
     at com.simplicite.util.CronJob.run(CronJob.java:339)
    Caused by: java.lang.NullPointerException: Cannot invoke "com.simplicite.util.ObjectField.getValue()" because the return value of "com.simplicite.util.Action.getConfirmField(String, String)" is null
     at com.simplicite.objects.System.ObjectUsage.deadlock(ObjectUsage.java:25)
     at jdk.internal.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.base/java.lang.reflect.Method.invoke(Method.java:567)
     at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:4307)
     ... 3 more

Merci d’avance

[Platform]
Status=OK
Version=5.0.54
BuiltOn=2021-06-22 18:01
Git=release/dcf816a1ef23a745bcc44e6f7262d7dee41c97dc
2

Visiblement vous appelez via la cron une action configurée avec des attributs de confirmation. Dans le contexte d’un appel non interactif ces attributs ne sont pas présents il faut donc gérer le cas où l’object field est null dans le code de votre action (comme le suggère les messages de la stacktrace).

3

merci pour ta réponse David.
Cette erreur peut-elle provoquer une lenteur de l’application?

4

Je ne peux pas répondre à une telle question avec les éléments fournis… mais je ne vois pas de rapport à priori entre une simple erreur applicative et les performances globales d’une application.

Quelle est la manifestation visible des “lenteurs” dont on parle ici ?

5

Lenteur de compilation, d’ouverture de page et sur notre environnement de recette on a carrément des crash une erreu 502, peut-être c’est un problème de mémoire alloué à l’application.

6

Cette cron est système et purge les dead-lock sur les usages d’objets (timestamp lock).
Avez vous le champ obu_duration dans l’action de cette cron deadlockTimestamp ?

image
image1518×444 21.4 KB

Si non, votre instance n’est pas à jour ou cassée.

1 Like
7

Sinon de manière plus générale activez le monitoring serveur:

image
image1920×971 83.4 KB

Cette page vous indiquera l’état général de votre instance (mémoire, requêtes SQL longues, performances des appels de service, etc.)

1 Like
8

recette_capture
recette_capture1918×959 86.9 KB

9

C’est à vous de vous servir de cet outil de monitoring pour déterminer ce qui pose pb dans votre cas.

Avec juste cette copie d’écran je n’ai pas d’élément pour vous aider => ca dit juste que 100% de la mémoire a été allouée pour le heap (qui n’est utilisé qu’à 15%) mais rien de plus, en général on est pas à 100% il doit donc y avoir un traitement quelque part qui a un moment à forcé votre instance à allouer 100% de la mémoire ou dans le genre.

Videz le cache ou redémarrez votre instance, démarrez le monitoring (à une fréquence de 1min au lieu de 10min par défaut) et servez vous de votre instance pendant quelque temps puis regardez attentivement les différents onglets de cette page pour voir si vous y trouvez des choses “bizarres” (des pages qui mettent du temps à répondre, des requêtes SQL abusivement longues etc.).

1 Like
10

Merci David on va faire cela

11

Bonjour François,
oui on a bien le champ obu_duration dans l’action

12

Bonjour,

S’il est bien déclaré, c’est que la plateforme ne le connait pas “encore” quand l’action s’exécute.
Est ce qu’un clear-cache global + restart tomcat corrige le problème ?

  • On va regarder de notre côté sur la V5 si des objets avec des timestamps de type “Record lock” ont ce problème
  • On va ajouter un contrôle pour ne pas lire ce champs s’il n’est pas encore présent dans l’action
1 Like
13

Autres précisions :

  • il y a une valeur par défaut via paramètre système OBJECT_LOCK_DURATION = 300
  • donc si le timestamps d’un objet est configuré en “record lock”, un utilisateur ne peut pas ouvrir un record en mise à jour plus de 5 minutes sans le quitter ou l’enregistrer
  • cette cron deadlockTimestamp sert à libérer les records bloqués trop longtemps ou quittés anormalement (utilisateur toujours sur l’écran mais parti faire autre chose, fermeture du navigateur, F5…)
14

Bonjour François,
Non le restart total ne corrige pas le problème

15

Bonsoir,

Ce problème est mineur mais il faudrait trouver la cause :

  • Regardez si vous avez le pb sur vos autres instances, aucune V5 connues ne sort ce genre d’erreur.
  • Arrêtez la cron deadlockTimestamp (désactiver + recharger la crontab) si vous n’avez pas d’objet à verrouillage, elle est inutile
  • Enfin mettez-vous à jour, il y a une sécurité qui a été ajoutée pour ne pas exécuter la tache si le champ n’est pas dans l’action, mais ce n’est pas normal
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.