All Products
Search
Document Center

Summary of common Jedis exceptions

Last Updated: Dec 15, 2020

Introduction

Jedis is simple to use. However, if you cannot set valid parameters such as jedispool parameters that are suitable for your scenarios and if you use some features such as Lua and transactions in an incorrect way, some issues may occur. This topic describes how to solve these issues.

Background

1. Failure to obtain Jedis connections from jedispool

Exception stack

  • If the blockWhenExhausted connection pool parameter is set to true (default value), the system waits for a period of time, depending on the maxWaitMillis parameter. If no Jedis connection is available in jedispool, the following exception occurs.
    redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
    ...
    Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
      at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)
  • When blockWhenExhausted jedispool parameter is set to false, the following exception occurs immediately if no Jedis connection is available in jedispool.
    redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
    ...
    Caused by: java.util.NoSuchElementException: Pool exhausted
      at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:464)

Possible cause

The above exception is caused by the client not getting available Jedis connections from the connection pool, the maximum number of Jedis resources is determined by the value of maxTotal, there may be several reasons.

Connection leaks

The default maxTotal value of JedisPool is 8. The following code shows that eight Jedis resources are retrieved from JedisPool but no resources are returned. Therefore, when the ninth attempt is to obtain the Jedis resource, the jedisPool.getResource().ping() cannot be called.

GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); JedisPool jedisPool = new JedisPool(poolConfig, "127.0.0.1", 6379); // The client borrowed eight connections from JedisPool, but did not return the resource. for (int i = 0; i < 8; i++) {     Jedis jedis = null;     try {         jedis = jedisPool.getResource();         jedis.ping();     } catch (Exception e) {         logger.error(e.getMessage(), e);     } } jedisPool.getResource().ping();

We recommend that you use the following code.

Jedis jedis = null; try { jedis = jedisPool.getResource(); // run jedis.exe cuteCommand() } catch (Exception e) { // if the command contains a key, we recommend that you print the key in the error log. For the cluster edition, you can use the key to find the target node.     logger.error(e.getMessage(), e); } finally { // It is not used to close the connection. In JedisPool mode, the Jedis resource will be returned to the resource pool.     if (jedis ! = null)          jedis.close(); }
High concurrency (the value of maxTotal is too small)

Example of exceptions caused by high concurrency: the average time consumed by one command (borrow | return resource + Jedis command execution + network time) is about 1ms, the QPS of a connection is about 1000. The required QPS is 50,000. Theoretically, the required resource pool size is 50000 divided by 1000 and 50. Therefore, you need to fine-tune the maxTotal value according to the actual situation.

Jedis connection blocking

For example, connections to Redis are blocked in the conditions such as slow query. All connections wait for a period less than the timeout value. In this case, a high concurrency level can result in insufficient resources in jedispool.

Jedis connection denied

When the client attempts to obtain a connection from jedispool, jedispool has to generate a connection due to the lack of idle connections. However, the new connection is denied, as shown in the following code:

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool     at redis.clients.util.Pool.getResource(Pool.java:50)     at redis.clients.jedis.JedisPool.getResource(JedisPool.java:99)     at TestAdmin.main(TestAdmin.java:14) Caused by: redis.clients.jedis.exceptions.JedisConnectionException: java.net.ConnectException: Connection refused     at redis.clients.jedis.Connection.connect(Connection.java:164)     at redis.clients.jedis.BinaryClient.connect(BinaryClient.java:80)     at redis.clients.jedis.BinaryJedis.connect(BinaryJedis.java:1676)     at redis.clients.jedis.JedisFactory.makeObject(JedisFactory.java:87)     at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:861)     at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:435)     at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)     at redis.clients.util.Pool.getResource(Pool.java:48)     ... 2 more Caused by: java.net.ConnectException: Connection refused     at java.net.PlainSocketImpl.socketConnect(Native Method)     at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)     at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)     at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)     at java.net.Socket.connect(Socket.java:579)     at redis.clients.jedis.Connection.connect(Connection.java:158)     ... 9 more

