Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keyspaceEvents cannot be configured [DATAREDIS-1075] #1612

spring-projects-issues opened this issue Dec 4, 2019 · 0 comments

keyspaceEvents cannot be configured [DATAREDIS-1075] #1612

spring-projects-issues opened this issue Dec 4, 2019 · 0 comments


Copy link

@spring-projects-issues spring-projects-issues commented Dec 4, 2019

ismael COULIBALY opened DATAREDIS-1075 and commented

Hey guys,
Me and my team are facing a probleme due to the usage of Spring Data Redis 2.2.2 in a Spring Boot App.
We are working on a App based on a microservice architecture. Three of our microservices put data in the same instance of Redis but inside different logical databases.
Some of data we put into Redis are tagged with the annotation @TimeToLive (TTL).
We also enabled the keyspaceEvents on start up [@EnableRedisRepositories(enableKeyspaceEvents = RedisKeyValueAdapter.EnableKeyspaceEvents.ON_STARTUP)].

The probleme we face is that keyspaceEvents are seen (received) by all logical databases. That make our pool of connection explode.

It seems like the management of keyspaceEvents is done right here :
In the code, we can see this : "keyevent@*:expired".
The wildcard means that the keyspaceEvents are seen by every logical database.

So, all of our microservices pollute each other because each of them see the keyspaceEvents of the other.

Can you make keyspaceEvents management configurable (TTL in particular) so that a logical database only receive events that happen in his scope ?


Referenced from: pull request #503

1 votes, 2 watchers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants