Tag Archives: Jedis Error

How to Solve Jedis Error: java.lang.ClassCastException: java.lang.Long cannot be cast to [B

Problem description

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] Jedis Error: NoSuchElementException: Timeout waiting for idle object

Project online environment discovery: java.util.nosuchelementexception: timeout waiting for idle object

Cause of the problem: instead of releasing resources in try, it should be handled in finally. Although it is a very basic grammar, it may be wrongly written. When maintaining the old system, we find that there are many potential bugs, so we should take a warning. To release resources in try, every time an exception occurs, a jedis object will not be released, and the available jedis object resources in pool will be less and less, which will eventually lead to java.util.nosuchelementexception: timeout waiting for idle object. This kind of problem is a chronic problem, it takes time to accumulate

Because the request can’t get the free object, the page will appear server 500 error. If the code is added to the loop to get jedis, the server may also be down

try {
jedis = pool.getResource();
// xxx business code
// original code: pool.returnResource(jedis);, should be placed in the finally block, otherwise each time an exception occurs will result in a jedis object not being t
} catch (RuntimeException e) { 
         if(jedis ! = null ) {
                 pool.returnBrokenResource(jedis);
}
} finally{ 
        // Release the resource correctly
         if(jedis ! = null ) {
                pool.returnResource(jedis);
         }
}