How to resolve Redis timeout exception —redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out

How I fixed the "read timed out" error in my Amazon Elasticache configuration.

I encountered this exception while implementing my cache using AWS Elasticache:

java.net.SocketTimeoutException: Read timed out; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out

Details of my development environment:


Java version: 8
jedis version: 2.9.3
spring-data-redis version: 2.0.14.RELEASE

After some debugging, I found this issue was encountered when I was trying to get all keys from the cache to eventually, delete them one by one.

....
redisTemplate.opsForHash().keys(REDIS_CACHE_NAME)
....

I tried increasing the connection timeout for the cache to 60 seconds, but still, it did not help. This was a bit confusing since getting all keys from the cache should not take that long.

After a lot of googling and experimenting, I found that upgrading my Redis and Jedis versions would resolve this issue because this was a reoccurring problem in earlier versions of Jedis and they have resolved the bug.

But for this upgrade, a spring version upgrade was also required for my project, which was a lot of effort due to some internal frameworks being used for the project.

Ultimately, the solution that resolved this issue for me was: throwing more money at the problem.

I discovered the data I was storing in my cache was quite large, and since this exception was thrown every time I tried to clear my cache, I might have been running into memory issues. This was validated by another exception I was seeing in the logs:

Exception in thread "Thread-228" redis.clients.jedis.exceptions.JedisDataException: OOM command not allowed when used memory > 'maxmemory'.

Since I was using AWS Elasticache, I tried to upgrade the node_type of my cache from t2.micro (0.555 GiB) to m6g.large (6.38 GiB) (which costs around $0.149/hr).

This seems to have solved the issue because I haven't encountered the same exception again.