[spip-dev] Dernier bug avant la 2.1.1

Hello,
il reste un bug sur la 2.1.1 pour lequel je sollicite votre avis.

Pour des raisons de performance, j'ai modifié sous_repertoire pour que la fonction ne vérifie qu'une seule fois par hit l'existence d'un dossier utilisé.

Pour des raisons de rangement, fil a introduit des sous-dossier pour ranger les caches sessionnés d'un même squelette. Du coup, on a été obligé d'activer la purge des sous dossier dans la purge du cache car sinon ces sous-dossiers n'etaient jamais supprimés et on finissait par deborder du nombre possible de dossier/fichiers dans un dossier de cache.

De ces deux modifs, est apparu un bug :
en cas de concurrence entre purge du cache et calcul du cache, il arrive que SPIP essaye d'écrire dans un sous-dossier qui n'existe plus (mais existait au debut du hit).

Deux solutions à cela :
- revenir sur l'optimisation perfo
- revenir sur le rangement des caches sessionnes en sous dossiers (quitte à les prefixer pour les garder groupés) et supprimer la purge recursive des dossier de cache.

Perso je penche pour la deuxième solution car je n'ai jamais vraiment eu l'usage de ces sous dossier de cache, alors que l'optimisation perfo impacte tous les sites.
Mais quelle solution a votre préférence ?

Cédric

  • revenir sur le rangement des caches sessionnes en sous dossiers

pourquoi pas

(quitte à les prefixer pour les garder groupés)

Non ça c’est impossible ; lorsqu’on appuie sur « recalculer cette page », il faut pouvoir adresser « tous les caches sessionnés de la page x » sans devoir parcourir un répertoire contenant potentiellement des dizaines de milliers de fichiers. C’est pour cette raison que je les avais mis dans un sous-répertoire. Il y a peut-être d’autres solutions (par ex, lister les caches sessionnés dans le cache non sessionné), mais celle de les poser en vrac pour les retrouver ensuite par scan n’est pas envisageable.

Cela dit, la méthode actuelle, par répertoire, pose d’autres problèmes, comme par exemple celui de ne pas se prêter à la mise en cache dans un autre mode que « fichier » (je pense à xcache ou memcache). Il faut donc inventer une meilleure méthode.

Si je résume :

  • il faut pouvoir trouver efficacement la liste de tous les caches sessionnés d’une page X
  • j’ai codé ça sous forme d’un sous-répertoire (c’est la méthode « filesystem »), ce qui n’est pas adaptable à d’autres types de cache, et de plus crée maintenant ce conflit avec ton optimisation
  • l’autre solution serait de maintenir à la main une liste de ces fichiers dans un « filesystem maison », stocké par ex dans le fichier non sessionné

– Fil

donc pour la 2.1.1, il y a peu d’autre solution que de revenir sur l’optimisation perfo
mais il faut règler ce problème en priorité pour une 2.1.2 alors.

Cédric

donc pour la 2.1.1, il y a peu d’autre solution que de revenir sur l’optimisation perfo
mais il faut règler ce problème en priorité pour une 2.1.2 alors.

il faut pas être défaitiste ; ça ne me paraît pas si compliqué que ça à reprogrammer.

– Fil

Certes, mais ça va introduire des bugs, faut tester valider etc…
Et il faut arrêter de repousser cette 2.1.1
On peut aussi dire qu’on laisse en l’état et qu’on sort une 2.1.2 dès qu’on a un fix.

Cédric

Certes, mais ça va introduire des bugs

rho :smiley:

, faut tester valider etc…
Et il faut arrêter de repousser cette 2.1.1

on peut se donner jusqu’à samedi ?

On peut aussi dire qu’on laisse en l’état et qu’on sort une 2.1.2 dès qu’on a un fix.

tu es en train de dire qu’il vaut mieux un bug certain qu’un bug imaginaire ?

– Fil

Certes, mais ça va introduire des bugs

voilà qui est fait
http://trac.rezo.net/trac/spip/changeset/15851

-- Fil