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

Adding resiliency in RedisClusterClient #44

Merged
merged 9 commits into from
Feb 16, 2022

Conversation

andrijaperovic
Copy link
Contributor

  • Handles TCP keepidle in failover scenario with Redis for stateful connection
  • Adding auth with SSL support for REDIS_CLUSTER type configuration
  • Handle cluster details endpoint of Redis Cluster returning IP in REDIS_CLUSTER type connection

@snowmanmsft @adchia

bootstrap.option(EpollChannelOption.TCP_KEEPINTVL, 5);
bootstrap.option(EpollChannelOption.TCP_KEEPCNT, 3);
// Socket Timeout (milliseconds)
bootstrap.option(EpollChannelOption.TCP_USER_TIMEOUT, 60000);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thoughts on having these be exposed in the cluster config?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that makes sense. Also, these are very cloud provider specific for Azure Cache for Redis in terms of how socket timeouts are handled (redis/lettuce#1428), so I'm wondering if it makes sense to subclass RedisClusterClient and make it cloud-provider specific (e.g. AzureRedisClusterClient, AwsRedisClusterClient, GcpRedisClusterClient, etc.).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cloud provider can be set via config property (e.g. cloud_provider: azure).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i.e. this wouldnt hold true if you wanted to run your own Redis cluster in Azure?

Might make sense then to instead allow for additional azure_configs within the RedisClusterConfig?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adchia correct, if we ran something like redis-server instead of the managed service we would not need the custom socket timeout configuration and tcp keep-idle config. I suspect that it would also not be required in the MemoryDB/ElastiCache and Memorystore managed Redis scenarios.

Copy link
Contributor

@adchia adchia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

(handle tcp keepidle in failover scenario, auth with ssl & handle cluster
details endpoint returning IP in ssl scenario.

Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
…vel.

Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
…vel.

Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
…vel.

Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
Signed-off-by: Andrija Perovic <andrija.perovic@sap.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants