Repository navigation
DOC-7226 Move memory-layer, semantic-cache, recommendation-engine and feature-store Jedis use cases to RedisClient - #4390
Merged
Conversation
Memory layer, semantic cache and recommendation engine (java-jedis) take a RedisClient instead of a JedisPooled. Jedis 8.0 removed JedisPooled, so these did not compile against the 8.0.2 that DOC-7213 made the docs baseline. The demo servers build the client with RedisClient.builder().hostAndPort(...) .clientConfig(...).poolConfig(...).build() so the existing pool and timeout settings carry over, and the page snippets use RedisClient.create(...). The poms move to Jedis 8.0.2 (memory layer and semantic cache from 5.2.0, recommendation engine from 6.2.0). Unlike the JedisPool directories, nothing structural changed: JedisPooled already borrowed a connection per multi()/pipelined() and these classes already closed them in try-with-resources, which is why this group is a type rename plus the constructors. Verification: all three compile with Maven offline against Jedis 8.0.2 with deprecation reporting on and no warnings. Each demo ran against redis:8.10 and was compared with the same request sequence on the original code (memory layer and semantic cache on Jedis 5.2.0, recommendation engine on 6.2.0). Memory layer gave identical dedup distances (0.873, 0.554, 0.582); semantic cache gave identical hit/miss and distances (0.0, 0.0665); recommendation engine gave identical ranked ids and scores for plain, session-aware and filtered+reranked searches. 40-60 concurrent requests per demo all returned 200. Constraint: RedisClient.builder() needs a ConnectionPoolConfig (GenericObjectPoolConfig<Connection>), which these demos already used Learned: the recommendation-engine demo cannot start on a fresh Redis 8.10, original code included: dropIndex tolerates only "no such index" / "unknown index name" and 8.10 says "SEARCH_INDEX_NOT_FOUND Index not found". Left unfixed (out of scope); I verified by pre-creating a dummy recommend:idx Learned: recommendation-engine builds a plain jar with no Main-Class; run it with mvn exec:java or a dependency:build-classpath classpath, not java -jar Learned: an empty "recalled" in the memory-layer demo's first turns is baseline behavior (recall threshold), not a search-parsing regression; compare against the original before suspecting the migration Ticket: DOC-7226 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…sClient
FeatureStore, BuildFeatures and DemoServer take a RedisClient instead of a
JedisPool. getResource() blocks are gone, the three pipelines are in
try-with-resources, DemoServer builds the client with RedisClient.builder() and a
ConnectionPoolConfig (maxTotal 64, maxIdle 32, minIdle 4, as before), and
BuildFeatures closes a RedisClient it creates with RedisClient.create. The pom
pins Jedis 8.0.2 (was 6.2.0), and the page's snippets, prerequisites ("Jedis 8.0
or later") and pool-sizing section follow.
One scoping trap: updateStreaming read the HEXPIRE Response after the pipeline
block, so the Response variable moves out of the try. Responses stay readable
after the pipeline closes because sync() resolves them.
Verification: compiles with Maven offline and deprecation reporting on, against
Jedis 8.0.2, no warnings. The migrated build and the original (Jedis 6.2.0) ran
the same scenario against redis:8.10 with the streaming worker paused for the
static part: identical batch fields and values for u0001, identical /read and
/batch-read output, key TTL ~86400, per-field TTL on every streaming field in
(0, 300] after the worker ran (the HEXPIRE pipeline), bulk-load key TTL ~600. The
bulk-load response lists "loaded" and "ttl_seconds" in a different order between
runs; that is Map.of's per-JVM randomized iteration order in unmodified code.
Constraint: pipeline Response values may be read after the try-with-resources closes the pipeline, but only if sync() ran inside it
Learned: comparing against the original on a different Jedis version needs invariants, not byte equality, wherever the demo uses Map.of for JSON
Ticket: DOC-7226
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Contributor
🧠 Redis MemoryFound 5 related items from repository history (5 new this commit):
Memory updated at 45b2b2c |
Contributor
This was referenced Oct 30, 2026
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Moves four Maven-based
java-jedisuse cases toRedisClient(Jedis 8.0.2).JedisPooledwas removed in Jedis 8.0, so three of these did not compile against it. Mostly a type rename plus builder-based construction that keeps the existing pool and timeout settings; poms move to 8.0.2. feature-store also moves its pipelines to try-with-resources.Verified: Maven offline build with 0 deprecation warnings; each demo run against Redis 8.10 and compared with the original code (identical distances, rankings, TTLs).
Known, not fixed: recommendation-engine
Recommender.dropIndexonly tolerates "no such index"/"unknown index name", so the demo cannot start on a fresh Redis 8.10 (original code too). Not run: Hugo build.Part of DOC-7226.
🤖 Generated with Claude Code
Note
Low Risk
Changes are confined to documentation and demo Maven projects with a mechanical client API swap; Redis command behavior is intended to stay the same.
Overview
Updates the feature-store, memory-layer, semantic-cache, and recommendation-engine Java demos and their guides for Jedis 8, where
JedisPooled/JedisPoolare replaced byRedisClient.Demo code now constructs clients with
RedisClient.builder()/RedisClient.create()andConnectionPoolConfig, passes a sharedRedisClientinto helpers instead of borrowing from a pool per call, and closes the client on shutdown. The feature-storeFeatureStoredropspool.getResource()wrappers and uses try-with-resources onPipelinedirectly; streamingHEXPIREresponses are read after the pipeline block closes.Maven
pom.xmlfiles pinredis.clients:jedis:8.0.2, and the related_index.mdsnippets and prerequisites (Jedis 8.0+, connection pool wording) match the new API.Reviewed by Cursor Bugbot for commit 45b2b2c. Bugbot is set up for automated code reviews on this repo. Configure here.