[Sylvain Wallez] > J'ai l'impression que laisser le cache Cocoon faire son boulot tout > seul comme un grand est la meilleure solution ;-)
[Fr�d�ric Glorieux]
J'ai test� l'ImageReader de Cocoon sur 100 nouvelles images � g�n�rer. S'il est dans les 64Mo standard java, une image sur 7 � 10 passe � la trappe, et cocoon met en cache des fichiers corrompus (d'o� ma confiance relative envers la cache cocoon pour ce genre d'op�rations).
Apr�s tests en Cocoon 2.1.5, je ne conseille pas d'utiliser ImageReader dans un tuyau cachable. Si un OutOfMemory arrive durant la g�n�ration d'une vignette, la vignette corrompue est mise en cache, et il est bien difficile de s'en d�barrasser. Il est je suppose possible de configurer son serveur pour diminuer le nombre de requ�tes jpg traitable selon la m�moire que l'on a disposition, ou bien il faudrait organiser des files d'attente quelque part, ou la petite ligne qui va bien dans la cache Cocoon...
En attendant, la proposition au d�but de ce fil de mettre en place sa propre proc�dure de cache a au moins cet avantage, on �vite d'�crire un fichier corrompu. Le premier qui demande une grosse page de vignettes peut avoir quelques blancs, mais le 2e les rebouche, voir le 3e (selon la m�moire allou�e � la JVM). A moiti� �l�gant, mais bon, �a fonctionne, et les blancs seront probablement d'abord pour les �diteurs, le public ne les verra pas.
Seul d�tail, cela ajoute une comparaison entre 2 File.lastModified() avant que Cocoon serve des fichiers statiques (avec la cache m�moire pour le coup !).
--
Fr�d�ric Glorieux ("AJLSM", <http://ajlsm.com>)--------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
