Liveness probe failure: Redémarrage plateforme

Request description

Bonjour,
Nous voudrions vous soumettre une issue que nous rencontrons sur la plateforme Simplicite depuis le 09/02/2023. C’est arrivé 3 jours d’affilée: le 09/02, le 10/02 et le 11/02.

Je vais prendre la matinée du 11/02 pour illustrer le problème mais c’est plus ou moins ce qui s’est passé les 2 autres jours.

Chronologie

L’application est en fonctionnement normal.

A 07:41: brutalement les temps de réponse passent de quelques secondes à 10 minutes presqu’intégralement en WAITING.

Quelques exemples :

/ui/logs?filter=%5E.*%24 - 10 min 0.054 s

Response code​ 200
Waiting 9 min 59.9 s
Suspension 126 ms
CPU 15.1 ms

/ui/json/app
action=getsysparam&_=5_1_54_20230209083418&_ajaxkey=CvQnXrNVxDwuODf8F0QQ

10 min 0.056 s
Response code​ 200

/ui/json/obj?action=metadata&object=MlaAftersaleItem&inst=the_ajax_MlaAftersaleItem&context=2&_=5_1_54_20230209083418&_ajaxkey=CvQnXrNVxDwuODf8F0QQ

Response code​ 200

/health

Waiting 9 min 59.7 s
Suspension 273 ms
CPU 7.83 ms

Au milieu des opérations, on a quelques étrangement quelques opérations rapides avec pourtant des appels, en base

/ui

Response code​ 200
CPU 112 ms Other 46.4 ms Waiting 22.7 ms
Time spent in database calls​ 55.5ms
Calls to databases​ 78

Puis dans un second temps, on passe en “No response”

/ui/json/app?action=getsysparam&_=5_1_54_20230209083418&_ajaxkey=WozHER1BWrCzPZNgY051

Suspension 161 ms

/health

Suspension 161 ms

/ui

Suspension 161 ms

Les threads se mettent instantanément en SLEEP

Au bout de 30 minutes le POD est killé et redémarré

Question: Avez vous une idée des indicateurs qui sont interrogés par la plateforme pour passer les threads en SLEEP?

----description of the request----

Steps to reproduce

On a rencontré le soucis 3 jours d’affilée. Plus rien depuis dimanche.

Technical information

Instance /health
[Platform]
Status=OK
Version=5.1.54
BuiltOn=2022-10-31 15:49
TimeZone=Europe/Paris
SystemDate=2023-02-14 15:10:31
Simplicité logs
Beaucoup de recherche en log, back et base de données et dans Dynatrace. Malheureusement, rien de particulièrement marquant sur la période.
Browser logs
---paste content of the **relevant** browser-side logs---
Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

Merci par avance de votre attention.

cdt,
Thierry BALLA
Technical Leader Renault

Sans présumer d’une analyse plus poussée:

  1. Comme déjà expliqué en détail dans un post précédent l’usage de la page legacy de consultation des logs server (/ui/logs) est à proscrire absolument en PROD. C’est un outil historique, absolument pas optimisé, qui est purement destiné aux instances de DEV, et même là il ne faut l’utiliser que très ponctuellement car ses temps de réponse peuvent être très longs en fct de la taille des fichiers logs. Comme c’est le 1er de la liste, ça m’interpelle…

  2. Je ne sais pas si c’est le cas mais la supervision technique des containers doit impérativement se faire sur le endpoint /ping, en aucun cas sur le endpoint informatif /health qui fait des traitements beaucoup plus lourds qui peuvent potentiellement mettre plus de temps à répondre, et peut être bloquer ou être bloqué par d’autres (typiquement quand il va mesurer des métriques système bas niveau : mémoire, occupation disque, etc.). Le endpoint /ping, lui, fait les traitements minimaux nécessaires et suffisants pour savoir si Tomcat fonctionne et arrive à faire une requête en base. Là aussi comme je vois des appels à /health ça m’interpelle…

