[keycloak-user] Keycloak + Infinispan Passivation Failure

Marek Posolda mposolda at redhat.com
Wed Feb 13 10:28:55 EST 2019


On 12/02/2019 22:02, Coe, Matthew wrote:
> Hello!
>
> I’m attempting to configure a cluster of standalone Keycloak 4.7.0.Final instances to have their Infinispan data persisted. I’m using JDBCPING to create the cluster, and our user load is great enough that we don’t want to keep all our sessions in memory.
>
> I’ve configured the “sessions” cache as follows:
>
> <distributed-cache name="sessions" statistics-enabled="true">
>      <state-transfer timeout="600000" />
>      <object-memory size="2"/>
>      <jdbc-store data-source="KeycloakDS" passivation="true" dialect="MYSQL" purge="false" shared="true">
>          <table>
>              <id-column type="VARCHAR(255)"/>
>              <data-column type="BLOB" name="data"/>
>              <timestamp-column type="BIGINT(20)" name="timestamp"/>
>          </table>
>      </jdbc-store>
> </distributed-cache>
>
> The object-memory size is selected purely for testing purposes, so that I can quickly hit a point where data will need to be evicted from Infinispan.
>
> The problem I’m running into is that data is only persisted to MySQL is passivation is on, where it exhibits the predictable passivation behaviour. When I turn passivation to false, instead of acting as a write-through cache, will all data persisted, no data is persisted at all. Once I fill the object-memory size, sessions start getting dropped behind the scenes.
>
> Is this pilot error? Or have I found a bug in Infinispan? DEBUG-level logging doesn’t reveal any complaints from the underlying systems.

We're programatically adding the flag to skip cacheStore/cacheLoad to 
many operations on userSession. The reason is, that for cross-dc 
scenario, we're programatically invoking execution of some operations on 
remote caches (JDG servers).

In other words, no other infinispan stores besides remote-store will 
properly work. Feel free to create JIRA (or add yourself as a vote to 
existing JIRA as it maybe already exists).

Marek

>
> Thanks!
>
> Matthew G P Coe
>
> Platform Software Developer
>
>
> T 416.969.2365
>
> M 416.427.7315
>
> E mcoe at ebay.com
>
> A 500 King Street West, Unit 200, M5V 1L8, Toronto, ON
>
>
>
> [Kijiji]
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user




More information about the keycloak-user mailing list