Jedis preventing application to close

[mathieucarbou]

Hi,

We are using Jedis for a very large website. When integrating it, we saw an issue with the way Repair threads are used.

if no Redis daemon is available, the following commands block the shutdown of the application:

jedisPool.init()
jedisPool.destroy();

The destroy thread block at:

repairThreads[i].interrupt();
repairThreads[i].join();

in the destroy method. The cause is that the repair threads never stops and thus the join does not finish.

I saw that the repair threads are not stoppable because of the following code in JedisPool.createResource() method:

while (!done) {
    try {
    jedis.connect();
    if (password != null) {
        jedis.auth(password);
    }
    done = true;
    } catch (Exception e) {
        try {
            Thread.sleep(100);
        } catch (InterruptedException e1) {
        }
    }
}

When no Redis daemon is available, the while loop keeps looping and the Interrupted exception is simply ignored.

As you may know, as a library developper, it is really not recommanded to catch Interrupted exception. If it is necessary, you should restore the interrupt status that the exception throwing cleared.

The following code fixes the issue:

try {
    Thread.sleep(100);
} catch (InterruptedException ignored) {
    // The repair thread can be interrupted on shutdown
    Thread.currentThread().interrupt();
    return null;
}

Note that the return null; may be acceptable there since we are in the case where the shutdown method has been called to interrupt the repair threads. So we are exiting the program.

This enables Repair threads to stop and then unblock the program shutdown.

For the moment, a quick hugly fix for those who needs the patch is to override the createResource() method and apply the above patch in it.

Thanks,

Mathieu Carbou
mathieu.carbou@gmail.com

[xetorthio]

Hi Mathieu,
Which version of Jedis are you using?
Also you should know that this pool will be deprecated next version (1.5.0), and will be replaced by the apache generic object pool. You can see the implementation on master.
But your fix is good for any developer using current or older version of Jedis.

Thanks!

[mathieucarbou]

Hi,

We are using the version deployed at http://repo2.maven.org/maven2/redis/clients/jedis/

There is no problem for us for the deprecation: we only have one implementation depending on the core and we will be glad to switch and use a more stable pool when 1.5.0 will be released.

Thanks a lot,

Mathieu.

[xetorthio]

Ok. Great.
The ETA for 1.5.0 is probably a week from now. Just to make sure there are no strange bugs or problems.

Thanks!

[linar-jether]

Seems that this is still an issue, solved by this commit of commons-pool: https://github.com/apache/commons-pool/pull/20/files

The eviction timer should be a daemon thread.