PS: la révision à jour de la version mineure 5.1 est la 5.1.56 (vs votre 5.1.54). Je précise que cette version mineure 5.1 n’est officiellement plus maintenue mais que nous continuons néanmoins à y backporter certains points critiques. Cela dit, il faudrait de toute façon envisager un jour de passer en 5.2 (d’autant qu’une 5.3 arrive).

Bonjour David,
Concernant les logs, la consigne a été transmise aux équipes de DEV de consulter les logs sur GCP, mais les habitudes ont la vie dure

Concernant le /health, je transmets la consigne aux DEVOPS puisqu’aujourd’hui on s’appuie sur le /health pour le “Liveness Probe”

Le sujet 5.2 est en cours chez nous et la migration ne devrait plus tarder

cdt

OK

  1. il est possible de retirer l’accès à la page des logs en désactivant les habilitations suivantes :

  2. Un check du HTTP 200 (sans autre analyse de ce que ça répond) sur /ping assure tout autant que le /health que “tout va bien” mais coute infiniment moins cher. Les indicateurs techniques que remonte le health sont récupérables par ailleurs (typiquement les indicateurs liés à la mémoire sont des infos fournis par la JVM, les infos sur les caches Simplicité sont disponibles via des services JMX, etc.)

Pour ce qui est de la 5.2 tant mieux car elle en est à sa révision 31, sa date de release initiale datant d’il y a bientôt 1 an.

1 Like

Si les logs ne montrent rien d’anormal, il faut regarder le monitoring interne de la plateforme.

Il faut activer le monitoring de Simplicité à une fréquence de 5 ou 10 minutes, car ça persiste des snapshop pour les afficher sur une période glissante (de base sur 3j). C’est là que vous verrez :

  • Les threads “de l’intérieur” = la stack des threads blockés (type dead lock) ou waiting (sleep).
  • La JVM de l’intérieur : les métriques session / heap / GC / CPU / CL…
  • Les accès bases : disk, requêtes/sec…
  • Les perfs globale et temps de réponse des services par objet côté serveur
  • Les logins de ceux qui pourraient utiliser un user-agent exotique
    etc

1 Like

Bonjour,
nous avons une piste pour une partie du problème. Nous avons constaté des latences importantes sur des actions UI un peu avant 8H00 ce matin.
Les actions duraient plus d’une heure quasi intégralement en WAITING

En poussant plus loin l’investigation, nous avons constaté un souci sur une séquence:

Nous avons 2 appels select nextval qui prennent chacun 34.8 minutes, ce qui fait en tout 1,16H.

On a trouvé les exceptions suivantes :

select nextval(‘mla_file_event_row_id_seq’)

Exception:

org.postgresql.util.PSQLException

Message:

ERROR: could not open relation with OID 11180755

Stacktrace:

org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676)

org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2366)

org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356)

org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:496)

org.postgresql.jdbc.PgStatement.execute(PgStatement.java:413)

org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)

org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:134)

org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:121)

org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:121)

com.simplicite.util.engine.DBAccess.query(DBAccess.java:622)

com.simplicite.util.engine.DBAccess.simpleQuery(DBAccess.java:820)

com.simplicite.util.engine.GrantDirect.simpleQuery(GrantDirect.java:123)

com.simplicite.util.Grant.simpleQuery(Grant.java:1104)

com.simplicite.util.tools.SQLTool.getSequenceNextval(SQLTool.java:555)

com.simplicite.util.engine.DBAccess.getNextIdFromDB(DBAccess.java:1371)

com.simplicite.util.engine.DBAccess.getNextIdFromDB(DBAccess.java:1361)

com.simplicite.util.engine.DBAccess.getNextId(DBAccess.java:1342)

com.simplicite.util.engine.ObjectManager.create(ObjectManager.java:1862)

com.simplicite.util.engine.ObjectManager.save(ObjectManager.java:3351)

com.simplicite.util.engine.ObjectDirect.save(ObjectDirect.java:478)

com.simplicite.util.ObjectDB.save(ObjectDB.java:1317)

com.simplicite.util.ObjectDB.save(ObjectDB.java:1304)

com.simplicite.util.tools.BusinessObjectTool.create(BusinessObjectTool.java:759)

com.simplicite.util.tools.BusinessObjectTool.create(BusinessObjectTool.java:739)

