Repository navigation
Add support for overriding offline session lifespan values - #24302
thomasdarimont wants to merge 3 commits into
Conversation
See: keycloak#24274 Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
- We now take the configured realm values into account - Made InfinispanUserSessionProviderFactory a ServerInfoAwareProvider to expose the detailed configuration
5b4ecb7 to
0a6fed8
Compare
|
Hi @thomasdarimont - we're considering your solution and are are currently making up our minds which automated tests we would add to it. As this PR is already some months old, do you have some ideas / thoughts / code you would like to add? |
|
Hey @ahus1 thanks for the heads up! That's awesome news :) Some ideas: In my PR, I introduced dedicated settings for Most users who need to customize the cache behavior want to reduce memory usage over time, especially when many offline sessions are at play. Those users will probably adjust the max-idle time of the offline user/client sessions cache to be ~10 hours to cover a workday or 24 hours to cover a full-day travel experience in a travel companion app. The current default cache-ispn.xml file does not specify a max-idle, hence it uses either the internal default (-1) or a Keycloak controlled value. Perhaps we could make Keycloak inspect the provided cache configuration, and if we detect that the admins configured max-idle differently than the default, we could use that. :)
|
|
Hi @thomasdarimont - thank you for the comment. We prefer documented options instead of a long XML file where people might get lost. Due to this, we prefer the SPI-parameters. Maybe we'll eventually have a CLI option for it. About the max-idle in the XML: As we're passing the lifetime and idle via the Java API, I was under the assumption that those would take precedence? Having that configurable via the UI per realm would be a next step. Let's take it one step at a time. |
|
Closing in favor of #26811 |
See: #24274
Signed-off-by: Thomas Darimont thomas.darimont@googlemail.com