redisson: Version 3.16.3: RedisTimeoutException: Command execution timeout for command: (PING)

After switching to version 3.16.3, I see tons of next exceptions:

org.redisson.client.handler.PingConnectionHandler : Unable to send PING command over channel: [id: 0x76185fba, L:/127.0.0.1:59095 - R:localhost/127.0.0.1:6379]

 org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://localhost:6379]
	at org.redisson.client.RedisConnection.lambda$async$1(RedisConnection.java:255)
	at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:669)
	at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:744)
	at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:469)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:829)

And I don’t see the same in v3.16.2.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (8 by maintainers)

Commits related to this issue

Most upvoted comments

Hello, We also face this issue with following complete error and stacktrace :

Unable to send PING command over channel:

org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: 
[addr=redis://XXX:YYY] 	at org.redisson.client.RedisConnection.lambda$async$0(RedisConnection.java:245) 	at 
io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:669) 	at 
io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:744) 	at 
io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:469) 	at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) 	at 
java.base/java.lang.Thread.run(Thread.java:832)


We are mainly using Queues, locks and MapCache. We are observing this error starts occurring and then our service is producing more and more error logs like the one provided. Is this commit supposed to fix our use case ? Did someone bypassed this issue with specific configuration ? As far as I can see, it’s supposed to be shipped in 3.16.9, but do you have and ETA for that version to be released ?

Than you for your support.