Uploaded image for project: 'Spring Data Redis'
  1. Spring Data Redis
  2. DATAREDIS-1011

Lettuce pipelining behaviour is different than Jedis pipelining


    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.1.9 (Lovelace SR9)
    • Fix Version/s: None
    • Component/s: Lettuce Driver
    • Labels:
    • Environment:
      Java 11, spring boot 2.1.4


      After switching to spring boot 2.1.x which switches from Jedis to Lettuce by default we are seeing a difference in pipelining behaviour. In particular we noticed a significant increase in the latency of our redis calls which utilize pipelining.

      For example:

              connection -> {
                // 1. use connection.{command} operation
                // 2. use connection.{command} operation
                // 3. use connection.{command} operation
                return null;

      the above use of the pipelining functionality in the Jedis implementation will buffer all 3 commands and flush them to the transport at once.

      However, in the lettuce implementation, due to auto-flushing being enabled by default in Lettuce, each command is flushed to the transport individually in an async manner. 

      This behaviour difference affects the latency of Redis operations done via pipelining.

      A possible solution for this could be:

      In the LettuceConnection class, when getAsyncConnection is called and a RedisAsyncCommands is created, we should check if pipelining is enabled and if so, disable auto-flushing for that instance of RedisAsyncCommands.

      Once the closePipeline method is called, we should call the flush operation and then await on the futures like is currently done.

      An example of this can be found in the lettuce documentation:

      https://github.com/lettuce-io/lettuce-core/wiki/Pipelining-and-command-flushing  under the Async Pipelining code example.

      At the very least, this functionality should be possible and can be configurable if need be. 






            • Assignee:
              cstrobl Christoph Strobl
              kayaniu Umair Kayani
              Last updater:
              Christoph Strobl
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: