...
Jusque-là le Redis Ticket Registry fonctionnait bien ainsi, mais l'apparition de ces entrées CAS_PRINCIPAL:uid (sorte de rustine ayant pour but de retrouver rapidement les tickets d'un utilisateur donné) vient casser ce système et il semble aventureux de fonctionner ainsi.
Ce
| Info |
|---|
| Après lecture du code (DefaultTicketRegistryCleaner et RedisTicketRegistry dans CAS), ce que l'on |
...
| en conclue ici, c'est que Redis supprime naturellement les entrées du type CAS_TICKET:TGT-numero en fonction du TTL positionné ; aussi lorsque le DefaultTicketRegistryCleaner passe, les tickets déjà supprimés par Redis lui-même ne sont pas listés/pris en compte par la procédure de CAS qui, de fait, ne les supprime pas des sets listés dans CAS_PRINCIPAL:uid ; en fonctionnant ainsi, l'ensemble des serialisation des TGT (avec l'ensemble des attributs utilisateurs associés) vont donc perdurer dans les CAS_PRINCIPAL:uid sans jamais être nettoyés pour consommer très rapidement l'ensemble de la RAM disponible (le graphe nous montre une consommation d'environ 1GB de RAM jour sur une période estivale de congés) - on peut considérer ce pb comme un bug. Provenant de toute manière d'une implémentation contournant une "limitation" Redis sur la recherche par index, il semble ici plus simple de ne pas s'obstiner sur cette option de ticket registry Redis, dans cette version 6.6 en tout cas. |
Notre CAS avec esup-otp utilisant dès à présent pour certaines données une base MongoDB, on s'est naturellement tourné vers le Ticket Registry sous MongoDB.
...