Bonjour, Je tenais tout d'abord à remercier Jean Marc et Olivier pour les réponses qu'ils m'ont apporté ce matin. Je vais regarder ces informations de plus près. Afin de pouvoir être plus réactif sur les mails reçus, je souhaiterais modifier mon mode d'abonnement à cps-users-fr (actuellement un mail envoyé pour 5 messages). Je souhaiterais recevoir un mail par message posté sur la liste. Est-il possible de modifier cette configuration après inscription ?
Pour les réponses apportées par Jean Marc: >>> Il est possible d'attacher des événements à l'invalidation du cache. >>> Le contexte de l'événement peut aussi être pris en compte pour >>> limiter la couverture, cf event_in_folders (sur des répertoires >>> donnés), event_on_types (pour des types d'objets donnés) .. mais pas >>> pour un utilisateur donné. >>> >>> donc si vous associez un évenement "event_ids:role_changed" au >>> parametres du cache portlet (c'est un exemple encore faut-il qu'il y >>> ait un évenement 'role_changed' qui soit émis) l'invalidation aura >>> lieu indépendemment de l'utilisateur pour qui le rôle a changé. Mais >>> dans votre cas cela devrait suffir? >> >> Corrige moi si je me trompe JM, mais l'invalidation ne se fera que sur >> le client ZEO sur lequel l'evennement a été émis, non ? Les caches >> des autres ZEO ne seront pas informé de la modification des roles, si ? >> > >si si, ca marche, l'information est écrite dans la ZODB donc elle se >propage entre les instance ZEO. Dans mon cas précis, je souhaite vraiment purger le cache pour un user uniquement (sinon, l'utilisation du cache n'a plus vraiment d'intérêt, si à chaque modification d'un user, on vide le cache complet pour ce portlet, çà revient à ne pas utiliser de cache je pense). N'y a-t-il pas moyen de surcharger expireCache pour lui passer des clefs de purge comme c'est le cas de la méthode "invalidateCacheEntriesByUser" (mais qui ne fonctionne qu'en local d'après les commentaires) ? Pour les réponses apportées par Olivier: >> - Notre application étant répartie sur plusieurs zClients, est-il >> possible de réaliser cette invalidation simultanément sur tous les >zClients ? > >Chaque client ZEO a son propre cache et à ma connaissance les caches sont >complétement indépendants des autres, de même que la gestion de >évennements. > >Pour éviter ce genre de désagréments il faut utiliser un load balancer qui >gére l'affinité des requetes en surveillant le cookie __ac_name par >exemple. pound 1 ou 2 sait faire ca. Actuellement, un pound est en place avec cette affinité cookie réglée à priori: User nobody Group nobody #RootJail /usr/local/pound LogLevel 3 Alive 1 Server 0 Client 1 #ListenHTTP *,8090 ListenHTTP *,8090 #ListenHTTPS *,443 /usr/share/ssl/certs/pound.pem ExtendedHTTP 1 # Catch dev server #UrlGroup ".preprod*" #Session COOKIE _ZopeId 3600 #BackEnd 172.16.10.7,8080,5 #EndGroup # Catch-all server(s) UrlGroup ".*" Session COOKIE _ZopeId 3600 BackEnd 172.16.10.2,8080,5 BackEnd 172.16.10.3,8080,5 BackEnd 172.16.10.21,8080,5 BackEnd 172.16.10.31,8080,5 EndGroup Pour autant, nous rencontrons toujours ce soucis. N'est-il pas possible d'implémenter un mécanisme sur base de celui définit pour CPSPortlets ? A vrai dire, je ne comprends pas bien le mode de fonctionnement de ce qui est implémenté pour CPSPortlets, car si on stocke en ZODB les informations de rafraîchissement, cela signifie qu'une requête part à la ZODB avant d'essayer de restituer son cache local. Ce qui, d'après moi, ralenti les performances globales non ? Cordialement Cédric Marfil Ingénieur conseils en Technologies de l'information Unilog IT Services NRD a logicaCMG company Marcq en Baroeul Tél: 03.59.56.60.68 (actuellement joignable à la CRMA au 03.20.14.26.36) Mail: [EMAIL PROTECTED] _______________________________________________ cps-users-fr Adresse de la liste : [email protected] Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>
