When accessing redis using jedis SDK, the following exceptions are thrown sometimes
java.lang.ClassCastException: java.lang.Long cannot be cast to [B at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:259) at redis.clients.jedis.Connection.getBulkReply(Connection.java:248) at redis.clients.jedis.Jedis.hget(Jedis.java:674)
Sometimes it may be accompanied by timeout exceptions:
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out at redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202) at redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40) at redis.clients.jedis.Protocol.process(Protocol.java:151) at redis.clients.jedis.Protocol.read(Protocol.java:215) at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340) at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:259) at redis.clients.jedis.Connection.getBulkReply(Connection.java:248) at redis.clients.jedis.Jedis.hget(Jedis.java:674)
Reason & Solution:
There are three main reasons:
A jedis connection is returned to the connection pool after throwing an exception (such as timeout exception) when it is in use. This connection may run similar exceptions when it is used next time. Specifically, it is related to the last data requested by the Sockt buffer. Refer to link 1.
In this case, you need to close the jedis correctly. Some articles may say that you need to call the returnbrokenresource method, which is an ancient method. At least above 2.9.0, you can close it directly. If an exception is caught, you need to close it in finally.
Multithreading access to jedis objects
According to jedis documentation, jedispool is thread safe and jedis is non thread safe. Check whether the code has multithreaded logic.
Redis cluster resources are heavily loaded and full
This is why I read redis first and then write it. I keep throwing this exception. If the comments are written out, read-only operation is OK. After the comment is read out, the following exceptions are thrown. This kind of load re throwing exception is also mentioned in the issue of link 2.
redis.clients.jedis.exceptions.JedisDataException: ERR at redis.clients.jedis.Protocol.processError(Protocol.java:127) at redis.clients.jedis.Protocol.process(Protocol.java:161) at redis.clients.jedis.Protocol.read(Protocol.java:215) at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340) at redis.clients.jedis.Connection.getOne(Connection.java:322) at redis.clients.jedis.ShardedJedisPipeline.sync(ShardedJedisPipeline.java:44)
Finally, I applied to the operation and maintenance department for a new redis, which can be read and written normally. If you maintain your own redis, check the log.
- [Solved] Redis Operation exception: java.lang.ClassCastException: java.lang.Long cannot be cast to [B
- Redis uses connection pool to solve the problem of error reporting
- [How to Solve] Caused by: java.net.SocketTimeoutException: connect timed out
- [Solved] Redis has java.net.socketexception: permission denied: connect problem during stress test
- [Solved] Jedis Error: NoSuchElementException: Timeout waiting for idle object
- [Solved] SpringBoot Access Redis Error: java.lang.NoSuchMethodError: redis.clients.jedis.JedisPoolConfig.setMinEvictableIdleTime
- [Solved] Jedis:Exception in thread “main” java.lang.VerifyError: Bad type on operand stack
- [Solved] increment Error: ERR value is not an integer or out of range
- How to Solve Error: Scanner class java. Util. NoSuchElementException exception
- Stackexchange.redis timeout performing timeout problem