com.simplicite.objects.mla_coremodel.MlaFileEvent.saveFileEventDataAsItem(MlaFileEvent.java:29)

select currval(‘mla_file_event_row_id_seq’)

Exception:

org.postgresql.util.PSQLException

Message:

ERROR: relation “mla_file_event_row_id_seq” does not exist Position: 16

Stacktrace:

org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676)

org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2366)

org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356)

org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:496)

org.postgresql.jdbc.PgStatement.execute(PgStatement.java:413)

org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)

org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:134)

org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:121)

org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:121)

com.simplicite.util.engine.DBAccess.query(DBAccess.java:622)

com.simplicite.util.engine.DBAccess.simpleQuery(DBAccess.java:820)

com.simplicite.util.engine.GrantDirect.simpleQuery(GrantDirect.java:123)

com.simplicite.util.Grant.simpleQuery(Grant.java:1104)

com.simplicite.util.tools.SQLTool.getSequence(SQLTool.java:488)

com.simplicite.util.tools.SQLTool.getSequenceNextval(SQLTool.java:563)

com.simplicite.util.engine.DBAccess.getNextIdFromDB(DBAccess.java:1371)

com.simplicite.util.engine.DBAccess.getNextIdFromDB(DBAccess.java:1361)

com.simplicite.util.engine.DBAccess.getNextId(DBAccess.java:1342)

com.simplicite.util.engine.ObjectManager.create(ObjectManager.java:1862)

com.simplicite.util.engine.ObjectManager.save(ObjectManager.java:3351)

com.simplicite.util.engine.ObjectDirect.save(ObjectDirect.java:478)

com.simplicite.util.ObjectDB.save(ObjectDB.java:1317)

com.simplicite.util.ObjectDB.save(ObjectDB.java:1304)

com.simplicite.util.tools.BusinessObjectTool.create(BusinessObjectTool.java:759)

com.simplicite.util.tools.BusinessObjectTool.create(BusinessObjectTool.java:739)

com.simplicite.objects.mla_coremodel.MlaFileEvent.saveFileEventDataAsItem(MlaFileEvent.java:29)

CREATE SEQUENCE mla_file_event_row_id_seq

Exception:

org.postgresql.util.PSQLException

Message:

ERROR: relation “mla_file_event_row_id_seq” already exists

Stacktrace:

org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676)

org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2366)

org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356)

org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:496)

org.postgresql.jdbc.PgStatement.execute(PgStatement.java:413)

org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)

org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:152)

org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:135)

org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:135)

com.simplicite.util.engine.DBAccess.update(DBAccess.java:1514)

com.simplicite.util.engine.GrantDirect.update(GrantDirect.java:397)

com.simplicite.util.Grant.update(Grant.java:1843)

com.simplicite.util.tools.SQLTool.getSequence(SQLTool.java:500)

com.simplicite.util.tools.SQLTool.getSequenceNextval(SQLTool.java:563)

com.simplicite.util.engine.DBAccess.getNextIdFromDB(DBAccess.java:1371)

com.simplicite.util.engine.DBAccess.getNextIdFromDB(DBAccess.java:1361)

com.simplicite.util.engine.DBAccess.getNextId(DBAccess.java:1342)

com.simplicite.util.engine.ObjectManager.create(ObjectManager.java:1862)

com.simplicite.util.engine.ObjectManager.save(ObjectManager.java:3351)

com.simplicite.util.engine.ObjectDirect.save(ObjectDirect.java:478)

com.simplicite.util.ObjectDB.save(ObjectDB.java:1317)

com.simplicite.util.ObjectDB.save(ObjectDB.java:1304)

com.simplicite.util.tools.BusinessObjectTool.create(BusinessObjectTool.java:759)

com.simplicite.util.tools.BusinessObjectTool.create(BusinessObjectTool.java:739)

com.simplicite.objects.mla_coremodel.MlaFileEvent.saveFileEventDataAsItem(MlaFileEvent.java:29)

La log est en PJ
downloaded-logs-20230215-164422.csv (335.7 KB)

