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

Connection Event Metadata #2502

Open
bdchatham opened this issue Sep 5, 2023 · 2 comments
Open

Connection Event Metadata #2502

bdchatham opened this issue Sep 5, 2023 · 2 comments
Labels
for: team-attention An issue we need to discuss as a team to make progress status: waiting-for-triage

Comments

@bdchatham
Copy link

Feature Request

I have confirmed the feature does not exist and did not see a request like this one. A similar topic can be found here: #885.

Is your feature request related to a problem? Please describe

I have an issue when a cluster is de-provisioned (through AWS ElastiCache) and is no longer present at the configured endpoint. While there is a programmatic way to react to such events, there is no way to easily associate that event to domain-specific records.

Describe the solution you'd like

I would like to configure Redis clients to populate a metadata field that contains an arbitrary string value. This would be a unique id for a data structure we associate to the client/cluster. Specifically, this allows us to invalidate a cache stored for the cluster in the event an identical resource is created soon after this one is removed.

Describe alternatives you've considered

  1. Reactive invalidation; use RedisConnectionExceptions as a signal to invalidate the cache. This is a pretty good approach, but also comes with risk of unknowns. It's not clear whether RedisConnectionException would always be a good signal for this and in the event of wide-spread networking event that is not suitable for cache invalidation, it could have significant adverse affects.

  2. Robustness; it is doubtful that RedisConnectionExceptions will always be a signal to invalidate the cache. Moreover, using message pattern matching to determine sub-cases of RedisConnectionException although possibly workable, is quite brittle and opaque. Using the event-driven approach may run into similar issues, but seems more apt for the problem.

Teachability, Documentation, Adoption, Migration Strategy

Users can use this event-metadata to make Lettuce event-driven patterns more suited to their applications. Today, the events are generic and only give signal to state like remote or local addresses. While these may be helpful, they are not likely to be useful to consumers of Lettuce given it sets the requirement that such data must be coupled to their service's data structure mappings.

@mp911de
Copy link
Collaborator

mp911de commented Sep 6, 2023

I'm currently not sure what you're asking for. Lettuce's connection events provide already details if a connection has been established or disconnected. They do not include the logical connection as the underlying components aren't aware of connection composition (e.g. Redis Cluster connections consist of a bunch of individual connections).

@mp911de mp911de added the status: waiting-for-feedback We need additional information before we can continue label Sep 6, 2023
@bdchatham
Copy link
Author

bdchatham commented Sep 6, 2023

Hey Mark, sorry if this wasn't all that clear. Maybe explaining the use-case is better.

Basically my thought is to be able to define an immutable map of metadata which each Lettuce event has populated for a given client. Let's say in my application I have caches mapping customer ids to customer profiles. When I register a subscriber (consumer) to the ClientResources message bus, I want to be able to associate the failure to an entry in that cache to invalidate it. Today, I see only cluster address fields which are not helpful to determine which customer this event maps to. Being able to register a static map of fields to a RedisClient which will be attached to each dispatched event would make the events much more useful to maintain a correlation to custom business logic.

Conversely, I suppose you might tell me to create a separate consumer instance for each RedisClient that has this state populated at creation time.

@tishun tishun added for: team-attention An issue we need to discuss as a team to make progress status: waiting-for-triage and removed status: waiting-for-feedback We need additional information before we can continue labels Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: team-attention An issue we need to discuss as a team to make progress status: waiting-for-triage
Projects
None yet
Development

No branches or pull requests

3 participants