Ce matin nous avons eu un comportement étrange :
Suite à 2 clear cache serveur très rapprochés, des ressources on disparu (fichier css de notre thème, scripts et css d’objets métiers) et depuis, l’export de module provoque une erreur. Nous avons eu ce problème vendredi dernier déjà mais on n’en connaissait pas la cause et on a reussi à le régler en remettant toutes les ressources qui avaient disparues.
C’est la deuxième fois en une semaine que nous rencontrons ce problème. Cela nous prend du temps à detecter les ressources manquantes et à les replacer. Ce comportement peut provoquer d’importantes regressions. Je transmet toutes les informations que nous avons pu rassembler jusque là:
Cause : clear cache serveur
Conséquences :
Ressources qui disparaissent ou dont le contenu est vidé. Les ressources semblent êtres aléatoires mais il semblerait que cela concerne que les ressources que l’on a récemment consulté/modifié depuis l’IDE integré.
Log d’erreur lors de l’export de module, rendant l’export impossible
1601536987820,“01-Oct-2020 07:23:06.927 INFO [http-nio-8443-exec-4] org.apache.catalina.core.StandardWrapperValve.invoke 2020-10-01 07:23:06,845|SIMPLICITE|http://ip
.internal:8080||ERROR|designer|com.simplicite.util.engine.Interface|exportModule||Evénement: name”
1601536987820,java.io.FileNotFoundException: /usr/local/tomcat/webapps/ROOT/WEB-INF/tmp/zip-1601536986526-dkwlSnDenzzpu4jaaEvg (Is a directory)
On nous a déjà signalé ce type de pb de ressource qui disparaissent de manière “aléatoire”. On a pas réussi à déterminer le mode opératoire pour reproduire le pb. @Francois cela va peut être nous aider à mieux cerner le contexte…
En attendant qu’on cerne et qu’on corrige le pb n’hésitez pas à commiter souvent vos modules pour toujours avoir un historique sous la main au cas où. Et lorsque vous commitez vérifiez (avant ou après le commit) le delta qui s’affiche pour voir ce qui a été ajouté/supprimé.
Oui j’ai déjà constaté ce problème uniquement sur les ressources qui se compilent (Style ou Script = minification de CSS ou de JS).
Sans jamais comprendre l’origine et reproduire le cas, je suspecte un problème dans m_document entre le fichier source et le fichier compilé, le code a été renforcé mais le mal avait dû être fait avant.
Regardez dans Document, les path de vos fichiers sources et compilés.
pour voir s’il existe des incohérences entre le path et le nom du field : res_file res_file_compiled
Le dernier patch de la V5 remet les path au “bon endroit” :
-- fix wrong resource path
update m_document
set dbd_path = REPLACE(dbd_path, '/res_file/', '/res_file_compiled/')
where dbd_path like 'Resource/res_file/%'
and dbd_field_id in (select row_id from m_field where fld_name='res_file_compiled');
commit;
En clair : tous les fichiers compilés n’avaient rien à faire dans le répertoire du fichier source.
Et je suspecte qu’au passage du cleaner ou dans certains cas de compilation, il supprimait le fichier source.
Il faudra peut être l’inclure à la V4 si cette version a le même soucis.
Bonjour,
nous avons aussi rencontré ce problème plusieurs fois et toujours suite à des clear caches très rapprochés.
Nous perdions du CSS et JS. Je regardais systématiquement le res-file de l’objet qui avait disparu de m_document sans regarder le res_file_compiled, je regarderais la prochaine fois en espérant ne plus avoir ce cas…
@François Est-ce que le patch a été inclus dans la V4 finalement ?
Il a été inclu à la 4.0.P25 qui correspond à la branche V4_0_MAINTENANCE
Pour des raisons de bascule progressive en maintenance il existe temporairement encore 2 branches (pre)release (V4_0_MAINTENANCE_PRERELEASE et V4_0_MAINTENANCE_RELEASE) sur laquelle le patch n’est pas présent. Ces 2 branches disparaitront lors de la release officielle de le V5 => tu peux donc basculer toutes tes instances sur la branche V4_0_MAINTENANCE dès maintenant (et tu auras le patch en question)
Suite a notre migration en v5-beta il y a encore des ressources qui disparaissent. Là suite à un clear cache serveur, on a eu un gros bug d’affichage avec l’erreur suivante
Après un clear cache global, l’affichage est revenu à la normale mais plusieurs de nos ressources ont sauté dont le CSS de notre theme ( même soucis qu’en V4).
Effectivement si les styles ou les JS du front ne sont pas chargés, ça affichera n’importe quoi, voir rien.
J’ai déjà eu le spinner de chargement qui ne termine jamais, mais ce n’est pas la cause du souci, c’est toujours le cache qui n’a pas été actualisé ou a été corrompu (perte de livrable).
Par contre cette histoire de ressources qui disparaissent devient très problématique car nous le voyons de temps en temps sans jamais comprendre/reproduire la cause.
Je reste persuadé que c’est un problème de robustesse au niveau de la compilation des ressources (less et js) car personne n’a détecté d’autre sorte de perte de document (document métier ou images…).
On va revérifier cette partie en priorité, comme c’est assez aléatoire, il y a peut-être un problème de concurrence d’accès asynchrone (du genre les ressources compilent pendant qu’un autre thread vide le cache ou supprime les dead-links…).
Des synchronize ont été ajoutés pour éviter les collisions éventuelles entre différents processus :
Le clear-cache global
La compilation/minification de Resource de type less/js
La compilation de Theme avec les thèmes par défaut (light, dark…)
La synchronisation des documents (pour supprimer les références mortes)
Ils s’attendront les uns les autres dans le cas de Threads en parallèle. Si le problème vient d’un unique thread, ça ne corrigera pas le problème, mais au moins ça écartera ce risque dans nos recherches de cause.
La ressource SCRIPT est liée à l’objet Disposition de row_id=15.
select * from m_disposition where row_id=15
Il faut juste recréer le fichier SCRIPT de cette disposition, même s’il était vide mettez un commentaire pour qu’il ne le soit plus, sinon il faut le recopier d’un autre environnement ou sauvegarde (export de module, dump…).
Pouvez vous préciser votre version actuelle ?
car il va falloir investiguer ce problème complexe à reproduire / aléatoire.
Pouvez-nous préciser quelle ressource précisément ?
le code d’objet, script partagé, ressource JS ou HTML… ?
message d’erreur dans les logs
Est ce une perte du fichier source (document perdu ou editeur vide demandant de recharger le code source depuis une sauvegarde) ou juste un problème en mémoire qui disparait via clear-cache ?
Ca permettra d’orienter les recherches de causes : compilation, synchro des docs, concurrence d’accès.
On vient de corriger la perte du code d’objet à la création initiale en V5 : si on utilisait 2 fois le bouton “Edit” dans une même session à la 1ère création du fichier source.
Nous allons mettre en quarantaine tous les endroits qui suppriment des documents (en dead-link ou autre), il doit y avoir une cause subtile d’erreur qui nous échappe.
Nous somme en v5-beta avec mise à jour quotidienne donc on est sur la dernière version.
Nous avons surtout constaté ça sur des ressource de type JS/CSS et le message d’erreur.
J’ai pas le message d’erreur sous les yeux mais c’est genre " Ressource not found for rowId = 234"
Ok merci donc c’est bien toujours le même problème.
Suite à investigation :
on a ajouté une mise en quarantaine de certains traitements qui suppriment les liens morts de document, il doit y avoir un cas imprévu autour des ressources compilées ou minifiées (JS/LESS/CSS) pendant qu’une re-synchro de documents s’exécute (clear-cache ou autre).
contrairement à la V4 on dirait que la V5 autorise des accès UI alors qu’un clear-cache est en cours, ce qui provoque des anomalies aléatoires (quelqu’un accède à un objet alors que le cache n’est pas encore prêt = log mineure mais troublante du style “il manque des champs ou des ressources ou des traductions…”). Le verrou actuel semble insuffisant.
On va renforcer encore cet aspect dans les prochains jours, car c’est à mon avis dans ces concurrences d’accès qu’il y a un cas imprévu d’écrasement.
Le problème sur les ressources minifiées/compilées (JS/LESS) et qui disparaissent en mémoire au démarrage de la plateforme a été corrigé. Simplicité retrouve désormais le fichier qui a été recompilé (qui a changé de docId par rapport au cache sérialisé).
D’autres évolutions sont en cours pour sécuriser le verrouillage de tous les accès via servlet (UI, API REST, GIT, Webhook…) durant un clear-cache en V5.1. Ce sera backporté en 5.0 si les tests sont concluants. Un clear-cache mettra “en attente” quelques secondes tous les accès, un peu comme la séquence de boot de tomcat.
Il n’y pas d’autre alternative pour ne pas avoir des instanciations en erreur(même si c’est rare) alors qu’un nouveau module se charge.
