Expected behavior
No exception is thrown
Actual behavior
While running a massively parallelized workload on a fast modern machine, we have noticed a sporadic an connection exception coming from the Jedis initialization code since the migration to version 4.X:
redis.clients.jedis.exceptions.JedisConnectionException: Unknown reply: H
at redis.clients.jedis@4.4.3/redis.clients.jedis.Protocol.process(Protocol.java:140)
at redis.clients.jedis@4.4.3/redis.clients.jedis.Protocol.read(Protocol.java:192)
at redis.clients.jedis@4.4.3/redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:335)
at redis.clients.jedis@4.4.3/redis.clients.jedis.Connection.getMany(Connection.java:347)
at redis.clients.jedis@4.4.3/redis.clients.jedis.Connection.initializeFromClientConfig(Connection.java:415)
at redis.clients.jedis@4.4.3/redis.clients.jedis.Connection.<init>(Connection.java:61)
at redis.clients.jedis@4.4.3/redis.clients.jedis.Jedis.<init>(Jedis.java:214)
at redis.clients.jedis@4.4.3/redis.clients.jedis.JedisFactory.makeObject(JedisFactory.java:178)
at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:571)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:298)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:223)
at redis.clients.jedis@4.4.3/redis.clients.jedis.util.Pool.getResource(Pool.java:38)
at redis.clients.jedis@4.4.3/redis.clients.jedis.JedisPool.getResource(JedisPool.java:378)
at com.telenordigital.tdbase.redis@0.230714.0916/com.telenordigital.tdbase.redis.BaseJedisService.jedis(BaseJedisService.java:57)
at com.telenordigital.tdbase.redis@0.230714.0916/com.telenordigital.tdbase.redis.BaseJedisService.withJedis(BaseJedisService.java:67)
at com.telenordigital.tdbase.redis@0.230714.0916/com.telenordigital.tdbase.redis.BaseJedisService.<init>(BaseJedisService.java:48)
at com.telenordigital.payment.dob.batch@1.0-SNAPSHOT/com.telenordigital.payment.dob.batch.BaseDobBatch.lambda$new$1(BaseDobBatch.java:41)
at java.base/java.util.Optional.map(Optional.java:260)
This exception can indicate a corruption of the input connection stream, as if the number of read operations didn't match the number of writes. So maybe there is something wrong when Jedis sends two 'CLIENT SETINFO' commands in a pipeline expecting for two replies? I cannot quite see it by myself though.
Note that, when I re-run my workload with modified Jedis code without sending those client info commands everything works just fine, i.e. no exception is thrown.
Steps to reproduce:
Unfortunately, I haven't been able to come up with a reproducible test case yet
Redis / Jedis Configuration
a Redis server is running in a docker container on the local host
Jedis version:
4.4.3
Redis version:
7.0
Java version:
20
Expected behavior
No exception is thrown
Actual behavior
While running a massively parallelized workload on a fast modern machine, we have noticed a sporadic an connection exception coming from the Jedis initialization code since the migration to version 4.X:
This exception can indicate a corruption of the input connection stream, as if the number of read operations didn't match the number of writes. So maybe there is something wrong when Jedis sends two 'CLIENT SETINFO' commands in a pipeline expecting for two replies? I cannot quite see it by myself though.
Note that, when I re-run my workload with modified Jedis code without sending those client info commands everything works just fine, i.e. no exception is thrown.
Steps to reproduce:
Unfortunately, I haven't been able to come up with a reproducible test case yet
Redis / Jedis Configuration
a Redis server is running in a docker container on the local host
Jedis version:
4.4.3
Redis version:
7.0
Java version:
20