How to handle JedisDataExceptions that have connection timeout?

[Rintcius Blok]

Hi,

We are encountering some JedisDataExceptions in our PROD env. with this message: redis.clients.jedis.exceptions.JedisDataException: ERR Connection timed out

As per the advice given at http://stackoverflow.com/questions/17082163/jedis-when-to-use-returnbrokenresource we do a returnBrokenResource in case of JedisConnectionException and a returnResource for other exceptions. 

Looking at the message of this JedisDataException though, this particular exception looks like a JedisConnectionException in diguise.

Is it correct to returnResource here or should we use returnBrokenResource?

Thanks,

Rintcius

(BTW I posted a question like this yesterday, but it didn't come through it seems. My apologies if it did come through and this is a duplicate)

[임정택]

Hello!

Can you describe what Redis & Jedis version & commands do you use?

(Sample code is very appreciated!)

Btw, I'm trying to find relevant message from Redis unstable (09dec3613e7af60a084704eb2e80c5cf4ecd1b09),

but Redis handles timeout to disconnect client, so Redis would not send ERR message, just lead Socket Exception.

(JedisConnectionException should follow, so it's normal situation.)

One exception is connection timeout with blpop, but Redis would send null reply, not ERR.

So I think it's strange message in recent Redis's point of view.

I would miss a spot, so I'll check agin when you explain Redis version.

Thanks!

2014년 2월 28일 금요일 오후 6시 20분 22초 UTC+9, Rintcius Blok 님의 말:

[Rintcius Blok]

Hi,

Sure, see below for the extra information.

Just let me know if you need more.

Thanks!

Rintcius

redis version: 2.6.16

jedis version: 2.1.0

Example code (simplified):

import redis.clients.jedis.Jedis;

import redis.clients.jedis.JedisPool;

import redis.clients.jedis.Pipeline;

import redis.clients.jedis.Response;

public class Example {

    public static void test() {

        JedisPool pool = new JedisPool("localhost");

        Jedis jedis = pool.getResource();

        Pipeline pipeline = jedis.pipelined();

        String key = "somekey";

        Response<Long> response = pipeline.hset(key, "somefield", "somevalue");

        pipeline.expire(key, 3600);

        pipeline.sync();

        System.out.println(response.get());

    }

}

[임정택]

Hello,

Maybe your example is too simplified to reproduce.

Can you make example able to reproduce?

Btw, I skimmed to Redis 2.6.16 and found nothing with sending "Connection timed out".

Jedis just treat "ERR xxxxx" to JedisDataException, so it could make sense in point of view of Jedis.

But Redis doesn't make sense. Redis would close connection immediately as @antirez would think it should make sense.

(See https://github.com/antirez/redis/pull/1567#issuecomment-36497940 for steal a glance at)

Also, your Jedis client is so much outdated. (over 2 years ago!)

We are preparing to release 2.4.3.

(or 2.4.2. Jonathan said 2.4.3 will be released but 2.4.2 had not been released.)

Please follow up with recent Jedis client to follow up your problem easily.

Thanks!

Sincerely.

Jungtaek Lim (HeartSaVioR)

2014년 3월 4일 화요일 오전 5시 4분 11초 UTC+9, Rintcius Blok 님의 말:

[Rintcius Blok]

Hi,

I tried a bit more to reproduce it. I still haven't reproduce it exactly, but found something interesting. 

In the case of where our problem occurred I reminded that we are using twemproxy (sorry that I didn't think of it before).

Now, if I stop the redis-server and run the code that I supplied earlier via twemproxy I am getting:

Caused by: redis.clients.jedis.exceptions.JedisDataException: ERR Connection refused

at redis.clients.jedis.Protocol.processError(Protocol.java:59)

at redis.clients.jedis.Protocol.process(Protocol.java:66)

at redis.clients.jedis.Protocol.read(Protocol.java:131)

at redis.clients.jedis.Connection.getAll(Connection.java:225)

at redis.clients.jedis.Connection.getAll(Connection.java:217)

at redis.clients.jedis.Pipeline.sync(Pipeline.java:68)

So I guess it's twemproxy as well that gives the timeout message. 

Hopefully that gives enough information. If not just let me know.

Regards, Rintcius

[Jonathan Leibiusky]

That is actually very important piece of information. I will download twemproxy source code to check hoe it handles timeouts.
Seems like it throws an error using redis protocol and maybe it is doing something wrong

--
You received this message because you are subscribed to the Google Groups "Jedis" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jedis_redis...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[임정택]

Oh my... Twemproxy seems to do it.

https://github.com/twitter/twemproxy/blob/master/notes/recommendation.md

Twemproxy does handle error between Client and Twemproxy, and send error message like target (Memcached or Redis).

That means there're more error messages from Twemproxy, and it would be more than now.

It's easy to use and maintain Twemproxy (handle memcached and Redis).

But I think it's wrong because Twemproxy is proxy.

It should be transparent to interact with Redis, so Twemproxy should respect Redis's error handling strategy.

Thanks!

Regards.

Jungtaek Lim (HeartSaVioR)

2014년 3월 8일 토요일 오전 3시 43분 15초 UTC+9, Jonathan L. 님의 말: