Re: [keycloak-user] Cache invalidation Javascript policies - cluster mode

Hi Pedro, It seems that the cache gets invalidated only in the node which received the policy update request. I'm not sure if i'll be able to provide the steps in a vanilla installation, but i'm going to open a Jira. Thank you again, Matteo On Mon, Jul 29, 2019 at 2:45 PM Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Hi, > > It does. But at the same time, I'm quite sure we are invalidating entries > in the cache when a policy is updated. Could you please create a JIRA to > track this? I'll need to spend some time testing this locally and try to > reproduce the issue. If you provide some steps to reproduce this (and are > able to do so) using a vanilla installation, I appreciate. > > Regards. > Pedro Igor > > On Mon, Jul 29, 2019 at 7:47 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; > wrote: > >> Hi all, >> We have a custom Javascript policy, and we're running 3 Keycloak >> instances >> in a Kubernetes cluster. >> Cluster configuration is based on DNS_PING and we've followed the Helm >> provided by Codecentric. >> The three Keycloak pods successfully joined the cluster (in standalone >> mode). We're seeing this from following log lines: >> >> 10:16:02,114 INFO [org.infinispan.CLUSTER] (MSC service thread 1-4) >> ISPN000094: Received new cluster view for channel ejb: [keycloak-2|13] >> (3) >> [keycloak-2, keycloak-1, keycloak-0] >> 10:16:02,114 INFO [org.infinispan.CLUSTER] (MSC service thread 1-3) >> ISPN000094: Received new cluster view for channel ejb: [keycloak-2|13] >> (3) >> [keycloak-2, keycloak-1, keycloak-0] >> 10:16:02,114 INFO [org.infinispan.CLUSTER] (MSC service thread 1-2) >> ISPN000094: Received new cluster view for channel ejb: [keycloak-2|13] >> (3) >> [keycloak-2, keycloak-1, keycloak-0] >> 10:16:02,114 INFO [org.infinispan.CLUSTER] (MSC service thread 1-1) >> ISPN000094: Received new cluster view for channel ejb: [keycloak-2|13] >> (3) >> [keycloak-2, keycloak-1, keycloak-0] >> 10:16:02,120 INFO >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC >> service >> thread 1-4) ISPN000079: Channel ejb local address is keycloak-0, physical >> addresses are [10.71.10.170:7600] >> 10:16:02,120 INFO >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC >> service >> thread 1-3) ISPN000079: Channel ejb local address is keycloak-0, physical >> addresses are [10.71.10.170:7600] >> 10:16:02,120 INFO >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC >> service >> thread 1-1) ISPN000079: Channel ejb local address is keycloak-0, physical >> addresses are [10.71.10.170:7600] >> 10:16:02,120 INFO >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC >> service >> thread 1-2) ISPN000079: Channel ejb local address is keycloak-0, physical >> addresses are [10.71.10.170:7600] >> 10:16:02,755 INFO >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC >> service >> thread 1-3) ISPN000078: Starting JGroups channel ejb >> 10:16:02,756 INFO [org.infinispan.CLUSTER] (MSC service thread 1-3) >> ISPN000094: Received new cluster view for channel ejb: [keycloak-2|13] >> (3) >> [keycloak-2, keycloak-1, keycloak-0] >> 10:16:02,757 INFO >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC >> service >> thread 1-3) ISPN000079: Channel ejb local address is keycloak-0, physical >> addresses are [10.71.10.170:7600] >> >> >> The problem can be reproduced by the following: >> - We update the code of our Javascript policy, adding a new "print" >> - We just see the new log line on one node, the others are not printing >> the >> new log >> >> Maybe is something related to cache invalidation? >> >> Thank you very much, >> Matteo Restelli >> >> -- >> >> Like <https://www.facebook.com/cuebiq/> I Follow >> <https://twitter.com/Cuebiq>I Connect >> <https://www.linkedin.com/company/cuebiq> >> >> >> This email is reserved >> exclusively for sending and receiving messages inherent working >> activities, >> and is not intended nor authorized for personal use. Therefore, any >> outgoing messages or incoming response messages will be treated as >> company >> messages and will be subject to the corporate IT policy and may possibly >> to >> be read by persons other than by the subscriber of the box. Confidential >> information may be contained in this message. If you are not the address >> indicated in this message, please do not copy or deliver this message to >> anyone. In such case, you should notify the sender immediately and >> delete >> the original message. >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >