Clear Cache sur instances multiples

Simplicité 5.1.44

Bonjour, ce ticket fait suite à celui ci :

On se rendait compte que les clearcache n’était pas forcément pris en compte et la cause est simple : nous avons plusieurs instances Simplicité sur une même base de données. Quand on fait le clearcache serveur sur l’instance A suite à la modification d’un paramètre, comment propager le clearcache sur les instance B, C … ?

Je répond sous contrôle de @Francois car je ne suis pas un expert de ce sujet.

En mode cluster, les URLs des noeuds Simplicité se référencent dans la table m_pf_node ui correspond à l’objet PlatformNode

Certains événements, notamment les clears cache globaux, se propagent par appel des noeuds référencés dans cette table par appel des services I/O correspondants.

  • Quel type de clear cache invoquez vous ? Je pense - là aussi sous contrôle de @Francois - que les clear cache partiels ne sont pas gérés par ce mécanisme
  • Avez vous globalement inhibé le endpoint IO (via USE_IO) ?
  • Avez vous positionné un password I/O (via la variable d’environnement Docker IO_PASSWORD ou via un param système EAI *) ?
  • Les URLs référencées dans m_pf_nodes sont elles appelables entre elles ?

Mais, sinon, comme @Francois le suggérait dans sa réponse au post cité si vous utilisez Grant.getSystemParam/setSystemParam vous accédez alors directement à la valeur paramètre en base et vous n’avez pas alors à vous soucier de flusher le cache des paramètres système. C’est infiniment plus simple et pas forcément beaucoup moins performant (sauf si on parle d’un pattern utilisé massivement dans votre code)

Bonjour,

Nos paramètres métier sont un ObjectDB qui hérite de SystemParam.
image
image

Comment peut-on appeler setSystemParam dans cette configuration ?

Pour ce qui est du clearcache on utilisait le clearcache global qui déconnecte toutes les session.

USE_IO est à Yes et nous n’avons pas positionné de mot de passe I/O mais il va faloir qu’on le fasse si on veut utiliser l’IO pour effectuer les imports de modules etc.

set/getSystemParam fait un simple update/select sur la table m_system. Je ne sais pas usage est fait de ces param systèmes mais clairement cette approche d’accès direct en base est sans doute largement préférable à une opération “lourde” et impactante pour les utilisateurs comme un clear cache global, à fortiori dans un contexte multi noeuds.

Sinon USE_IO = yes signifie que le endpoint I/O est ouvert, il est donc possible de s’y connecter depuis n’importe quelle IP soit avec un login/password interne standard, soit avec un login/password spécifique au endpoint I/O défini dans un param système EAI * (méthode considérée aujourd’hui comme deprecated) soit en utilisant le password unique défini par la variable d’environnement IO_PASSWORD ou la property JVM io.password (valable pour tout login)

Iil est possible de définir des “whitelists” d’IP ou d’IP ranges sur les endpoint sensibles (comme I/O ou Git). cf. Simplicité® documentation/90-operation/docker ou, mieux, de gérer ce filtrage en amont au niveau de votre reverse proxy (typiquement dans un contexte multi noeurd Docker ça n’empêchera pas les noeuds de communiquer les uns avec les autres via I/O mais ça restreindra l’accès à ce endpoint depuis l’extérieur)

Plus généralement, en PROD, il convient de sécuriser les endpoints sensibles non utilisés ou utilisés de manière limitée (cf. Simplicité® documentation/security)

Oui il faut vérifier dans le menu Operation / Nodes si l’URL alimentée au démarrage d’un noeud est bien accessible entre chaque noeud. Certaines actions (clear-cache global + désactivaton de User…) déclenchent un appel vers tous les noeuds.

Si ce mécanisme ne fonctionne pas (pb d’URL, IO fermé…), une cron sur chaque noeud vérifie périodiquement (toutes les 5 minutes de mémoire) via timestamp s’il faut faire quelque chose (clear cache mémoire, logout session…).

Mais bon si le besoin est juste un problème fraicheur de données, il faut mieux passer par du SQL (ou des verbes qui font du SQL) plutôt qu’un mécanisme de lecture dans un cache dupliqué et à synchroniser.

De ce que je vois nos paramètres sont bien stockées dans la table_m_system.

Si j’ai bien compris : getParameter() va chercher la paramètre en cache alors que getSystemParameter va récupérer la valeur en base directement ?

Oui set/getParameter = en mémoire dans le cache et set/getSystemParam = directement en base

Mais vous pouvez aussi simplement utiliser votre objet métier qui hérite de SystemParam pour faire les appel en base

Un pattern qui vous oblige à faire un clear cache pour répondre à un besoin métier n’est clairement pas une bonne approche, un clear cache est une opération d’exploitation ou de maintenance ponctuelle.

Tout à fait, c’est la raison pour laquelle nous cherchons à nous en passer :wink: