Erreur persistante lors de l'insert d'une donnée

Erreur persistante lors de l'insert d'une donnée
0
Tags: #<Tag:0x00007f76910731b8>

Bonjour,

Je me retrouve face à un problème déjà éprouvé chez nous (Renault) mais qui n’a jamais trouvé de véritable solution, à savoir une erreur 400 à la suite d’un appel Rest sur API mappée (mapping spécifique Renault) mais qui possède tout de même un body (les champs de la ressource insérée) et qui effectue bien l’insert en base (ressource disponible après l’appel dans le business object).
J’ai pu expérimenter ce comportement aujourd’hui et trouver l’enchaînement d’actions menant à lui.
Etape 1 : insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans un objet. Disons, pour faire simple que cet objet n’a qu’une seule clé fonctionnelle. -> Http : 200 | insert en base OK (c’est normal)
Etape 2 : insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans le même objet avec la même valeur de clé fonctionnelle. -> Http : 400 | insert NOK la clé existe déjà en base (c’est normal)
Etape 3 ATTENDUE: insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans le même objet avec une valeur de clé fonctionnelle différente. -> Http : 200 | insert OK la clé n’existe pas en base, elle est créée (ce serait anormal).
Etape 3 OBTENUE: insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans le même objet avec une valeur de clé fonctionnelle différente. -> Http : 400 | insert OK la clé n’existe pas en base mais on garde le code 400 (c’est anormal).
Je précise que pour revenir à un comportement dit normal, pas d’autre solution que le clearCache.

Avez-vous connaissance de ce problème?

Merci

PS : le health de mon instance :

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-01-21 00:44 (revision 120e5c70932b8d0317b8b6c80a743db7662de7f4)
Encoding=UTF-8
EndpointIP=172.17.0.5
EndpointURL=http://f9abf5c13c8a:8080
TimeZone=Europe/Paris
SystemDate=2020-02-18 16:11:09

[Application]
ApplicationVersion=0.8 dev
ContextPath=
ContextURL=https://int.rff.dev.aws.renault.com
ActiveSessions=3
TotalUsers=11
EnabledUsers=7
LastLoginDate=2020-01-21 13:35:58

[Server]
ServerInfo=Apache Tomcat/9.0.30
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.158-101.185.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=9149
DiskUsable=8621
DiskTotal=10015

[JavaVM]
Version=13.0.1
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=13.0.1+9
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.11 2019 05 30
HeapFree=178757
HeapSize=506948
HeapMaxSize=1773888
TotalFreeSize=1445697

[Cache]
GrantCache=20
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=285
ObjectCacheMax=10000
ObjectCacheRatio=2
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.9
DBDate=2020-02-18 16:11:09
DBDateOffset=0
DBPatchLevel=P24;120e5c70932b8d0317b8b6c80a743db7662de7f4
UsingBLOBs=true

[Healthcheck]
Date=2020-02-18 16:11:09
ElapsedTime=73

Pourquoi ce serait anormal ? si vous essayez de créer un record avec un clé fonctionnelle qui n’existe pas, il n’y a pas d’erreur, le record est créé c’est normal…

Bon sinon ce que je comprends de votre description c’est que quand vous vous servez des formulaires de la UI Simplicité ça fait ce qu’il faut. Mais que quand vous vous servez d’un appel POST (création) sur l’API mappée de votre objet vous obtenez un code HTTP 400 (alors que le record a quand même bien été créé) ? C’est ça ?

Pourquoi ce serait anormal ? si vous essayez de créer un record avec un clé fonctionnelle qui n’existe pas, il n’y a pas d’erreur, le record est créé c’est normal…

Effectivement ce cas est “normal”, erreur de copié collé

En revanche le fait pour l’erreur 400, le comportement est un peu délicat à décrire puisque je n’obtiens rien des logs.
-> Via les API mappées, à partir du moment où j’ai obtenu sur un appel un retour 400 pour cause de clé fonctionnelle déjà existante, tous les appels suivants tombent en 400 même si le comportement du système est celui d’un code 200 (tous les champs sont valides, insert en base correct…)
-> Via les formulaires Simplicité, il ne semble pas y avoir de problème (même si, encore une fois, je ne suis pas en mesure de dire si une erreur s’est produite puisqu’il n’y a pas de logs)

Ce problème n’est pas simple à décrire…

Bon je vais essayer de reproduire ce cas, je pense avoir compris le mode opératoire (le pb ne se produit que si on a obtenu un 400 lors d’un appel précédent).

Je vous tiens au courant

C’est bien ça.
Merci.

Ok je reproduis bien le pb décrit avec le mode opératoire indiqué.

C’est corrigé, il y avait effectivement un pb de reset du dernier code erreur.
Ca a été poussé sur toutes les branches actives et leurs images Docker respectives.

