"Unknown reply" exception. about jedis

[xetorthio]

This usually happens when you share Jedis instances among different threads.
Please make sure you are not doing that. If you need to do that, use JedisPool.

[viulian]

Thanks for the reply, I do use the pool.
For each service method invocation:

public void savePost(Post post) {
    Jedis conn = getPool().getResource();
    try {
    ....
    } finally {
        if (conn != null) {
            getPool().returnResource(conn);
        }
    }
}

The getPool method:

private JedisPool getPool() {
    if (pool == null) {
        pool = new JedisPool(server, port);
        pool.init();
    }

    return pool;
}

I'm not using Spring for services, but a JSF bean with Application scope.
I am using hot deploy in Tomcat (from Netbeans IDE) and at around the moment of the exception there were some redeploys before / after, since I was changing behavior of the request beans.

But the pool behavior is there from the beginning, I read about it in the wiki and applied it :)

[xetorthio]

Great! Can you write a small test that reproduces this? Maybe a connection is not used for some time and redis is closing it? I have the feeling it might be that. But a tests that reproduces this would be great!

[johanhaleby]

I also experience a similar error (Jedis 1.3.1) but it doesn't seem to be deterministic so it's hard to write tests that demonstrates it. I get: "redis.clients.jedis.JedisException: Unknown reply: P" and "redis.clients.jedis.JedisException: Unknown reply: ^@".
E.g.
redis.clients.jedis.JedisException: Unknown reply: P
at redis.clients.jedis.Protocol.process(Protocol.java:65)
at redis.clients.jedis.Protocol.read(Protocol.java:116)
at redis.clients.jedis.Connection.getIntegerReply(Connection.java:131)
at redis.clients.jedis.Jedis.hexists(Jedis.java:787)

I'm also using the JedisPool to get a Jedis instance before each invocation.

[xetorthio]

This happens because Redis by default closes idle connections after 300 seconds and the pool is not checking connections in the ready queue.
You should use Jedis 1.5.0 RC2 which uses the apache pool instead and you can tell that pool to test on borrow, which will ensure that the connection is up and running.

[johanhaleby]

Thanks for your reply. Would you recommend using 1.5.0 RC2 in a business critical system or would you rather advice me to wait until the final 1.5.0 release?

[xetorthio]

It is in maven central already.
Final 1.5.0 will be released Friday. There won't be many changes. Lots of the big changes were pushed to 1.6.0, so I would say you can go ahead and use it. Or you can wait until Friday for the final 1.5.0. :)

[xetorthio]

This issue has been handled before using testOnBorrow
So I'm closing this since there is a solution. You'll find information on this in:
https://github.com/xetorthio/jedis/wiki
under "Using Jedis in a multithreaded environment"