xenago commented on issue #14619: URL: https://github.com/apache/superset/issues/14619#issuecomment-1922255913
> I assume we could just replace `GLOBAL_ASYNC_QUERIES_REDIS_CONFIG` with an instance of whichever backend the deployment wishes to use (`redis.Redis` for most cases). I don't know if my understanding is 100 percent correct, but in `redis-py` it seems like `Sentinel` is used to discover the current master and acquire a `redis.Redis` session for actual use, e.g. [`master_for`](https://redis-py.readthedocs.io/en/stable/_modules/redis/sentinel.html#Sentinel.master_for). So in a basic scenario, a `redis.Redis` instance acquired that way could be passed as a direct instance in `GLOBAL_ASYNC_QUERIES_REDIS_CONFIG` just like a plain redis connection would, but when a failover occurs that wouldn't leave a mechanism for a new client session to be established in its place. Maybe either an instance of `Sentinel` or `redis.Redis` could be passed through as `GLOBAL_ASYNC_QUERIES_REDIS_CONFIG`, with `AsyncQueryManager` behaving differently based on the type? If a `Sentinel` instance was directly provided as `GLOBAL_ASYNC_QUERIES_REDIS_CONFIG`, then it would subsequently need to acquire a usable `redis.Redis`, but if a `redis.Redis` instance was provided as `GLOBAL_ASYNC_QUERIES_REDIS_CONFIG` then it could be used directly without any extra steps. Later if a communication failure occurs and `AsyncQueryManager` was set up with `Sentinel`, then an attempt could be made to establish a connection with a new master, unlike with bare `redis.Redis`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
