Closed mouadk closed 3 years ago
It looks as if you're mixing reactive programming with imperative API calls. Please either consistently use reactive programming or imperative. Mixing these two is almost a guarantee for blocked event loop threads.
yep thanks for pointing it out
Bug Report
Current Behavior
Actually we are seeing a lots of Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out after x minute(s), even if the command turned out to have accomplished its task successfully sometimes.
Increasing the timeout leads to event loop threads being stuck in the TIMED_WAITING (see attached thread dump)
thread dump
Stack trace
```java Command timed out after 1 minute(s) io.lettuce.core.RedisCommandTimeoutException: Command timed out after 1 minute(s) at io.lettuce.core.ExceptionFactory.createTimeoutException(ExceptionFactory.java:51) at io.lettuce.core.LettuceFutures.awaitOrCancel(LettuceFutures.java:114) at io.lettuce.core.FutureSyncInvocationHandler.handleInvocation(FutureSyncInvocationHandler.java:69) at io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80) at com.sun.proxy.$Proxy41.lrange(Unknown Source) ```Environment
Additional context
What is strange is this doesn’t happen when we configure a StreamMessageListenerContainer (used to subscribe to a Redis Stream) with a polling time out of ZERO duration, We have been asking ourself if it’s a bug or we are doing something wrong here.
Note that this strange behaviour happens only in Kubernetes cluster, locally it looks good.
Appreciate if you can help us demystify what is causing this strange behaviour.