Jedis VS Redisson

Finding out what's causing that was not that simple as Jedis does not write a lot of log information when the log level is set to debug. From what we could tell from the Jedis source code it seems that when the Jedis client connects to the configuration endpoint it fetches all known hosts. It stores that in a local cache and figures out the primary node from the set of nodes. Once the primary node is known it will execute operations against the primary node. It does so by connecting to the Amazon-generated domain name/entry and when that entry is down / unreachable it seems it does not use the configuration endpoint to rediscover the nodes or fetch the new cluster topology. We initially thought this had to do with the DNS caching of the JVM, so we also tried to disable caching, but we did not see any effect after that change.

jedis is used to interact with Redis.

Como um bônus, deixo aqui uma classe SessionManager pra ajudar na implementação em Java usando Jedis e o gerador de token do Tomcat, que já é normalmente incluído no Spring Boot:

Source code you can find in the GitHub repository. he main idea of this project is the implementation of microservice using Kotlin, Spring WebFlux, PostgresSQL, and Redis with metrics and monitoring and deploying it to k8s. For interacting with PostgresSQL we will use reactive Spring Data R2DBC and for Redis caching using Redisson.

I came up empty handed in search of an alternative to Quartz for scheduling Crons in a clustered/distributed environment. Redisson has a scheduler, but it came with its own issues: - https://github.com/redisson/redisson/issues/4020 - https://github.com/redisson/redisson/issues/3991 - https://github.com/redisson/redisson/issues/4321

4. We use the open-source library Redisson to connect to Redis instance and use Redis as Hibernate 2nd level cache. Please see their Github repo for more information.