5.3.7.RELEASE vs 6.0.0.RELEASE / RESP2 vs RESP3 support

[daniel-b2c2]

Could somebody kindly confirm if the following statements are true:

• 5.3.7 only ever supported RESP2,
  • and so all connections we made to a redis server using this library, would have been via RESP2 protocol
• 6.0.0 additionally supports RESP3
• These 4 changes which were responsible for introducing RESP3,
  • and only to the 6.x branch:

[tishun]

Hey @daniel-b2c2 ,

Could somebody kindly confirm if the following statements are true:

• 5.3.7 only ever supported RESP2 (and so all connections we made to a redis server using this library, would have been via RESP2 protocol)

To the best of my knowledge and as far as I can see - yes.

• 6.0.0 additionally supports RESP3

This is correct, as per https://github.com/redis/lettuce/releases/tag/6.0.0.RELEASE

• These 4 changes which were responsible for introducing RESP3,

  • and only to the 6.x branch:

Quite possibly. Before digging into deeper archeology can you give some hint as to what you are trying to achieve?
I am only asking because I would give a more correct answer.

[daniel-b2c2]

Many thanks for the response.

Before digging into deeper archeology can you give some hint as to what you are trying to achieve?

Sure, we have a wrapper for the lettuce redis client, we've been using 5.3.7 and recently tried to upgrade to 6.0.0. Following the upgrade some of our tests fail.

The test isn't trivial, it's looking at a reconnection scenario and asserting that any listeners we registered before the disconnection are re-registered upon reconnect.

To do this we are simulating a server and client being connected, the server going down, and then seeing the server come back up, and making some assertions.

The behaviour we see is that once the server is brought down, even when it comes back up, the client is stuck in a loop forever trying to re-establish the connection, failing to do so, and throwing an exception to indicate this. Our wrapper catches the exception and we schedule a reconnect in 5 seconds. The schedule to invoke the reconnect gets called as expected but when it invokes the reconnect it never succeeds in reconnecting, and round it goes till the unit test times-out.

The exception is thrown in AbstractRedisClient's getConnection where the connectionFuture.get() is called, resulting in the following stacktrace:

This gets turned into a RedisConnectionException, and our wrapper catches this, and then schedules the retry (which does all the above again).

I've managed to track this change in behaviour down to these 4 commits.

That is to say before these commits, in branch 6.x, our tests would pass, after these 4 commits (treating them a group as separately they don't compile), we see our test failing.

I'm trying to understand what changed, if we need to do anything on our side to get the test to pass.

I checked the protocol it attempts to connect with and it tries RESP3, which is a change in behaviour (even if internal only) so I have tried downgrading to RESP2 by setting the client protocol option, but the tests still fail.

It's early days so I haven't isolated the code-under-test further (a.k.a a demo) which would be my next step as I'm still exploring what changed and if there's anything obvious - client default flags that have changed etc.

[tishun]

I checked the protocol it attempts to connect with and it tries RESP3, which is a change in behaviour (even if internal only) so I have tried downgrading to RESP2 by setting the client protocol option, but the tests still fail.

Not really internal, this is a breaking change, but it is expected as this is a major release of the library and I believe it was designed to change the behaviour from the beginning. That being said RESP3 should not alter the way the driver reconnects, so it must be some other side effect.

This gets turned into a RedisConnectionException, and our wrapper catches this, and then schedules the retry (which does all the above again).

If I am reading this right you are handling the reconnection manually. Is there some reason you are doing that instead of using the driver's own reconnect functionality?

I'm trying to understand what changed, if we need to do anything on our side to get the test to pass.

I am still lacking a few of the details to suggest anything myself, but let me know if I can help.
It really boils down to how you do the reconnect yourself and how you configure the driver.