You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
logger.infof("Setting a memory limit implies to have exactly one owner. Setting num_owners=1 to avoid data loss.", name);
builder.clustering().hash().numOwners(1);
We're currently wondering what exactly is meant by this line, and how it prevents data loss. Offline Sessions are persistent in the database, even if persistent sessions are disabled, so there should never be any data loss, regardless of how infinispan is configured for offline sessions.
With this setting, if the owner of an offline session goes offline, that session can no longer be fetched from cache on any of the remaining nodes in the cluster, and they all have to access it from the database. That might qualify as data loss, but then this setting is causing the data loss, not preventing it.
As I understand it, when a cache entry gets evicted due to memory limit, that entry is evicted from all owners, so there should not be a "consistency" issue either?
If I understand correctly, this configuration line means that if persistent sessions are disabled, Keycloak users have two choices regarding how the offline sessions are configured right now, which are either unbounded, because num_owners=1 is only enforced when there is a memory limit or non-distributed, because as soon as any memory limit is set, num_owners=1 is enforced. The latter can cause some unnecessary database load, while the former is potentially dangerous, because offline sessions can have rather long lifetimes, and if the cluster runs for a long time, the cache will grow and may cause OutOfMemoryErrors in the long run. Though the cache can still be bounded somewhat via spi-user-sessions-infinispan-offline-(client-)session-cache-entry-lifespan-override
Can someone shed some light on why this choice was made?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
While reviewing startup logs and our cache configuration, we stumbled upon this line in CacheConfigurator.java:
https://github.com/keycloak/keycloak/blob/26.4.7/model/infinispan/src/main/java/org/keycloak/spi/infinispan/impl/embedded/CacheConfigurator.java#L277.
We're currently wondering what exactly is meant by this line, and how it prevents data loss. Offline Sessions are persistent in the database, even if persistent sessions are disabled, so there should never be any data loss, regardless of how infinispan is configured for offline sessions.
With this setting, if the owner of an offline session goes offline, that session can no longer be fetched from cache on any of the remaining nodes in the cluster, and they all have to access it from the database. That might qualify as data loss, but then this setting is causing the data loss, not preventing it.
As I understand it, when a cache entry gets evicted due to memory limit, that entry is evicted from all owners, so there should not be a "consistency" issue either?
If I understand correctly, this configuration line means that if persistent sessions are disabled, Keycloak users have two choices regarding how the offline sessions are configured right now, which are either unbounded, because
num_owners=1is only enforced when there is a memory limit or non-distributed, because as soon as any memory limit is set,num_owners=1is enforced. The latter can cause some unnecessary database load, while the former is potentially dangerous, because offline sessions can have rather long lifetimes, and if the cluster runs for a long time, the cache will grow and may cause OutOfMemoryErrors in the long run. Though the cache can still be bounded somewhat viaspi-user-sessions-infinispan-offline-(client-)session-cache-entry-lifespan-overrideCan someone shed some light on why this choice was made?
Beta Was this translation helpful? Give feedback.
All reactions