Le temps ne fait rien à l'affaire, si le système décide que c'est pas urgent d'écrire sur disque,
il ne le fait pas aussi longtemps qu'il veut. Cela dit, ce n'est qu'une hypothèse, le pb est peut-etre
ailleurs.
esj
C'est quand même étrange, l'ancien système faisait aussi un simple
"fopen" et rien de spécial ne se produisait.
Il ne manque pas un "fclose" quelque part (pas regardé le code, désolé)
?
Il ne manque pas un "fclose" quelque part (pas regardé le code, désolé)
Bonne suggestion. Par acquis de conscience, j'ai rajouté sur CVS le fclose sur le source du squelette,
mais a priori c'était transparent. J'ai aussi amélioré la verif d'autorisation de supprimer un cache
à partir d'une URL de forum.
esj
Bonne suggestion. Par acquis de conscience, j'ai rajouté sur CVS le fclose
sur le source du squelette, mais a priori c'était transparent.
Navré de te décevoir, mais on a encore de gros problèmes de cache sur
www.menteur.com ; voilà comment ça s'observe :
- 1 publier une brève longue
- 2 recalculer la page d'accueil
- 3 dépublier la brève longue et publier une brève courte
- 4 recalculer la page d'accueil
La page d'accueil affiche la brève la plus récente : à l'étape 4 le fichier
fait la même longueur qu'à l'étape 2, alors que la page est censée être plus
courte. ET ce qui "déborde" correspond à la fin de la page de l'étape 2.
Par ailleurs il est possible de "recalculer" une page et qu'elle s'affiche
quand même avec l'*
Tout ça est un poil compliqué à tester, mais observé plusieurs fois sur les
toutes dernières versions de la CVS.
-- Fil
Tout ça est un poil compliqué à tester, mais observé plusieurs fois sur les
toutes dernières versions de la CVS.
Dans inc-cache, la séquence suivante :
if (!$lock2 = fopen($file, 'r+b'))
[...]
fseek($lock2,0);
fwrite($lock2, "<!-- $fraicheur\t" .
$page['process_ins'] .
"\t" .
$page['invalideurs']['squelette'] .
"\t$cle pid: " .
getmypid() .
" -->\n");
fwrite($lock2,$texte);
flock($lock2, LOCK_UN);
fclose($lock2);
...me semble clairement de nature à provoquer le bug décrit par Fil : la
page est ouverte en "r+b" et non "wb", ce qui ne tronque pas le contenu
existant quand on écrit un nouveau contenu. Je me demande même pourquoi
ce bug n'est pas constaté plus souvent.
A propos, on connaissait le "code spaghetti", voici maintenant les
"locks spaghetti" ;-))
a+
Antoine.
> Tout ça est un poil compliqué à tester, mais observé plusieurs fois sur
> les toutes dernières versions de la CVS.
Voici la séquence précise et les spip.log correspondants.
1- je publie
Jul 21 15:11:29 127.0.0.1 (pid 409) demande indexation article 3713
2- je recalcule
Jul 21 15:11:36 127.0.0.1 (pid 409) GET Wed, 21 Jul 2004 13:06:47 GMT
/~fil/spip/index.phpoui
Jul 21 15:11:36 127.0.0.1 (pid 409) Squelette sommaire-dist:
(html_bb9b4246ba4e0715e5787291371ec02c)13855 octets, 157 ms
Jul 21 15:11:37 127.0.0.1 (pid 409) Page sommaire-dist: 9754 octets, 486 ms
Jul 21 15:11:37 127.0.0.1 (pid 409) libËre verrou /~fil/spip/ (9754 octets,
7200 sec de validitÈ.)
Jul 21 15:11:37 127.0.0.1 (pid 409) Page 100% HTML (9972 octets)
Jul 21 15:11:37 127.0.0.1 (pid 409) effectuer_une_indexation
Jul 21 15:11:37 127.0.0.1 (pid 409) indexation article 2360
fichiers modifiés en cache :
CACHE/c/7200/6bdb953f6dce76acc2e2b9c07eec3048.html
CACHE/s/html_bb9b4246ba4e0715e5787291371ec02c.php
3- je dépublie
4- je recalcule
Jul 21 15:12:27 127.0.0.1 (pid 576) GET /~fil/spip/index.phpoui
Jul 21 15:12:27 127.0.0.1 (pid 576) Squelette sommaire-dist:
(html_bb9b4246ba4e0715e5787291371ec02c)13855 octets, 161 ms
Jul 21 15:12:27 127.0.0.1 (pid 576) Page sommaire-dist: 9180 octets, 434 ms
Jul 21 15:12:27 127.0.0.1 (pid 576) libËre verrou /~fil/spip/ (9180 octets,
7200 sec de validitÈ.)
Jul 21 15:12:27 127.0.0.1 (pid 576) Page 100% HTML (9398 octets)
Jul 21 15:12:27 127.0.0.1 (pid 576) effectuer_une_indexation
Jul 21 15:12:27 127.0.0.1 (pid 576) indexation article 2361
fichiers modifiés en cache : les mêmes
CACHE/c/7200/6bdb953f6dce76acc2e2b9c07eec3048.html
CACHE/s/html_bb9b4246ba4e0715e5787291371ec02c.php
5- je vais sur la page sans ?recalcul = elle est trop longue.
Jul 21 15:13:15 127.0.0.1 (pid 495) GET Wed, 21 Jul 2004 13:06:47 GMT
/~fil/spip/index.php
Jul 21 15:13:15 127.0.0.1 (pid 495) Page 100% HTML (9976 octets)
Jul 21 15:13:15 127.0.0.1 (pid 495) effectuer_une_indexation
Jul 21 15:13:16 127.0.0.1 (pid 495) indexation article 2364
Dans inc-cache, la séquence suivante :
if (!$lock2 = fopen($file, 'r+b'))
Oui, ça corrige ! Ouf !
-- Fil
> Dans inc-cache, la séquence suivante :
> if (!$lock2 = fopen($file, 'r+b'))Oui, ça corrige ! Ouf !
Je ne sais pas comment tu corriges, mais si tu mets "wb" à la place et
avant de faire le lock, d'autres processus risquent de voir une page
vide (rendant les locks à peu près inutiles)...
A propos, un article célèbre :
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html
a+
Antoine.
C'est vrai, mais le fseek, dans mon esprit, était censé le faire.
Mais tu dois avoir raison: le fseek ici ne doit porter que l'aspect lecture,
et pas sur l'aspect écriture. Je reprends ça tout de suite.
esj
Je ne sais pas comment tu corriges, mais si tu mets "wb" à la place et
avant de faire le lock, d'autres processus risquent de voir une page
vide (rendant les locks à peu près inutiles)...
Je crois qu'on va revenir au mécanisme de inc-cache.php3 précédent, en
ajoutant éventuellement les deux locks qui manquent ?
A propos, un article célèbre :
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html
-- Fil
C'est vrai, mais le fseek, dans mon esprit, était censé le faire.
Mais tu dois avoir raison: le fseek ici ne doit porter que l'aspect
lecture,
et pas sur l'aspect écriture. Je reprends ça tout de suite.
ftruncate() doit faire l'affaire.
Je connais bien sur cet article, mais ça n'a pas de rapport:
je voudrais tout de même rappeler que la version précédente n'est pas fiable non plus,
et n'avait aucune chance de l'être sans utiliser les verrous de l'OS.
Qu'une version parfaitement fiable soit difficile à mettre au point, quoi d'étonnant,
d'autant que j'ai cherché à éviter les solutions de facilité consistant à bloquer tous
les processus à la fois, ou à avoir autant de fichier de verrouillage que de fichiers de cache.
esj
Navré de te décevoir, mais on a encore de gros problèmes de cache
pas de déception, je m'attendais pas à ce que le fclose ailleur change qqch.
En revanche, je n'arrive pas à reproduire le bug sur ma plate-forme.
>ftruncate() doit faire l'affaire.
Essayons ! J'ai fait le commit.
Oui, ça marche.
Il y a une autre bizarrerie dans les logs précités : quand on calcule une
page on est censé lever un lock SQL (via la fonction timeout(...)), de
manière à dire aux process en aval qu'il ne faut plus trop bosser (ne pas
indexer par exemple). Or là, ça indexe.
-- Fil
Il y a une autre bizarrerie dans les logs précités : quand on calcule une
page on est censé lever un lock SQL (via la fonction timeout(...)), de
manière à dire aux process en aval qu'il ne faut plus trop bosser (ne pas
indexer par exemple). Or là, ça indexe.
Une piste : on ne peut lever qu'un lock SQL à la fois. Le précédent est
automatiquement "releasé". Donc on ne peut pas les imbriquer.
a+
Antoine.
ftruncate() doit faire l'affaire.
Essayons ! J'ai fait le commit.
Oui, ça marche.
Ouf !
Je présente mes excuses à tout le monde pour avoir ramé aussi longtemps là-dessus.
Vous pouvez jeter un coup d'oeil au manuel PHP sur fread avec r+,
je pense que vous conviendrez qu'il y a une ambiguité dans la rédaction.
Merci Antoine.
Il y a une autre bizarrerie dans les logs précités : quand on calcule une
page on est censé lever un lock SQL (via la fonction timeout(...)), de
manière à dire aux process en aval qu'il ne faut plus trop bosser (ne pas
indexer par exemple). Or là, ça indexe.
Oui, j'avais repéré mais mis ça en background, il y avait plus urgent.
Je prends enfin le temps de déjeuner et je regarde.
Emmanuel
Je prends enfin le temps de déjeuner
Non mais quel scandale !
et je regarde.
En même temps si on importe le mécanisme inc_cron du spip-lab ce n'est
peut-être pas tellement la peine de se fatiguer avec ça...
-- Fil
J'ai un peu regardé, mais je ne comprends pas trop la logique de tout ça:
ça tourne autour d'un fichier ecrire/data/lock dont
1. je ne vois pas quand il est créé;
2. le processus pouvant être suspendu par l'OS, la date de ce fichier ne donne pas le temps déjà consommé par le processus mais seulement une borne supérieure;
3. en cas de processus concurrents, sa signification est franchement fausse.
Il y a qqch que je n'ai pas capté ?
esj
J'ai un peu regardé, mais je ne comprends pas trop la logique de tout
ça:
ça tourne autour d'un fichier ecrire/data/lock dont
1. je ne vois pas quand il est créé;
C'est un "lock hébergeur", qu'un processus externe pose dans tous les
répertoires ecrire/data/ de tous les spip quand l'hébergeur veut calmer les
spip, leur dire de ne pas faire les calculs pas nécessaires. Sur ma machine,
je pose ce lock dès que le load dépasse 2, ça refroidit les choses, et on
recommence au bout de 2 minutes, etc.
Ca n'a rien à voir avec le lock MySQL.
-- Fil
Finalement la commande de l'indexation n'a pas besoin de ce lock:
il suffisait de passer en argument à inc_cron l'info qu'on a recalculé la page ou pas.
Commis.
esj