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

[Matteo Restelli]

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 at redhat.com> 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 at cuebiq.com>
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>

-- 

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.