Valkey GLIDE Documentation

The Zero-Copy Initiative is a performance optimization in glide-core (specifically within the vendored redis-rs) designed to reduce per-value memory copies on the client hot path.

Historically, both receiving (GET/MGET) and sending (SET) data involved multiple copies:

• Receive: The parser would to_vec() payloads out of the socket buffer, and the FFI would copy them again into the caller's buffer.
• Send: A SET value could be copied up to three times (into command data, into the packed RESP vector, and into the framed write buffer) before reaching the kernel.

The initiative implements a multi-phase design to reduce these copies to a theoretical minimum (the kernel-to-userspace recv/send copy).

Transactions in the compatibility layer behave differently than standard Jedis. After calling multi(), you must use the returned Transaction object to queue commands. Calling methods directly on the Jedis instance will not queue them to the transaction.

Using the Transaction Object

Transaction t = jedis.multi();
Response<String> r1 = t.set("key", "value");
Response<String> r2 = t.get("key");
List<Object> results = t.exec();
String value = r2.get(); // retrieve after exec()

Using the Native GLIDE Batch API

For commands not exposed on the Transaction object, or for non-atomic pipelining, use the native GLIDE Batch API with a GlideClient instance:

Batch batch = new Batch(true)  // true = atomic transaction
    .set("key1", "value1")
    .get("key1");
Object[] results = glideClient.exec(batch, false).get();

Valkey GLIDE supports Java 8 (JDK 1.8) by using compatibility utilities that replace APIs introduced in Java 9 and later. Projects targeting Java 8 should ensure their build.gradle is configured with:

• sourceCompatibility = JavaVersion.VERSION_1_8
• targetCompatibility = JavaVersion.VERSION_1_8

Migrating to Valkey GLIDE involves several architectural shifts regarding security and connection management:

• GLIDE Architecture Shift: Moves from application-managed SSL to system-managed SSL with secure defaults.
• Certificate Management: If you use custom keystores or truststores, you must migrate these to the system certificate store.
• Protocol Selection: GLIDE automatically selects TLS 1.2+ and secure cipher suites.
• Client Authentication: Client certificates are not supported; you must use username/password authentication instead.

When using the Jedis 4.x compatibility layer, GLIDE manages connection pooling internally for optimized performance.

Key Difference:

• In Jedis 4.x, GenericObjectPoolConfig (Apache Commons Pool 2) controls min/max connections and eviction.
• In the GLIDE compatibility layer, these GenericObjectPoolConfig parameters are ignored (though they are accepted to maintain API compatibility). GLIDE's internal pooling is optimized for performance and reliability automatically.

Selecting the correct artifact depends on your existing codebase's dependency version:

• Use jedis-4-compatibility when: Your application was built against Jedis 4.x (e.g., 4.0.x–4.4.x). This is specifically required if you use JedisPooled with GenericObjectPoolConfig<Connection>. Note that this layer is RESP2 only; while .protocol() is available for source compatibility, it is ignored and forced to RESP2.
• Use jedis-compatibility (5.x-oriented) when: Your codebase targets Jedis 5.x APIs (e.g., GenericObjectPoolConfig<Object> on JedisPooled) and you require RESP3 support.
• Either module may fit when: You only use JedisPool, UnifiedJedis, JedisCluster, or standalone Jedis with simple constructors. In this case, pick the one that matches your current major API shape.

The receive path in Valkey GLIDE is described as reduced-copy. It aims to reach the 'one-copy floor' where data moves directly from the kernel read buffer to the caller.

This is achieved by replacing per-bulk-string Vec allocations and memcpy operations with a slice of a single frame buffer. This provides significant performance gains, especially for multi-element responses like MGET, because it eliminates one allocation and one copy per element, sharply reducing allocator pressure.