HY-love-sleep opened a new issue, #7156: URL: https://github.com/apache/shenyu/issues/7156
### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior `org.apache.shenyu.infra.redis.RedisConnectionFactory` wraps a `LettuceConnectionFactory`: its constructor builds it and calls `afterPropertiesSet()`, which opens the connection pool and its threads, but the class only exposes `getLettuceConnectionFactory()` — there is no `destroy()`, or any other lifecycle end. Every site that rebuilds its client after a config change therefore drops the previous client without shutting it down: | site | what happens | | --- | --- | | `AiTokenLimiterPluginHandler:65` | `new RedisConnectionFactory(...)` when the config differs, then the cached `ShenyuReactiveRedisTemplate` is replaced and the old one is only dropped | | `RateLimiterPluginDataHandler:58` | same | | `SensitiveWordPluginDataHandler` | same (added with #7153, where the review already noted the missing `destroy()`) | Changing the redis configuration N times leaves N live `LettuceConnectionFactory` instances — each with its own shared connection pool and event-loop threads — inside the gateway. The pattern of releasing the previous client already exists in the code base: `CachePluginDataHandler` calls `lastCache.close()` before it replaces the cache. It just cannot be applied to a redis client, because the factory has no lifecycle end to call. The same gap is visible in `RedisCache.close()`, which closes a connection rather than the factory, so the pool itself is only released if it happens to be garbage collected. ### Expected Behavior `RedisConnectionFactory` should expose a lifecycle end, for example a `destroy()` that delegates to `LettuceConnectionFactory.destroy()` (the lettuce factory already implements `DisposableBean`), and the handlers that replace a client should call it on the instance they are about to drop. ### Steps To Reproduce 1. Start the gateway and enable the `aiTokenLimiter` (or `rateLimiter`) plugin with a redis config. 2. Change its `url` (or `password` / `database`), save, and repeat a few times. 3. Take a thread dump: every change left another connection pool alive. ### Anything else? I would like to work on this one, @Aias00 — could you assign the issue to me? The plan is small and does not change any behaviour: add the lifecycle end to `shenyu-infra-redis`, call it at the sites above that replace a client, and test that a replaced factory is destroyed while an unchanged configuration is not rebuilt. -- 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]
