feat(session): a unified Redis session client that supports switching between underlying clients

[benym]

AgentScope-Java Version

1.0.8-SNAPSHOT

Description

releted to #610

Background

The current JedisSeesion uses JedisPool, which only supports standalone scenarios. In production environments, users mostly use more complex deployment methods, such as sentinels, clusters, and master-slave setups. Furthermore, in a Java environment, users may use different Redis client implementations, such as Jedis, Lettuce, and Redisson. If each is used independently, scaling up with different Redis client implementations would result in a lot of duplicate code. Moreover, naming conventions like JedisSeesion are unclear, as they are all essentially types of Redis clients.

New Feature

• Unified the RedisSession client: using the adapter pattern to implement different underlying Redis clients, and consolidated the duplicate code that was originally scattered across various client implementations into the RedisSession.
• Various Redis deployment modes: Jedis, Lettuce, Redisson adopt more modern APIs and support various deployment modes such as standalone, sentinel, cluster, and master-slave.
• README: Add a README introduction for the agentscope-extensions-session-redis module

The newly added codes all have complete javadoc documentation and the mvn test has passed.

Modify

• Added lettuce dependency
• Add the "deprecated" tag to the old versions of JedisSession and RedissonSession, and update the corresponding javadoc.

New Usage

Jedis Usage Examples

• Jedis Standalone (using RedisClient):

// Create Jedis RedisClient (new API)
RedisClient redisClient = RedisClient.create("redis://localhost:6379");

// Build RedisSession
Session session = RedisSession.builder()
    .jedisClient(redisClient)
    .build();

• Jedis Cluster (using RedisClusterClient)

// Create Jedis RedisClusterClient
Set<HostAndPort> nodes = new HashSet<>();
nodes.add(new HostAndPort("localhost", 7000));
nodes.add(new HostAndPort("localhost", 7001));
nodes.add(new HostAndPort("localhost", 7002));
RedisClusterClient redisClusterClient = RedisClusterClient.create(nodes);

// Build RedisSession
Session session = RedisSession.builder()
    .jedisClient(redisClusterClient)
    .build();

• Jedis Sentinel (using RedisSentinelClient)

// Create Jedis RedisSentinelClient
Set<String> sentinelNodes = new HashSet<>();
sentinelNodes.add("localhost:26379");
sentinelNodes.add("localhost:26380");
RedisSentinelClient redisSentinelClient = RedisSentinelClient.create("mymaster", sentinelNodes);

// Build RedisSession
Session session = RedisSession.builder()
    .jedisClient(redisSentinelClient)
    .build();

Lettuce Usage Examples

• Lettuce Standalone

// Create Lettuce RedisClient
RedisClient redisClient = RedisClient.create("redis://localhost:6379");

// Build RedisSession
Session session = RedisSession.builder()
    .lettuceClient(redisClient)
    .build();

• Lettuce Cluster

// Create Lettuce RedisClient for cluster
RedisURI clusterUri = RedisURI.create("redis://localhost:7000");
RedisClient redisClient = RedisClient.create(clusterUri);

// Build RedisSession
Session session = RedisSession.builder()
    .lettuceClient(redisClient)
    .build();

• Lettuce Sentinel

// Create Lettuce RedisClient for sentinel
RedisURI sentinelUri = RedisURI.builder()
    .withSentinelMasterId("mymaster")
    .withSentinel("localhost", 26379)
    .withSentinel("localhost", 26380)
    .build();
RedisClient redisClient = RedisClient.create(sentinelUri);

// Build RedisSession
Session session = RedisSession.builder()
    .lettuceClient(redisClient)
    .build();

Redisson Usage Example

// Create RedissonClient (configure as needed for your deployment mode)
Config config = new Config();
config.useSingleServer().setAddress("redis://localhost:6379");
// or for cluster: config.useClusterServers().addNodeAddress("redis://localhost:7000");
// or for sentinel: config.useSentinelServers().setMasterName("mymaster").addSentinelAddress("redis://localhost:26379");

