La meta cache_signature n'envisage pas que la base puisse être utilisée avec plusieurs caches différents. Cette situation peut exister si on a plusieurs VirtualHost utilisant la même base, ou bien si une base est répliquée entre plusieurs machines servant le même site (installation haute dispo).
L'utilisation de la même meta pour contrôler plusieurs caches va provoquer soit des recalculs inutiles, soit des conflits de réplication de base de donnée.
Le problème peut être évité en suffixant le nom de la meta par un identifiant dépendant du VirtualHost et de la machine. Le patch ci-joint implémente cette modification.
La meta cache_signature n'envisage pas que la base puisse être utilisée avec plusieurs caches différents. Cette situation peut exister si on a plusieurs VirtualHost utilisant la même base, ou bien si une base est répliquée entre plusieurs machines servant le même site (installation haute dispo).
L'utilisation de la même meta pour contrôler plusieurs caches va provoquer soit des recalculs inutiles, soit des conflits de réplication de base de donnée.
Le problème peut être évité en suffixant le nom de la meta par un identifiant dépendant du VirtualHost et de la machine. Le patch ci-joint implémente cette modification.
Bonjour
Merci pour le patch.
Est il possible de le proposer en tant que pull request sur
https://git.spip.net/SPIP/spip (compte de la zone) ou bien sur le
clone public http://github.com/spip/spip ?
> Est il possible de le proposer en tant que pull request sur
> https://git.spip.net/SPIP/spip (compte de la zone) ou bien sur le
> clone public http://github.com/spip/spip ?
C'est fait:
https://github.com/spip/SPIP/pull/26
Est-ce que je dois lancer des pull requests pour les branches de SPIP?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu`netbsd.org
Merci pour le PR. Pour le moment il faut mieux faire sur la
trunk/master, le report sur les branches est à avoir au cas par cas.
Je suis preneur d'un relecteur de code pour valider le PR.
bonjour
Merci pour le PR. Pour le moment il faut mieux faire sur la
trunk/master, le report sur les branches est à avoir au cas par cas.
Je suis preneur d'un relecteur de code pour valider le PR.
je vais regarder, mais je pense que la PR ne doit pas être appliquée en l'état :
les caches sont déjà distingués en fonction du host qui sert à accéder au site, via le contexte implicite du cache, qui sert à définir l'identifiant de mise en cache (donc 2 hits sur la meme page via 2 host différents tomberont sur 2 identifiants différents)
Le cas qui peut être problématique est celui de la base répliquée entre plusieurs serveurs, mais là on entre dans un autre sujet et pour qu'il y ait collision cela supposerait que le dossier tmp/cache est commun aux serveurs. Ce qui semble une mauvaise idée si chaque serveur à sa base (répliquées avec possibles désynchro ?). Dans ce cas il suffit de définir un dossier cache sur chaque machine (via un `define('_DIR_CACHE',...) qui tape dans un dossier qui n'est pas partagé).
Si le problème vient d'une utilisation de memoization (cache via memcached ou autre), alors ce n'est pas ici qu'il faut en parler car ça ne concerne pas le core
je vais regarder, mais je pense que la PR ne doit pas être appliquée en l'état :
* les caches sont déjà distingués en fonction du host qui sert à accéder au site, via le contexte implicite du cache, qui sert à définir l'identifiant de mise en cache (donc 2 hits sur la meme page via 2 host différents tomberont sur 2 identifiants différents)
Le cas qui peut être problématique est celui de la base répliquée entre plusieurs serveurs, mais là on entre dans un autre sujet et pour qu'il y ait collision cela supposerait que le dossier tmp/cache est commun aux serveurs. Ce qui semble une mauvaise idée si chaque serveur à sa base (répliquées avec possibles désynchro ?). Dans ce cas il suffit de définir un dossier cache sur chaque machine (via un `define('_DIR_CACHE',...) qui tape dans un dossier qui n'est pas partagé).
Si le problème vient d'une utilisation de memoization (cache via memcached ou autre), alors ce n'est pas ici qu'il faut en parler car ça ne concerne pas le core
Le cas qui peut être problématique est celui de la base répliquée
entre plusieurs serveurs, mais là on entre dans un autre sujet et
pour qu'il y ait collision cela supposerait que le dossier tmp/cache
est commun aux serveurs.
On se heurte au problème dans ce contexte, mais chaque serveur
a son dossier cache. La base de donnée est partagée, sauf certaines
tables qui restent locales (jobs; syndic, urls, transactions, visites, referers).
Comme chaque machine a son cache, elle tente d'écrire la meta cache_signature avec une valeur qui rentre en conflit avec celle des autres, d'où l'idée d'avoir un nom de meta différente pour chaque cache.
cedric - a écrit :
> Le cas qui peut être problématique est celui de la base répliquée
> entre plusieurs serveurs, mais là on entre dans un autre sujet et
> pour qu'il y ait collision cela supposerait que le dossier tmp/cache
> est commun aux serveurs.
On se heurte au problème dans ce contexte, mais chaque serveur
a son dossier cache. La base de donnée est partagée, sauf certaines
tables qui restent locales (jobs; syndic, urls, transactions, visites, referers).
Comme chaque machine a son cache, elle tente d'écrire la meta cache_signature avec une valeur qui rentre en conflit avec celle des autres, d'où l'idée d'avoir un nom de meta différente pour chaque cache.
Comment ça "chaque machine tente d'écrire la meta avec une valeur qui rentre en conflit avec celle des autres" ?
On ecrit la meta qu'une seule fois dans toute la vie du site, et une fois que la meta existe elle n'est plus jamais modifiée, chaque machine devrait donc utiliser la même valeur ici, ce qui n'est absolument pas gênant
Cette signature est uniquement une sécurité anti-injection pour éviter qu'un autre site malveillant ne soit en mesure d'injecter des faux caches, elle n'intervient en rien dans la gestion du cache par lui même, qui tient déjà compte normalement des spécificités de l'instance via la fonction calculer_contexte_implicite() https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/assembler.php#L204
Si la modification de cette signature corrige un problème avéré, il est a craindre que ce ne soit pas la bonne correction et masque en fait un autre bug.
Il faudrait donc remonter à la source du vrai problème constaté et voir ce que cela impacte et si ce n'est pas plutôt la fonction calculer_contexte_implicite() qui devrait évoluer, ce qui est à envisager avec prudence là aussi.
Comment ça "chaque machine tente d'écrire la meta avec une valeur qui rentre en conflit avec celle des autres" ?
On ecrit la meta qu'une seule fois dans toute la vie du site, et une fois que la meta existe elle n'est plus jamais modifiée, chaque machine devrait donc utiliser la même valeur ici, ce qui n'est absolument pas gênant
Cette signature est uniquement une sécurité anti-injection pour éviter qu'un autre site malveillant ne soit en mesure d'injecter des faux caches, elle n'intervient en rien dans la gestion du cache par lui même, qui tient déjà compte normalement des spécificités de l'instance via la fonction calculer_contexte_implicite()
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/assembler.php#L204
Si la modification de cette signature corrige un problème avéré, il est a craindre que ce ne soit pas la bonne correction et masque en fait un autre bug.
Il faudrait donc remonter à la source du vrai problème constaté et voir ce que cela impacte et si ce n'est pas plutôt la fonction calculer_contexte_implicite() qui devrait évoluer, ce qui est à envisager avec prudence là aussi.
La meta cache_signature n'envisage pas que la base puisse être utilisée avec plusieurs caches différents. Cette situation peut exister si on a plusieurs VirtualHost utilisant la même base, ou bien si une base est répliquée entre plusieurs machines servant le même site (installation haute dispo).
L'utilisation de la même meta pour contrôler plusieurs caches va provoquer soit des recalculs inutiles, soit des conflits de réplication de base de donnée.
Le problème peut être évité en suffixant le nom de la meta par un identifiant dépendant du VirtualHost et de la machine. Le patch ci-joint implémente cette modification.
Bonjour
Merci pour le patch.
Est il possible de le proposer en tant que pull request sur
https://git.spip.net/SPIP/spip (compte de la zone) ou bien sur le
clone public http://github.com/spip/spip ?
C'est fait:
https://github.com/spip/SPIP/pull/26
Est-ce que je dois lancer des pull requests pour les branches de SPIP?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu`netbsd.org
bonjour
Merci pour le PR. Pour le moment il faut mieux faire sur la
trunk/master, le report sur les branches est à avoir au cas par cas.
Je suis preneur d'un relecteur de code pour valider le PR.
je vais regarder, mais je pense que la PR ne doit pas être appliquée en l'état :
Le cas qui peut être problématique est celui de la base répliquée entre plusieurs serveurs, mais là on entre dans un autre sujet et pour qu'il y ait collision cela supposerait que le dossier tmp/cache est commun aux serveurs. Ce qui semble une mauvaise idée si chaque serveur à sa base (répliquées avec possibles désynchro ?). Dans ce cas il suffit de définir un dossier cache sur chaque machine (via un `define('_DIR_CACHE',...) qui tape dans un dossier qui n'est pas partagé).
Si le problème vient d'une utilisation de memoization (cache via memcached ou autre), alors ce n'est pas ici qu'il faut en parler car ça ne concerne pas le core
Statut changé à En cours
cedric - a écrit :
On se heurte au problème dans ce contexte, mais chaque serveur
a son dossier cache. La base de donnée est partagée, sauf certaines
tables qui restent locales (jobs; syndic, urls, transactions, visites, referers).
Comme chaque machine a son cache, elle tente d'écrire la meta cache_signature avec une valeur qui rentre en conflit avec celle des autres, d'où l'idée d'avoir un nom de meta différente pour chaque cache.
Comment ça "chaque machine tente d'écrire la meta avec une valeur qui rentre en conflit avec celle des autres" ?
On ecrit la meta qu'une seule fois dans toute la vie du site, et une fois que la meta existe elle n'est plus jamais modifiée, chaque machine devrait donc utiliser la même valeur ici, ce qui n'est absolument pas gênant
Cette signature est uniquement une sécurité anti-injection pour éviter qu'un autre site malveillant ne soit en mesure d'injecter des faux caches, elle n'intervient en rien dans la gestion du cache par lui même, qui tient déjà compte normalement des spécificités de l'instance via la fonction calculer_contexte_implicite()
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/assembler.php#L204
Si la modification de cette signature corrige un problème avéré, il est a craindre que ce ne soit pas la bonne correction et masque en fait un autre bug.
Il faudrait donc remonter à la source du vrai problème constaté et voir ce que cela impacte et si ce n'est pas plutôt la fonction calculer_contexte_implicite() qui devrait évoluer, ce qui est à envisager avec prudence là aussi.
Pas de réponse à la demande de précisions
Statut changé à Fermé