We can see from the at function that it is actually a Socket connection.

 socket.setSoLinger(true, 0); // Control calls close () method,         // the underlying socket is closed         // immediately         // <-@wjw_add 158:  socket.connect(new InetSocketAddress(host, port), connectionTimeout);

Tips: In this case, you must check whether the domain name configuration for Redis is correct and whether the network is normal during this period.

Other FAQ

For packet loss, DNS, and client TCP parameter configuration, you can open a ticket for help.

Fixes

Based on the preceding analysis, the causes of the failure to obtain connections from jedispool are complex. If you want to provide sufficient resources in jedispool, increasing the value of maxTotal is not the only solution. The solution varies according to actual conditions.

2. Client buffer exception

Exception stack

The exception stack is as follows.

redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream. at redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:199) at redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40) at redis.clients.jedis.Protocol.process(Protocol.java:151) ......

Possible cause

This client buffer exception may occur due to the following causes:

Multiple threads use one Jedis connection.

Normally, a thread uses a Jedis connection. You can use JedisPool to manage Jedis connections to ensure thread security and avoid this situation. The following example shows that two threads share one Jedis connection:

new Thread(new Runnable() {
    public void run() {
        for (int i = 0; i < 100; i++) {
            jedis.get("hello");
        }
    }
}).start();
new Thread(new Runnable() {
    public void run() {
        for (int i = 0; i < 100; i++) {
            jedis.hget("haskey", "f");
        }
    }
}).start();
The client buffer is full.

Apsaradb for Redis provides three types of client buffers:

  • Normal client buffer: receives normal commands, such as GET, SET, MSET, HGETALL, and ZRANGE.
  • Replica client buffer: synchronizes write commands from a master node during replications.
  • PUBSUB buffer: the PUBSUB command is not a normal command, so the command has an independent buffer.

You can configure the client buffer for apsaradb for Redis in the following way:

client-output-buffer-limit [$Class] [$Hard_Limit] [$Soft_Limit] [$Soft_Seconds]
  • Class: specifies the type of the client. Valid values: normal, slave, and pubsub.
  • hard limit: If a client uses the output buffer that is more than the value of hard limit, the system terminates the client immediately. Unit: seconds.
  • [$Soft_Limit] and [$Soft_Seconds]: if a client uses an output buffer that exceeds the soft limit and lasts for seconds, the client is immediately shut down, in seconds.

The following example shows the buffer configuration for apsaradb for Redis. In the specified condition, the system terminates the client immediately and shows the Unexpected end of stream error.

redis> config get client-output-buffer-limit
1) "client-output-buffer-limit"
2) "normal 524288000 0 0 slave 2147483648 536870912 480 pubsub 33554432 8388608 60"
Idle connection for a long time

(3) the Redis service automatically disconnects a long idle connection. You can check the timeout setting and jedispool configuration to determine whether the idle connection detection is required.

Solutions and approaches

  • Check the code of your service to make sure that you use JedisPool to manage Jedis connections and check whether multiple threads share one Jedis connection.
  • Check whether the cause is that the client buffer is full or idle for long periods of time. The value of timeout in apsaradb for Redis is 0 by default. You cannot modify this value. The default value of client-output-buffer-limit is 500mb, which is a reasonable value after Alibaba cloud optimization. If the value of the parameter is more than 64 MB, the client returns too many values. In this case, to ensure performance and stability of the service, we recommend that you optimize the application.

3. Invalid client address

Tips: Alibaba Cloud Redis provides the client whitelist function.

Exception stack

The exception stack is as follows.

Caused by: redis.clients.jedis.exceptions.JedisDataException: ERR illegal address
    at redis.clients.jedis.Protocol.processError(Protocol.java:117)
    at redis.clients.jedis.Protocol.process(Protocol.java:151)
    at redis.clients.jedis.Protocol.read(Protocol.java:205)
  ......

When you add a member to the collection, for example, using the settest#helloworld" command, the following error may also be caused by a whitelist issue.

Error: Insert the diskette for drive %1.

Possible cause