Merci beaucoup David pour ta réactivité.
Toutes les instances de référentiels n’ayant pas commencé l’upgrade en P24, est-il envisageable de backporter le correctif en P23 ? (j’ai bien noté le nouveau tag simplicite/platform:4.0.P23)

à ce sujet, nous avons un gros doute sur le processus d’upgrade en configuration load-balanced: en effet, nos instances de production sur AWS sont par défaut configurées en load-balancing sur 3 tâches et les build incluent le paramètre auto-upgrade=true. Dans cette configuration, que se passera-t-il lors du démarrage des 3 instances en parallèle ? L’auto-upgrade va-t-il être exécuté sur chaque instance (avec une seule et même base de données en face) ?

Non, on ne peut plus toucher à la P23, nos processus de dev et de packaging ne sont pas prévu pour ça.

L’image Docker P23 n’est conservée que pour des raisons historiques (typiquement pour pouvoir tester les upgrades). Tu auras noté qu’elle n’a plus été upgradée depuis la release de la P24.

Il est de toute façon temps de passer en P24.

Par contre la question sur l’autoupgrade en contexte multi-noeud est effectivement pertinente, ce qu’on fait d’habitude dans ce cas c’est de ne démarrer avec un noeud unique pour l’upgrade puis redémarrer avec N noeuds. Il manque donc un mode “lock” où on pourrait effectivement démarrer directement les N noeuds et le 1er qui démarrerait l’autoupgrade prendrait la main (à la manière de ce qui se passe pour la crontab) les autres noeuds attendant que ça se termine pour finir de démarrer.

Bonjour,

Suite à un upgrade vers la P24 sur une instance load-balanced sur 3 noeuds, ma bdd a été corrompue…
J’ai réduit à 1 noeud le load-balanceur.
J’ai demandé une nouvelle bdd vierge sur laquelle j’ai redéployé mais l’interface me semble étrange :

Je ne vois plus l’entrée “User” par exemple… savez-vous si cela est normal?
Puis-je récupérer ces entrées de menu ou dois-je retenter une installation from scratch?

Le health :

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-02-19 18:56 (revision 154407ecda5b5207d9d265e80b8256320fcc0ffd)
Encoding=UTF-8
EndpointIP=172.17.0.12
EndpointURL=http://49f20f05ca27:8080
TimeZone=Europe/Paris
SystemDate=2020-02-20 09:50:31

[Application]
ApplicationVersion=4.0
ContextPath=
ContextURL=https://ope.rff.ope.aws.renault.com
ActiveSessions=1
TotalUsers=3
EnabledUsers=2
LastLoginDate=

[Server]
ServerInfo=Apache Tomcat/9.0.31
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.158-101.185.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=9148
DiskUsable=8620
DiskTotal=10015

[JavaVM]
Version=13.0.2
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=13.0.2+8
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.11 2019 05 30
HeapFree=290518
HeapSize=506944
HeapMaxSize=1773888
TotalFreeSize=1557462

[Cache]
GrantCache=7
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=270
ObjectCacheMax=10000
ObjectCacheRatio=2
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.10
DBDate=2020-02-20 09:50:31
DBDateOffset=0
DBPatchLevel=P24;154407ecda5b5207d9d265e80b8256320fcc0ffd
UsingBLOBs=true

[Healthcheck]
Date=2020-02-20 09:50:31
ElapsedTime=8

Il faut changer de scope pour se mettre en “Simplicite administrator”
Out of the box on est sur le scope “Application design” qui est plus restreint

Ah d’accord! Merci !

Par contre la “corruption” de la base je ne pense pas, au pire les instances ont fait des choses en concurrence et sont dans un état foireux.

Comme je l’ait dit, il aurait fallu démarrer une fois mono noeud, arrêter et redémarrer multi noeuds.

Par corrompue, je vux dire que certains objets avaient disparu de la bdd, notamment l’objet “import utilisateur”

Y compris après un arret-relance ?

Mon point c’est que si plusieurs noeuds travaillent en autoupgrade en // il y a des clearcache concurrents qui se vont se déclencher avec, forcément, des résultats imprévisibles sur le cache.

Je pense qu’en redémarrant ces “corruptions” devraient disparaitre car ce sont sans doute que des “corruptions” du cache monté en mémoire, pas de la base.

Bonjour David,
ok pour la P23 (on priorise les upgrades de notré côté selon les cas).
la logique du lock nous semble plus sûre même si nous pouvons nous assurer de redéployer sur un seul noeud tout nouveau build de nouvelle release
Bruno

Oui je vous tiens au courant pour la mise en place du lock sur l’autoupgrade.

Le pb avec les locks c’est la stratégie d’unlock en cas de pb…