Database index not applied to Jedis client

[s-sathish]

Hi Team, Opening this issue in regard with redis/jedis#2523

As per this https://github.com/redis/jedis/blob/master/src/main/java/redis/clients/jedis/BinaryClient.java#L124
setDb should be called only after SELECT(db) command

Shouldn't jedis.getClient().select(getDatabase()); called before connecting the client ?
Please provide inputs

Thanks

Spring Data Redis: 2.5
Jedis: 3.6.0

[s-sathish]

Hi @mp911de I can submit a PR if needed for the same. Please let me know.

[mp911de]

Feel free. It would also make sense to investigate why none of the tests has failed.

[s-sathish]

Ok. Getting it checked.

[s-sathish]

Checking more on this, following are the observations -

1. In the example provided in 3.6.0 switch database invalid with spring boot redisTemplate redis/jedis#2523 - JedisConnectionFactory was not created as a conventional bean. Doing this after creating the JedisConnectionFactory should have made it work there codeFactory.afterPropertiesSet()
   But please note that this is not the case with the previous version 2.4.8. Even without calling afterPropertiesSet() it works as select() is done when creating Jedis client object.
2. None of the tests related to this failed because in our test cases when we create JedisConnectionFactory, we use afterPropertiesSet which will set the JedisClientConfig accordingly based on the user provided options. I have added one test to support this.

PR for the same - #2056
Please review.

[mp911de]

Thanks for having a look. With version 2.5 of Spring Data Redis we leverage the JedisClientConfig object to consistently configure the client. Calling the lifecycle method afterPropertiesSet() is required to properly transition from the configuration state into a state where the client is initialized with the configuration and becomes ready to use.

In our previous code, we couldn't rely on proper database selection because of the evolution of Jedis. There have always been mismatches between the client state and what was configured in JedisConnectionFactory. Issuing a SELECT although the database was already selected generates overhead and we don't want to impose overhead if it is not necessary.

That being said, either your code or the bean container must initialize JedisConnectionFactory with calling afterPropertiesSet(). Everything else is wrong API usage. Following the thought of reinstating the database selection, it would fix the database selection but would leave the client in a partially configured state where SSL, authentication, pooling, and other configuration remains not applied.

It would even make sense to throw IllegalStateException when calling getConnection() respective getClusterConnection() while JedisConnectionFactory is not yet initialized.

[mp911de]

Closing this one in favor of #2057.