The ApsaraDB for Redis instance has a whitelist of clients configured. The IP address of the current client that connects to the instance does not exist in the whitelist.

Fixes

Add the whitelist of the client (IP). For more information about how to add a whitelist, see set IP whitelist.

4. Maximum number of client connections

Exception stack

The exception stack is as follows.

redis.clients.jedis.exceptions.JedisDataException: ERR max number of clients reached

Possible cause

The number of client connections is more than the value of maxclients configured on an ApsaraDB for Redis instance.

Fixes

  • Submit a ticket to contact Alibaba Cloud technical support personnel to temporarily adjust the maximum number of connections to help locate the problem.
  • To locate your own problem, you can locate the client with the most connections, find the cause of the problem, such as the connection pool configuration, and then handle it.

Drawback 5: client read /write timeout

Exception stack

redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out

Possible cause

There may be several causes of the problem.

  • The value of the read /write timeout parameter is too short.
  • Slow query or connection blocking occurs.
  • The network is unstable.

Fixes

The user provides the read and write timeout. Submit a ticket to identify the cause and resolve the issue.

6. Password-related exceptions

Exception stack

  • Apsaradb for Redis has password verification configured. But a client does not provide any password in a request as shown in the following code:
    Exception in thread "main" redis.clients.jedis.exceptions.JedisDataException: NOAUTH Authentication required.
       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)
  • Apsaradb for Redis does not have password verification configured. But a client provides a password in a request as shown in the following code:
    Exception in thread "main" redis.clients.jedis.exceptions.JedisDataException: ERR Client sent AUTH, but no password is set
       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)
  • The client transmitted an incorrect password.
    redis.clients.jedis.exceptions.JedisDataException: ERR invalid password
      at redis.clients.jedis.Protocol.processError(Protocol.java:117)
      at redis.clients.jedis.Protocol.process(Protocol.java:151)
      at redis.clients.jedis.Protocol.read(Protocol.java:205)

Fixes

Check whether password authentication is set and whether the correct password is provided.

7. Abnormal transaction

Exception stack

The exception stack is as follows.

redis.clients.jedis.exceptions.JedisDataException: EXECABORT Transaction discarded because of previous errors

Possible cause

This is a transaction exception in apsaradb for Redis. The transaction contains an incorrect command, such as the unknown sett command.

127.0.0.1:6379> multi
OK
127.0.0.1:6379> sett key world
(error) ERR unknown command 'sett'
127.0.0.1:6379> incr counter
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.

Fixes

Check your code logic and fix code errors.

Problem 8: Class conversion error

Exception stack

The exception stack is as follows.

java.lang.ClassCastException: java.lang.Long cannot be cast to java.util.List
         at redis.clients.jedis.Connection.getBinaryMultiBulkReply(Connection.java:199)
         at redis.clients.jedis.Jedis.hgetAll(Jedis.java:851)
       at redis.clients.jedis.ShardedJedis.hgetAll(ShardedJedis.java:198)
java.lang.ClassCastException: java.util.ArrayList cannot be cast to [B
         at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:182)
         at redis.clients.jedis.Connection.getBulkReply(Connection.java:171)
         at redis.clients.jedis.Jedis.rpop(Jedis.java:1109)
         at redis.clients.jedis.ShardedJedis.rpop(ShardedJedis.java:258)
.......

Possible cause

Normally, one thread uses one Jedis connection. If multiple threads share the same Jedis connection, this exception occurs. You can use JedisPool to avoid this exception. The following example shows that two threads use the same Jedis connection. The get and hgetAll commands return different data types.

new Thread(new Runnable() {
    public void run() {
        for (int i = 0; i < 100; i++) {
            jedis.set("hello", "world");
            jedis.get("hello");
        }
    }
}).start();
new Thread(new Runnable() {
    public void run() {
        for (int i = 0; i < 100; i++) {
            jedis.hset("hashkey", "f", "v");
            jedis.hgetAll("hashkey");
        }
    }
}).start();

Solutions and approaches

Check the code.

Question 9: incorrect command usage

Exception stack

