How to use Jedis in multi threaded environment
Jedis instances are single threaded
- Don’t use the same Jedis connection instance from multiple threads at the same time.
- Using the same Jedis instance from multiple threads at the same time will result in socket connection errors/resets or strange error messages like “expected ‘$’ but got ‘ ‘“.
- This allows you to talk to redis from multiple threads while still getting the benefits of reused connections.
- The JedisPool object is thread-safe and can be used from multiple threads at the same time.
- This pool should be configured once and reused.
- Make sure to return the Jedis instance back to the pool when done, otherwise you will leak the connection.
- We have seen a few cases where connections in the pool get into a bad state. As a failsafe, you may want to re-create the JedisPool if you see connection errors that continue for longer than 30 seconds.
Also make use of maxTotal and blockWhenExhausted settings while configuring jedis pool:
This setting controls the max number of connections that can be created at a given time. Given that Jedis connections cannot be shared across threads, this setting affects the amount of concurrency your application can have when talking to Redis. Note that each connection does have some memory and CPU overhead, so setting this to a very high value may have negative side effects. If not set, the default value is 8, which is probably too low for most applications. When chosing a value, consider how many concurrent calls into Redis you think you will have under load.
This controls behavior when a thread asks for a connection, but there aren’t any that are free and the pool can’t create more (due to maxTotal). If set to true, the calling thread will block for maxWaitMillis before throwing an exception. The default is true and I recommend true for production environments. You could set it to false in testing environments to help you more easily discover what value to use for maxTotal.