RedissonClient redissonClient = Redisson.create(config);

// Build RedisSession
Session session = RedisSession.builder()
    .redissonClient(redissonClient)
    .build();

Checklist

Please check the following items before code is ready to be reviewed.

• Code has been formatted with mvn spotless:apply
• All tests are passing (mvn test)
• Javadoc comments are complete and follow project conventions
• Related documentation has been updated (e.g. links, examples, etc.)
• Code is ready for review

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[gemini-code-assist]

Summary of Changes

Hello @benym, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the Redis session management within AgentScope by introducing a unified RedisSession client. This new implementation leverages an adapter pattern to abstract away the underlying Redis client library, enabling seamless integration with Jedis, Lettuce, and Redisson, and supporting diverse Redis deployment topologies like standalone, cluster, and sentinel. This change streamlines the session management API, reduces code duplication, and improves flexibility for users operating in various production environments.

Highlights

• Unified Redis Session Client: Introduced a new RedisSession class that uses an adapter pattern to provide a single, consistent API for interacting with different Redis client implementations.
• Multi-Client Support: The new RedisSession now natively supports Jedis, Lettuce, and Redisson clients, allowing users to choose their preferred Redis client.
• Flexible Deployment Modes: The unified client supports various Redis deployment modes, including standalone, sentinel, cluster, and master-slave configurations, addressing limitations of previous implementations.
• Deprecation of Old Sessions: The existing JedisSession and RedissonSession classes have been deprecated, guiding users towards the new unified RedisSession.
• Enhanced Documentation: Comprehensive README.md and README_zh.md files have been added to the agentscope-extensions-session-redis module, providing detailed usage examples and explanations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[benym]

ptal,thx @AlbumenJ @chickenlj

[gemini-code-assist]

Code Review

This pull request introduces a unified RedisSession client, which is a significant improvement for supporting various Redis clients (Jedis, Lettuce, Redisson) and deployment modes. The use of the adapter pattern is well-executed. I've identified a few areas for improvement, primarily concerning performance and documentation accuracy. The Jedis and Lettuce adapters currently use the KEYS command, which can pose a performance risk in production; I've suggested switching to SCAN. Additionally, there are some inaccuracies in Javadoc and README examples that should be corrected for clarity. Overall, this is a great feature addition.

[codecov]

Codecov Report

❌ Patch coverage is 83.26180% with 39 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...io/agentscope/core/session/redis/RedisSession.java	75.38%	24 Missing and 8 partials ⚠️
...re/session/redis/lettuce/LettuceClientAdapter.java	91.17%	1 Missing and 2 partials ⚠️
...e/core/session/redis/jedis/JedisClientAdapter.java	93.10%	0 Missing and 2 partials ⚠️
.../session/redis/redisson/RedissonClientAdapter.java	95.00%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[benym]

done. please check again. @AlbumenJ

[AlbumenJ]

Can we reuse this class?

[benym]

Can we reuse this class?

This class is unlikely to be reused. JedisPool in JedisSession can be replaced with UnifiedJedis to adapt to various Redis deployment environments, but I don't think it's necessary to maintain this class anymore. This would allow for multiple parallel implementations of Redis-based sessions, and the core logic of session-based systems is clearly repetitive. The core logic of RedisSeesion is based on JedisSeesion, using an adapter design to hide the underlying client operations. I believe that for users, Jedis is just a client; they are actually operating Redis. Therefore, a unified RedisSeesion is sufficient. If Jedis is needed, the switch can be completed by specifying the Jedis client during initialization. Now that everything can be unified under a single RedisSession, the old implementation can be deprecated, reducing maintenance burden.

[benym]

From a design perspective, the adapter handles the client commands for operating Redis, while existing JedisSession and RedissonSession handle session operation logic. This part is largely reusable and doesn't need to be implemented repeatedly for the client.