Releases: redis/jedis
5.1.5
5.1.4
Changes
π₯ Breaking Changes
π New Features
- Support Hash field expiration (#3826)
- Support issuing Latency commands (#3729)
- Add support for the NOVALUES option of HSCAN command (#3741, #3746)
- Add support for CLIENT TRACKINGINFO command (#3751)
- Support IGNORE and other optional arguments for timeseries commands (#3860, #3863)
- Add last entry id for XREADs and support XREADs reply as map (#3791)
- Support the MAXAGE option for CLIENT KILL (#3754)
- Support ADDSCORES argument in FT.AGGREGATE (#3908)
- Support [S]PUBLISH in pipelines and transactions (#3859)
π Bug Fixes
- Ensure closing connection in Pipeline (#3865)
- Address change in JSON.GET command without path (#3858)
π§° Maintenance
- Add methods in CommandArguments and RawableFactory (#3834)
- Modify and fail-fast GeoSearchParam (#3827)
Contributors
We'd like to thank all the contributors who worked on this release!
5.2.0-beta4
What's new
Redis 7.4-RC1 support
In this release, we added support for Redis 7.4-RC1, including:
- Support Hash field expiration (#3826)
- Add last entry id for XREADs and support XREADs reply as map (#3791)
- Add support for the NOVALUES option of HSCAN (#3741, #3746)
- Support the MAXAGE option for CLIENT KILL (#3754)
Client-side caching
This release supports server-assisted, client-side caching, and is currently beta grade.
Client-side caching is available within UnifiedJedis, JedisPooled, JedisCluster, etc classes via implementation of ClientSideCache class, with only RESP3 protocol. It is recommended to use a ClientSideCache implementation with TTL (time-to-live). We have included two implementations based on Google Guava and Caffeine libraries.
How to try Client-Side Caching
- Install Jedis 5.2.0-beta4
- Choose and install a caching library: Google Guava or Caffeine
- Use the following code example to get started:
import redis.clients.jedis.*;
import redis.clients.jedis.csc.*;
class CacheExample {
public static void main() {
HostAndPort node = HostAndPort.from("localhost:6379");
JedisClientConfig clientConfig = DefaultJedisClientConfig.builder()
.resp3() // RESP3 protocol
//.user("myuser") // Redis server username (optional)
//.password("mypass") // Redis user's password (optional)
.build();
ClientSideCache clientSideCache;
// Uncomment one of the following lines to use the corresponding cache backend
// GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder().maximumSize(10_000).ttl(100).build();
// CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder().maximumSize(10_000).ttl(100).build();
UnifiedJedis client = new UnifiedJedis(node, clientConfig, clientSideCache);
// JedisPooled client = new JedisPooled(node, clientConfig, clientSideCache);
// JedisCluster client = new JedisCluster(Collections.singleton(node), clientConfig, clientSideCache);
client.set("foo", "bar");
client.get("foo");
client.get("foo"); // cache hit
client.del("foo");
client.close();
}
}
It is highly recommended to use a ClientSideCache implementation with TTL.
Both of our provided GuavaClientSideCache and CaffeineClientSideCache have TTL support and use a default value when not set. It is discouraged to use ttl(0)
in these.
It is also a good idea to keep the idle connections busy to get more and updated notifications. It can be done easily using pool config:
GenericObjectPoolConfig<Connection> poolConfig = new ConnectionPoolConfig();
poolConfig.setTestWhileIdle(true); // ConnectionPoolConfig by default does this.
// It is still shown here for better understanding.
This pool config can be used as follows:
JedisPooled client = new JedisPooled(node, clientConfig, clientSideCache, poolConfig);
JedisCluster client = new JedisCluster(Collections.singleton(node), clientConfig, clientSideCache, poolConfig);
It is possible to limit or ignore commands and/or keys for client side caching. For example, if we want to ignore some keys based on their prefix, we can define a ClientSideCacheable:
final String IGNORE_PREFIX = "PREFIX_TO_IGNORE";
ClientSideCacheable isCacheable = new ClientSideCacheable() {
@Override
public boolean isCacheable(ProtocolCommand command, Object... keys) {
for (String key : (String[]) keys) { // assuming we'll only execute methods with String keys
if (key.startsWith(IGNORE_PREFIX)) {
return false;
}
}
return true;
}
};
This ClientSideCacheable can be a parameter for ClientSideCache. In our provided implementations, it can be:
GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder().cacheable(isCacheable).build();
CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder().cacheable(isCacheable).build();
It is also possible to create client-side caching enabled client object using URL/URI with proper query params. Supported params are:
cache_lib
(caching library) - required; can be eitherguava
orcaffeine
cache_max_size
(maximum no of commands) - optionalcache_ttl
(time-to-live, in seconds) - optional
For example:
JedisPooled client = new JedisPooled("redis://myuser:mypass@localhost:6379/?cache_lib=guava&cache_max_size=10000&cache_ttl=100");
π₯ Breaking Changes
- Address change in JSON.GET command without path (#3858)
- Modify and fail-fast GeoSearchParam (#3827)
- Support transaction from UnifiedJedis without calling multi first (#3804)
- Reduce the log level of validateObject to WARN (#3750)
π Other notable improvements
- Support [S]PUBLISH commands in pipelines and transactions (#3859)
- PubSub handle array of messages for RESP2 (#3811)
- Add Experimental, Internal and VisibleForTesting annotations (#3790)
- Implement equals and hashcode in Params classes (#3728)
- Support CLIENT TRACKINGINFO command (#3751)
- Support issuing Latency commands (#3729)
π§° Maintenance
- Bump org.json:json from 20231013 to 20240303 (#3706, #3752)
- Access Reducer attributes (#3637)
- Add methods in CommandArguments and RawableFactory (#3834)
- Deprecate unused Set builders (#3857)
- Deprecate unused JSON.ARRAPPEND in CommandObjects (#3798)
- GETSET command is deprecated since Redis 6.2.0 (#3768)
- Resolve compile warnings (#3810)
- Disable Redis Graph tests (#3856)
- Introduce EndpointConfig and load endpoint settings from the endpoints.json file (#3836)
- Address Gears test fail - Cleanup Function libraries (#3840)
- Add more tests for the CommandObjects class (#3809)
- Extensive unit tests for the CommandObjects class (#3796)
- Add extensive tests for UnifiedJedis (#3788)
- Pipelined tests for lists and sets, and API typo fix (#3772)
- Extensive unit tests for PipeliningBase (#3778)
- Streamline test execution (#3760)
- Add pipelined tests for sorted sets (#3771)
- Geo pipelined tests (#3767)
- Reenable clustering tests (#3764)
- Add tests for Stream pipelined commands (#3763)
- Add Hashes pipeline commands unit tests (#3288)
- Add unit tests for pipelining - migrate and db commands (#3759)
- Address RediSearch profile change (#3636)
- Running doctests also on emb-examples (#3693)
- Run integration workflow for 5.2.0 branch (#3681)
- Spellcheck as part of CI (#3492)
- Adding stale issues workflow (#3528)
- Creating CODEOWNERS for documentation (#3570)
- Unifying GitHub tokens (#3650)
- Replace deprecated set-output command with environment file (#3622)
- Fixing GPG key usage (#3670)
- Bump org.apache.maven.plugins:maven-jar-plugin from 3.3.0 to 3.4.1 (#3819, #3822)
- Bump org.apache.maven.plugins:maven-gpg-plugin from 3.2.2 to 3.2.4 (#3775, #3785, #3794, #3818, #3823)
- Bump org.jacoco:jacoco-maven-plugin from 0.8.5 to 0.8.12 (#3653, #3805)
- Bump org.apache.maven.plugins:maven-source-plugin from 3.3.0 to 3.3.1 (#3807)
- Bump org.apache.maven.plugins:maven-compiler-plugin from 3.11.0 to 3.13.0 (#3665, #3786)
- Bump org.apache.maven.plugins:maven-surefire-plugin from 3.2.2 to 3.2.5 (#3656, #3688)
- Bump org.apache.maven.plugins:maven-javadoc-plugin from 3.6.2 to 3.6.3 (#3639)
- Bump jackson.version (com.fasterxml.jackson.core:jackson-databind and com.fasterxml.jackson.datatype:jackson-datatype-jsr310) from 2.14.2 to 2.17.1 (#3666, #3762, #3776, #3833)
- Bump com.kohlschutter.junixsocket:junixsocket-core from 2.8.1 to 2.9.1 (#3647, #3724, #3806)
Contributors
We'd like to thank all the contributors who worked on this release!
5.2.0-beta3
Re-released as 5.2.0-beta4.
5.1.3
Changes
π New Features
- Custom connection pool to MultiClusterPooledConnectionProvider (#3801)
π Bug Fixes
- Consider null values in empty StreamPendingSummary (#3793)
- Fix UnifiedJedis pexpireAt glitch (#3782)
- Use expiryOption in PipelineBase.expireAt (#3777)
π§° Maintenance
- Add TS.INFO [DEGUB] and CF.MEXISTS in pipelined commands (#3787)
- Fix typo in SetPipelineCommands method name (#3773)
- Bump jackson.version from 2.16.1 to 2.16.2 (#3762)
Contributors
We'd like to thank all the contributors who worked on this release!
5.2.0-beta2
What's new
This release supports server-assisted, client-side caching, and is currently beta grade.
Client-side caching is available within UnifiedJedis, JedisPooled, JedisCluster, etc classes via implementation of ClientSideCache class, with only RESP3 protocol. It is recommended to use a ClientSideCache implementation with TTL (time-to-live). We have included two implementations based on Google Guava and Caffeine libraries.
How to try Client-Side Caching
- Install Jedis 5.2.0-beta2
- Choose and install a caching library: Google Guava or Caffeine
- Use the following code example to get started:
import redis.clients.jedis.*;
import redis.clients.jedis.csc.*;
class CacheExample {
public static void main() {
HostAndPort node = HostAndPort.from("localhost:6379");
JedisClientConfig clientConfig = DefaultJedisClientConfig.builder()
.resp3() // RESP3 protocol
//.user("myuser") // Redis server username (optional)
//.password("mypass") // Redis user's password (optional)
.build();
ClientSideCache clientSideCache;
// Uncomment one of the following lines to use the corresponding cache backend
// GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder().maximumSize(10_000).ttl(100).build();
// CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder().maximumSize(10_000).ttl(100).build();
UnifiedJedis client = new UnifiedJedis(node, clientConfig, clientSideCache);
// JedisPooled client = new JedisPooled(node, clientConfig, clientSideCache);
// JedisCluster client = new JedisCluster(Collections.singleton(node), clientConfig, clientSideCache);
client.set("foo", "bar");
client.get("foo");
client.get("foo"); // cache hit
client.del("foo");
client.close();
}
}
It is highly recommended to use a ClientSideCache implementation with TTL.
Both of our provided GuavaClientSideCache and CaffeineClientSideCache have TTL support and use a default value when not set. It is discouraged to use ttl(0)
in these.
It is also a good idea to keep the idle connections busy to get more and updated notifications. It can be done easily using pool config:
GenericObjectPoolConfig<Connection> poolConfig = new ConnectionPoolConfig();
poolConfig.setTestWhileIdle(true); // ConnectionPoolConfig by default does this.
// It is still shown here for better understanding.
This pool config can be used as follows:
JedisPooled client = new JedisPooled(node, clientConfig, clientSideCache, poolConfig);
JedisCluster client = new JedisCluster(Collections.singleton(node), clientConfig, clientSideCache, poolConfig);
It is possible to limit or ignore commands and/or keys for client side caching. For example, if we want to ignore some keys based on their prefix, we can define a ClientSideCacheable:
final String IGNORE_PREFIX = "PREFIX_TO_IGNORE";
ClientSideCacheable isCacheable = new ClientSideCacheable() {
@Override
public boolean isCacheable(ProtocolCommand command, Object... keys) {
for (String key : (String[]) keys) { // assuming we'll only execute methods with String keys
if (key.startsWith(IGNORE_PREFIX)) {
return false;
}
}
return true;
}
};
This ClientSideCacheable can be a parameter for ClientSideCache. In our provided implementations, it can be:
GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder().cacheable(isCacheable).build();
CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder().cacheable(isCacheable).build();
It is also possible to create client-side caching enabled client object using URL/URI with proper query params. Supported params are:
cache_lib
(caching library) - required; can be eitherguava
orcaffeine
cache_max_size
(maximum no of commands) - optionalcache_ttl
(time-to-live, in seconds) - optional
For example:
JedisPooled client = new JedisPooled("redis://myuser:mypass@localhost:6379/?cache_lib=guava&cache_max_size=10000&cache_ttl=100");
4.4.8
Changes
π Bug Fixes
- Fix ZREVRANGE versions with max/min swapped in MultiNodePipelineBase (#3784)
- Use expiryOption in PipelineBase.expireAt (#3777)
- Fix UnifiedJedis pexpireAt glitch (#3782)
- Consider null values in empty StreamPendingSummary (#3793)
Contributors
We'd like to thank all the contributors who worked on this release!
5.2.0-beta1
What's new
This release supports server-assisted, client-side caching, and is currently beta grade.
Client-side caching is available within UnifiedJedis, JedisPooled, JedisCluster, etc classes via implementation of ClientSideCache class, with only RESP3 protocol. It is recommended to use a ClientSideCache implementation with TTL (time-to-live). We have included two implementations based on Google Guava and Caffeine libraries.
How to try Client-Side Caching
- Install Jedis 5.2.0-beta1
- Choose and install a caching library: Google Guava or Caffeine
- Use the following code example to get started:
import redis.clients.jedis.*;
import redis.clients.jedis.csc.*;
class CacheExample {
public static void main() {
HostAndPort node = HostAndPort.from("localhost:6379");
JedisClientConfig clientConfig = DefaultJedisClientConfig.builder()
.resp3() // RESP3 protocol
//.user("myuser") // Redis server username (optional)
//.password("mypass") // Redis user's password (optional)
.build();
ClientSideCache clientSideCache;
// Uncomment one of the following lines to use the corresponding cache backend
// GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder().maximumSize(10_000).ttl(100).build();
// CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder().maximumSize(10_000).ttl(100).build();
UnifiedJedis client = new UnifiedJedis(node, clientConfig, clientSideCache);
// JedisPooled client = new JedisPooled(node, clientConfig, clientSideCache);
// JedisCluster client = new JedisCluster(Collections.singleton(node), clientConfig, clientSideCache);
client.set("foo", "bar");
client.get("foo");
client.get("foo"); // cache hit
client.del("foo");
client.close();
}
}
It is highly recommended to use a ClientSideCache implementation with TTL.
Both of our provided GuavaClientSideCache and CaffeineClientSideCache have TTL support and use a default value when not set. It is discouraged to use ttl(0)
in these.
It is also a good idea to keep the idle connections busy to get more and updated notifications. It can be done easily using pool config:
GenericObjectPoolConfig<Connection> poolConfig = new ConnectionPoolConfig();
poolConfig.setTestWhileIdle(true); // ConnectionPoolConfig by default does this.
// It is still shown here for better understanding.
This pool config can be used as follows:
JedisPooled client = new JedisPooled(node, clientConfig, clientSideCache, poolConfig);
JedisCluster client = new JedisCluster(Collections.singleton(node), clientConfig, clientSideCache, poolConfig);
It is possible to limit or ignore commands and/or keys for client side caching. For example, if we want to ignore some keys based on their prefix, we can define a ClientSideCacheable:
final String IGNORE_PREFIX = "PREFIX_TO_IGNORE";
ClientSideCacheable isCacheable = new ClientSideCacheable() {
@Override
public boolean isCacheable(ProtocolCommand command, Object... keys) {
for (String key : (String[]) keys) { // assuming we'll only execute methods with String keys
if (key.startsWith(IGNORE_PREFIX)) {
return false;
}
}
return true;
}
};
This ClientSideCacheable can be a parameter for ClientSideCache. In our provided implementations, it can be:
GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder().cacheable(isCacheable).build();
CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder().cacheable(isCacheable).build();
It is also possible to create client-side caching enabled client object using URL/URI with proper query params. Supported params are:
cache_lib
(caching library) - required; can be eitherguava
orcaffeine
cache_max_size
(maximum no of commands) - optionalcache_ttl
(time-to-live, in seconds) - optional
For example:
JedisPooled client = new JedisPooled("redis://myuser:mypass@localhost:6379/?cache_lib=guava&cache_max_size=10000&cache_ttl=100");
5.1.2
5.2.0-alpha3
This release provides support for server-assisted, client-side caching, and is currently alpha grade.
Client-side caching is available within UnifiedJedis, JedisPooled, JedisCluster, etc classes via implementation of ClientSideCache class, with RESP3 only. It is recommended a ClientSideCache implementation with TTL (time-to-live). We have included two implementations based on Google Guava and Caffeine libraries.
class CacheExample {
public static void main() {
HostAndPort hnp = HostAndPort.from("localhost:6379");
JedisClientConfig config = DefaultJedisClientConfig.builder()
.resp3() // RESP3 protocol
.password("foobared")
.build();
ClientSideCache csc;
// ClientSideCache csc = GuavaCSC.builder().maximumSize(1000).ttl(100).build();
// ClientSideCache csc = CaffeineCSC.builder().maximumSize(1000).ttl(100).build();
UnifiedJedis client = new UnifiedJedis(hnp, config, csc);
// JedisPooled client = new JedisPooled(hnp, config, csc);
// JedisCluster client = new JedisCluster(Collections.singleton(hnp), config, csc);
client.set("foo", "bar");
client.get("foo");
client.get("foo"); // cache hit
client.del("foo");
client.close();
}
}