The exception stack is as follows.

Exception in thread "main" redis.clients.jedis.exceptions.JedisDataException: WRONGTYPE Operation against a key holding the wrong kind of value
    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)
.....

Possible cause

For example, the error occurs because key=''hello'' is a string key but the hgetAll command returns a hash key.

jedis.set("hello","world");
jedis.hgetAll("hello");

Solutions and approaches

The error message returned because an error has occurred while modifying the code.

10. Memory usage of apsaradb for Redis is more than the value of maxmemory

Exception stack

The memory usage of a node of ApsaraDB for Redis is more than the value of maxmemory on the instance. The exception stack is as follows.

redis.clients.jedis.exceptions.JedisDataException: OOM command not allowed when used memory > 'maxmemory'.

Possible cause

There may be several reasons.

  • Service data increases normally.
  • The client buffer is abnormal, such as monitor and pub/sub are not used properly.
  • In cache-only scenarios, the maxmemory-policy is configured in an incorrect way. For example, the volatile-lru is not configured for expired keys.

Fixes

  1. Check the reason for the increase in memory and solve the problem based on the service scenario.
  2. In case of emergency handling, you can temporarily adjust maxmeory, and then ask if you need to upgrade or adjust the configuration.

11. Apsaradb for Redis is loading persistence files

Exception stack

The exception stack is as follows.

redis.clients.jedis.exceptions.JedisDataException: LOADING Redis is loading the dataset in memory

Possible cause

When a Jedis client tries to connect to an ApsaraDB for Redis instance, the instance is loading persistence files and cannot normally process read and write requests.

Fixes

Normally, this situation does not occur for the Alibaba Cloud Redis. If this occurs, open a ticket.

12. Lua script timeout

Exception stack

The exception stack is as follows.

redis.clients.jedis.exceptions.JedisDataException: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.

Possible cause

An ApsaraDB for Redis instance is running a Lua script for a period of time that is more than the value of LUA-time-limit. In this case, if a Jedis client tries to connect to the instance, the preceding exception occurs.

Fixes

Follow the exception prompt You can only call SCRIPT KILL or SHUTDOWN nosave.com, and run the kill command to terminate the Lua SCRIPT.

Question 13: connection timeout

Exception stack

redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: connect timed out

Cause

There are several possible reasons.

  • The connection timeout value is too low.
  • The value of tcp-backlog reaches the upper limit. This fails the new connection.
  • Network failures occur between the client and the service.

Fixes

The user provides the connection timeout and submits a ticket to locate the relevant reason.

Question 14: Lua script write times out

Exception stack

The exception stack is as follows.

(error) UNKILLABLE Sorry the script already executed write commands against the dataset. You can either wait the script termination or kill the server in a hard way using the SHUTDOWN NOSAVE command.

Possible cause

An apsaradb for Redis instance is running a Lua script for more than lua-time-limit and has run a write command. In this case, if a Jedis client tries to connect to the instance, the preceding exception occurs.

Fixes

Submits a ticket for Emergency Handling. The administrator needs to restart or switch Redis nodes.

Question 15: class loading error

Exception stack

The exception stack for classes and methods cannot be found as follows.

Exception in thread "commons-pool-EvictionTimer" java.lang.NoClassDefFoundError: redis/clients/util/IOUtils
    at redis.clients.jedis.Connection.disconnect(Connection.java:226)
    at redis.clients.jedis.BinaryClient.disconnect(BinaryClient.java:941)
    at redis.clients.jedis.BinaryJedis.disconnect(BinaryJedis.java:1771)
    at redis.clients.jedis.JedisFactory.destroyObject(JedisFactory.java:91)
    at         org.apache.commons.pool2.impl.GenericObjectPool.destroy(GenericObjectPool.java:897)
    at org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:793)
    at org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1036)
    at java.util.TimerThread.mainLoop(Timer.java:555)
    at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.ClassNotFoundException: redis.clients.util.IOUtils
......

Possible cause

A Jedis client throws an exception to indicate that the target class is not available when running the required command. This type of problem is generally due to loading multiple jedis versions (such as jedis 2.9.0 and jedis 2.6), and there is no problem with the code during compilation, however, the class loader loads an earlier version of Jedis at runtime, causing no class to be found at runtime.

Fixes

You can exclude repeated Jedis code to solve this issue. For example, use the Maven dependency tree to remove or exclude useless dependencies.

Issue 16: server commands are not supported

Exception stack

The following example shows that a client runs the GEOADD command, but the ApsaraDB for Redis service indicates that the command is unknown in the response.

redis.clients.jedis.exceptions.JedisDataException: ERR unknown command 'GEOADD'

Possible cause

This command is not recognized by the apsaradb for Redis client due to the following reasons:

  • Apsaradb for Redis does not support some Redis commands, or only some minor versions of apsaradb for Redis support these Redis commands. For example, the geoadd command is Redis 3.2 to add the Geo API.
  • The command is incorrect. The Jedis client does not support the commands that you combine directly. Instead, each API calls a required function.

Fixes

You can ask the administrator to check whether any ApsaraDB for Redis edition supports the required command. If so, you can upgrade to the target minor version.

Question 17: incorrect use of pipeline

Exception stack

The exception stack is as follows.

redis.clients.jedis.exceptions.JedisDataException: Please close pipeline or multi block before calling this method.

Possible cause

  • In pipeline.sync() prior to execution by response.get() fetch values in pipeline.sync() before execution command not implemented (can monitor do the authentication), the following code will trigger all of the above an exception
    Jedis jedis = new Jedis("127.0.0.1", 6379);
    Pipeline pipeline = jedis.pipelined();
    pipeline.set("hello", "world");
    pipeline.set("java", "jedis");
    Response<String> pipeString = pipeline.get("java");
    //The GET command must follow the SYNC command. To obtain multiple values, we recommend that you use List<Object> objectList = pipeline.syncAndReturnAll();
    System.out.println(pipeString.get());
    //The command takes effect.
    pipeline.sync();
  • The set field in the response is initialized as false. When the Jedis client obtains the analysis response, if the response parameter is set to set=false, the following response is returned:
    public T get() {
    // if response has dependency response and dependency is not built,
    // build it first and no more!!
    if (dependency ! = null && dependency.set && ! dependency.built) {
      dependency.build();
    }
    if (! set) {
      throw new JedisDataException(
          "Please close pipeline or multi block before calling this method.") ;
    }
    if (! built) {
      build();
    }
    if (exception ! = null) {
      throw exception;
    }
    return response;
    }
  • The pipeline.sync () code sets set=true in each result, as shown below.
    public void sync() {
    if (getPipelinedResponseLength() > 0) {
      List<Object> unformatted = client.getAll();
      for (Object o : unformatted) {
        generateResponse(o);
      }
    }
    }
  • The following is the code for generateresponse (o):
    protected Response<? > generateResponse(Object data) {
    Response<? > response = pipelinedResponses.poll();
    if (response ! = null) {
      response.set(data);
    }
    return response;
    }
  • The code for response.set(data) is as follows:
    public void set(Object data) {
      this.data = data;
      set = true;
    }

Fixes

For volume as a result of the resolution, it is recommended that you use a pipeline.syncandreturnall() implemented following manipulation simulates the batch hgetall.

/**
* The pipeline simulates running the HGETALL command for multiple times.
* @param keyList
* @return
*/
public Map<String, Map<String, String>> mHgetAll(List<String> keyList) {
// 1. Generate the pipeline object.
Pipeline pipeline = jedis.pipelined();
// 2. The pipeline runs the command. The command does not take effect at the moment.
for (String key : keyList) {
  pipeline.hgetAll(key);
}
// 3. The Jedis client runs the command. The syncAndReturnAll() method returns the result.
List<Object> objectList = pipeline.syncAndReturnAll();
if (objectList == null || objectList.isEmpty()) {
  return Collections.emptyMap();
}
// 4. Parse the result.
Map<String,Map<String, String>> resultMap = new HashMap<String, Map<String,String>>();
for (int i = 0; i < objectList.size(); i++) {
  Object object = objectList.get(i);
  Map<String, String> map = (Map<String, String>) object;
  String key = keyList.get(i);
  resultMap.put(key, map);
}
return resultMap;
}