Avec une séquence de:
CREATE SEQUENCE mla_file_event_row_id_seq
et même ALTER SEQUENCE mla_file_event_row_id_seq RESTART WITH 9161231

Merci par avance

Bonjour,
Je reviens sur ce souci constaté sur les séquences. En regardant mieux et en isolant une session particulière, on trouve le véritable enchainement d’appels en base de données qui est le suivant:

“2023-02-16 08:01:55.060 UTC [546185]: [1391397-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: select nextval(‘mla_standard_logistic_condition_level_row_id_seq’)”,2023-02-16T08:01:55.061720Z
“2023-02-16 08:01:55.060 UTC [546185]: [1391396-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: could not open relation with OID 11201631”,2023-02-16T08:01:55.061361Z

“2023-02-16 08:01:55.068 UTC [546185]: [1391399-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: select currval(‘mla_standard_logistic_condition_level_row_id_seq’)”,2023-02-16T08:01:55.069219Z
“2023-02-16 08:01:55.068 UTC [546185]: [1391398-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: relation ““mla_standard_logistic_condition_level_row_id_seq”” does not exist at character 16”,2023-02-16T08:01:55.068972Z

“2023-02-16 08:01:55.084 UTC [546185]: [1391402-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: CREATE SEQUENCE mla_standard_logistic_condition_level_row_id_seq”,2023-02-16T08:01:55.085692Z
"2023-02-16 08:01:55.084 UTC [546185]: [1391400-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: duplicate key value violates unique constraint ““pg_type_typname_nsp_index””",2023-02-16T08:01:55.085248Z
“2023-02-16 08:01:55.084 UTC [546185]: [1391401-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm DETAIL: Key (typname, typnamespace)=(mla_standard_logistic_condition_level_row_id_seq, 16432) already exists.”,2023-02-16T08:01:55.085531Z

"2023-02-16 08:01:55.122 UTC [546185]: [1391405-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: insert into mla_standard_logistic_condition_level (row_id,created_dt,updated_dt,created_by,updated_by,mla_slc_level,mla_SLC_start_validity_date,mla_slc_validity_end_date,mla_slc_service_rouding,mla_slc_quantity,mlastandardlogisticconditionLevel_mlastockkeepingunit_id,mla_t_source_integration) values ($1,$2,$3,$4,$5,$6,$7,null,$8,$9,$10,$11),2023-02-16T08:01:55.123271Z
“2023-02-16 08:01:55.122 UTC [546185]: [1391404-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm DETAIL: Key (row_id)=(2365196) already exists.”,2023-02-16T08:01:55.123205Z
"2023-02-16 08:01:55.122 UTC [546185]: [1391403-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: duplicate key value violates unique constraint ““mla_standard_logistic_condition_level_pkey””",2023-02-16T08:01:55.122931Z

“2023-02-16 08:01:55.130 UTC [546185]: [1391408-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: insert into mla_standard_logistic_condition_level (row_id,created_dt,updated_dt,created_by,updated_by,mla_slc_level,mla_SLC_start_validity_date,mla_slc_validity_end_date,mla_slc_service_rouding,mla_slc_quantity,mlastandardlogisticconditionLevel_mlastockkeepingunit_id,mla_t_source_integration) values ($1,$2,$3,$4,$5,$6,$7,null,$8,$9,$10,$11)”,2023-02-16T08:01:55.130850Z
"2023-02-16 08:01:55.130 UTC [546185]: [1391406-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: duplicate key value violates unique constraint ““mla_standard_logistic_condition_level_uk””",2023-02-16T08:01:55.130490Z
“2023-02-16 08:01:55.130 UTC [546185]: [1391407-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm DETAIL: Key (mla_slc_level, mla_slc_start_validity_date, mlastandardlogisticconditionlevel_mlastockkeepingunit_id)=(1, 2023-02-16, 632506) already exists.”,2023-02-16T08:01:55.130756Z

“2023-02-16 08:02:03.950 UTC [546185]: [1391411-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: insert into mla_standard_logistic_condition_level (row_id,created_dt,updated_dt,created_by,updated_by,mla_slc_level,mla_SLC_start_validity_date,mla_slc_validity_end_date,mla_slc_service_rouding,mla_slc_quantity,mlastandardlogisticconditionLevel_mlastockkeepingunit_id,mla_t_source_integration) values ($1,$2,$3,$4,$5,$6,$7,null,$8,$9,$10,$11)”,2023-02-16T08:02:03.951775Z
"2023-02-16 08:02:03.950 UTC [546185]: [1391409-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: duplicate key value violates unique constraint ““mla_standard_logistic_condition_level_uk””",2023-02-16T08:02:03.950840Z
“2023-02-16 08:02:03.950 UTC [546185]: [1391410-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm DETAIL: Key (mla_slc_level, mla_slc_start_validity_date, mlastandardlogisticconditionlevel_mlastockkeepingunit_id)=(1, 2023-02-16, 593597) already exists.”,2023-02-16T08:02:03.951641Z

Sachant que plusieurs process réalisent ces opérations en parallèle, ça explique certainement le côté “messy” à ce moment là.

Bonjour,

Rien d’anormal à priori.
Il peut y avoir des erreurs SQL à prendre comme des warnings la 1ere fois ou au démarrage de l’instance car Simplicité essaye de créer une séquence si elle n’existe pas, ou de la recaler au max(row_id) en cas d’erreur lors d’un insert (les duplicate sur le row_id). La plateforme s’auto-corrige si les séquences n’ont pas été livrées ou des insert ont été faits “à la main” sans incrémenter la séquence.

mla_standard_logistic_condition_level
il serait judicieux de vérifier les indexes en base de cette table vis à vis de la définition de l’objet.
mla_standard_logistic_condition_level_uk
Normalement Simplicité fait un contrôle d’unicité de la clé fonctionnelle avant de faire un insert.

  • Ca peut se produire en cas d’accès concurrent 2 validates au même moment suivie de 2 inserts au même moment.
  • sinon c’est que la clé unique n’est pas la bonne en base (ceux des champs clé fonctionnelle)

Par contre ce n’est pas normal de ne pas pouvoir dropper/recréer la séquence ou un index en dehors de Simplicité. Et cela relève plus du support d’un DBA si c’est la cas, il doit y avoir un pb dans les catalogues de la base, mais on a jamais eu ce type d’incident.

Ce qui nous a beaucoup coûté hier et peut-être aujourd’hui, c’est cette erreur. C’est plutôt ce qui nous inquiète. C’est comme si un process essayait de faire un nextval sur une SEQUENCE qui a entre temps été recréée.

Sur le post précédent, on a pris toute les opérations liées à la session [546185] et au final, l’INSERT n’aboutit pas.

cdt

Bonjour,
Je mets ici les copies d’écran:

et

cdt

Bonjour,
Pour repréciser, je ne trouve pas l’enchainement normal.
On a une erreur sur le nextval à cause d’un OID qui n’existe plus.
On appelle currval, la séquence n’existe pas.

On essaie de recréer la séquence, mais visiblement, elle a déjà été recréée par un autre process. Et pour finir les 3 INSERT échouent.

ça vaut peut-être le coup de regarder comment sont fait ces appels dans notre code.

cdt

Simplicité fait au mieux :

Il crée une séquence par table une seule fois si elle n’existe pas lors du premier “insert” en base.

  • on ne peut pas avoir ce problème 2 fois si on utilise des accès via les API Simplicité
  • l’erreur SQL n’est pas loguée côté Simplicité, mais il y a forcement une erreur visible coté base : Simplicité teste un currval pour savoir si la séquence existe ou pas.
  • le rebuild Sequence est effectué si la séquence est invalide (si curval < max(row_id)) = fait un drop si la sequence existait avant, puis recrée la séquence avec la bonne valeur

Comment sont faits les accès base dans le traitement de 8h ? visiblement on parle d’un traitement particulier qui ne passe pas par les couches logiques de la plateforme comme le ferait la UI.

  • Via des threads en concurrence d’accès ? séquentiellement ?
  • Via des objets Simplicité mal synchronisés entre les méthodes search/select …et les create/save ?
  • Via des requêtes SQL INSERT directes qui désynchronisent les séquences et forcent Simplicité à les recréer ?
  • un mixte de tout ça sans trop savoir ce qu’on fait ?
1 Like

Bonjour,
Je reviens vers vous concernant cette histoire de séquence. La situation décrite est, je suis d’accord, plutôt une conséquence.

Mais le fait est que la suppression de séquences par différents process en même temps peut durablement déstabiliser l’ensemble des opérations en cours.

La question est la suivante: quel enchainement d’evènement peut mener à un DROP de séquence?

Merci par avance.
Thierry

Statements

07:03:00.115 [1184015]: [684657-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: DROP SEQUENCE mla_file_event_row_id_seq",2023-02-21T06:03:00.116771Z

07:03:00.151 [1184017]: [541415-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: CREATE SEQUENCE mla_file_event_row_id_seq",2023-02-21T06:03:00.152216Z

07:03:00.151 [1184017]: [541414-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: relation ““mla_file_event_row_id_seq”” already exists",2023-02-21T06:03:00.151980Z

07:05:28.904 [1363232]: [1032319-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: DROP SEQUENCE mla_file_event_row_id_seq",2023-02-21T06:05:28.905440Z

07:05:28.925 [1363230]: [638205-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm STATEMENT: CREATE SEQUENCE mla_file_event_row_id_seq",2023-02-21T06:05:28.925920Z
07:05:28.925 [1363230]: [638204-1] db=mla_simplicite_01_db,user=mla_simplicite_01_adm ERROR: relation ““mla_file_event_row_id_seq”” already exists",2023-02-21T06:05:28.925716Z

Bonjour,

On a revu, suite à notre échange précédent, l’algo de recalage des séquences qui sont désynchronisées vis à vis du row_id de la table .Il ne fera plus de DROP/CREATE si la séquence existe déjà, mais uniquement un ALTER de la valeur courante.

Ca devrait corriger votre problème de concurrence d’accès.
Par contre pas du tout la façon d’insérer en base sans tenir compte de la séquence par votre batch, qui ne semble pas passer par les couches Simplicité pour faire des mises à jour, et qui du coup provoque des erreurs imprévisibles.

Il faudrait qu’on vous rebuild la 5.1 pour embarquer cette optimisation qui date du 16/2.
@david a-t-on prévu un build spécifique de la 5.1 prochainement ?

1 Like

La dernière révision post maintenance de la 5.1 est la 5.1.56 qui à été releasée le 09/02

Nous pouvons pousser une nouvelle révision de maintenance rapidement pour embarquer ce changement.

Mais je rappelle tout de même qu’il n’est pas sain de rester ad vitam aeternam sur une version mineure officiellement plus maintenue depuis octobre 2022, cf. Simplicité® documentation/versions

La version mineure suivante 5.2 a bientôt 1 an et en est à sa 32ème révision (et une version mineure suivante ne va pas tarder ce qui fera passer la 5.2 en maintenance court terme), je ne comprend vraiment pas pourquoi upgrader pose pb car on parle de version mineures qui n’induisent aucune incompatibilité (à part si des choses très atypiques ou des choses deprecated depuis des lustres sont utilisées)

Bonjour David,
Nous sommes preneur d’une nouvelle révision embarquant la correction. Merci de la réactivité.

Concernant la 5.2, le sujet est en cours chez nous. Nous avons rencontré des anomalies dans le module System de Simplicite, ce qui nous a bloqué.
C’est maintenant résolu en DEV et en cours de déploiement sur nos autres environnements.

cdt

Peut on avoir des précisions sur ce point ?

Nous builderons la nouvelle révision de la 5.1 dans la journée, les images Docker correspondantes seront dispo demain

Salut David,
Excuse moi, je n’ai pas été clair. C’est des soucis qui découlaient de mauvaises manipulations chez nous. C’est maintenant corrigé.

cdt,
Thierry

La révision 5.1.57 est releasée

2 Likes

Attention, on va devoir relivrer car il y a eu une erreur dans le backportage de l’évolution 5.2 en 5.1 que vous utilisez encore. On vous tient au courant.

1 Like