Properly handle broken resource

[PedroMPagani]

Currently from what I see one of the best ways to handle broken resources is mainly the testOnBorrow, which basically would execute a ping before returning the resource, but that can be a + on the latency of the call, even tho small, could be avoided?

I'm mainly trying to find the best ways to make sure that the operations would still execute even if it encounters a broken Jedis connection, so far came up with something like:

public void executeProcess(Consumer<Jedis> consumer){
    Jedis jedis = this.pool.getResource();
    try {
       consumer.accept(jedis);
    } finally {
      this.pool.returnResource(jedis);
      return;
    } catch(Exception exception){
      this.pool.returnBrokenResource(jedis);
      executeProcess(consumer);
      return;
    }
  }

Also including a pubsub safety in case the redis server is restarted, all pubsubs would basicaly disconnect, and if the software does not handle it properly it would basically break, does this seems tangeable or something good?

Thread thread = new Thread(()->{
while(true){
 // register pubsub here, if the subscription throws an exception, try to subscribe again?
}
});
thread.setDaemon(true);
thread.start();

Any ideas on hw to improve or how to properly handle the fails and still make sure the op executes?

[sazzad16]

For the first part:

Try UnifiedJedis with RetryableCommandExecutor.

final int maxAttempts = 5;
final Duration maxRetriesDuration = Duration.ofSeconds(2);

PooledConnectionProvider pooledConnectionProvider = new PooledConnectionProvider(hostAndPort, clientConfig);
RetryableCommandExecutor retryableCommandExecutor = new RetryableCommandExecutor(pooledConnectionProvider, maxAttempts, maxRetriesDuration);
UnifiedJedis jedis = new UnifiedJedis(retryableCommandExecutor);

---

For the second part:

Yes, subscribe is not a strength of this library. We welcome any contribution 🙂

[sazzad16]

this also happens in JedisPool

In that case, can't help you further. JedisPool has been here for a quite long time and considered pretty stable.

You may check your jvm, cpu network, etc.
You may check your jvm, cpu, network, etc.

[PedroMPagani]

this also happens in JedisPool

In that case, can't help you further. JedisPool has been here for a quite long time and considered pretty stable.

You may check your jvm, cpu network, etc.

Do you know by any chance what configs in redis side that could cause this? Or this would be 100% because of the JVM, I can tell you I have tcpbacklog at 65k, I have already disabled the transparent pages in the node of the redis, would I have to also disable it in the prod nodes?

[sazzad16]

I don't recall any Jedis/Redis specific issue which causes only the first call to be slow. Sorry 🙁

[PedroMPagani]

I don't recall any Jedis/Redis specific issue which causes only the first call to be slow. Sorry 🙁

I understand, what would I be looking for in the JVM to identify what's causing it?

[sazzad16]

Random weird stuffs, i.e.

• if the behavior is true for other libraries using sockets, specifically synchronous sockets (java.io)
• try a different version
• try a different implementation