Processing Approach

Check and modify the business code.

Question 18: The administrator's command common user cannot be executed.

Exception stack

A common user cannot run the ROLE command. For more information, see Supported Redis commands.

redis.clients.jedis.exceptions.JedisDataException: ERR command role not support for normal user

Possible cause

The required command is not available.

Fixes

The error message returned because the specified command is not supported. If you need to use the command or ask questions, submit a ticket.

Other FAQ

How do I select a Jedis version?

In principle, you can select the latest release. However, we recommend that you select a version that has been released for a certain period. A serious issue occurred in an earlier Jedis version during the release history. Jedis 2.9.0 is a stable version so far.

<dependency>
    <groupId>redis.clients
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
    <type>jar</type>
    <scope>compile</scope>
</dependency>

2. Is JedisCluster in Jedis is the client of the apsaradb for Redis cluster edition?

Not the Ali Cloud Redis cluster version of the client, use the Ali Cloud cluster version of the client, directly use Jedis and JedisPool. The Redis cluster and the apsaradb for Redis cluster run in different architectures. For more information, see comparative analysis of Redis 4.0, codis, and ApsaraDB for Redis clusters.

JedisPool parameters

Configure and use resources

The following table lists the resource settings and usage.

No. Parameter Description Default value Recommendations
1 maxTotal The maximum number of connections in the JedisPool. 8 -
2 maxIdle The maximum number of idle connections in JedisPool. 8 -
3 minIdle The minimum number of idle connections in JedisPool. 0 -
4 blockWhenExhausted Specifies whether the client must wait when the resource pool is exhausted. The maxWaitMillis parameter takes effect only when the blockWhenExhausted parameter is set to true. true We recommend that you use the default value.
5 maxWaitMillis Specifies the maximum time for the client to wait for the connection when no resource is available in JedisPool. Unit: milliseconds. -1: specifies no timeout. We recommend that you do not use the default value.
6 testOnBorrow Specifies whether to use the Ping command to check the connection validity when a client borrows a connection from JedisPool. If the connection is invalid, JedisPool removes the connection. false We recommend that you set the parameter to false when handling large data volumes. If you set the parameter to true, the system runs the ping command once more.
7 testOnReturn Specifies whether to use the Ping command to check the connection validity when a client returns a borrowed connection to JedisPool. If the connection is invalid, JedisPool removes the connection. false We recommend that you set the parameter to false when handling large data volumes. If you set the parameter to true, the system runs the ping command once more.
8 jmxEnabled Specifies whether to enable Java Management Extensions (JMX) monitoring to monitor the utilization of Jedis clients. true We recommend that you set the parameter to true. The monitored application must be running during the monitoring.

Monitoring of idle resources

This is to detect idle Jedis objects. This feature includes four parameters. You can set the testWhileIdle parameter to true to enable the feature. The parameters are described in the following table.

No. Parameter Description Default value Recommendations
1 testWhileIdle Specifies whether to enable the monitoring of idle resources. false We recommend that you set the parameter to true.
2 timeBetweenEvictionRunsMillis Specifies the cycle of idle resources detection. Unit: milliseconds. -1: specifies that the system does not monitor idle resources. We recommend that you customize a monitoring cycle. You can also use the default value.
3 minEvictableIdleTimeMillis Specifies the minimum idle time for resources in JedisPool. The system removes the resource that has been idle for the specified period. Unit: milliseconds. 1,000 × 60 × 30 milliseconds = 30 minutes You can customize the value as needed, or use the default value in most scenarios.
4 numTestsPerEvictionRun Specifies the number of connections sampled during the monitoring of idle resources. 3 You can fine-tune the value according to the number of connections in your application. If you set the parameter to -1, JedisPool monitors all connections.

Application scope

  • ApsaraDB for Redis