CrudRepository.findByIdOrNull() sometimes returns null even when there is a value

[dlwhdals987]

val kotlinVer = "1.7.0"
id("org.springframework.boot") version "2.6.1"
id("io.spring.dependency-management") version "1.0.11.RELEASE"

@Repository
interface PlayerRepository : CrudRepository<Player, MemberId> {}

---

playerRepository.findByIdOrNull()
--> If you use it like the above, there will be cases where there is no data even if there is data

If there is a delay due to the large number of requests, sometimes the result is null.

Internally, it seems to use the dispatch(<T> RedisCommand<K, V, T> dispatch(RedisCommand<K, V, T> command)) method in the io.lettuce.core.api.StatefulConnection.interface. Is it related?

Is there a way to make the data reconciliation come out non-null?

[jxblum]

Hi @dlwhdals987-

DISCLAIMER: I am no Redis expert and I am still learning the ins and outs of SD Redis as well as Redis.

Regarding:

"If there is a delay due to the large number of requests, sometimes the result is null."

This is somewhat relevant to your ask (corrected & simplified):

Internally, it seems to use the <T> AsyncCommand<K, V, T> dispatch(:RedisCommand<K, V, T>) method in the io.lettuce.core.api.StatefulConnection interface. Is it related?

In short, YES.

However, let's be very clear here, and start at the beginning.

As you are probably already aware, Spring Data Redis builds on Spring Data KeyValue. Therefore, SD Redis's (default) CrudRepository implementation is actually SD KeyValue's SimpleKeyValueRepository class. Thus, when you (indirectly) invoke the findById(:ID) operation on CrudRepository, the following (~) sequence of calls will happen:

playerRepository.findById(memberId)
  -> SimpleKeyValueRepository.findById(memberId, Player.class):Optional<Player>
  -> SimpleKeyValueRepository.execute(:KeyValueAdapter):Optional<Player>
  -> RedisKeyValueAdapter.get(memberId, keyspace, Player.class) // a SD KeyValue KeyValueAdapter interface impl
  -> RedisTemplate.execute(:RedisConnection)
  -> DefaultedRedisConnection.hGetAll(key) // key is the memberId in binary form (byte[])
  -> LettuceHashCommands.hGetAll(key)
...

Now is the moment to pause and observe the implementation of the LuttuceHashCommands.hGetAll(key) method. You will notice 2 things.

First, on line 103, notice connection.invoke().... LettuceConnection's invoke() method (here) returns an "asynchronous" connection.

Second, the use of the "asynchronous" connection also corresponds to the invocation of the RedisHashAsyncCommands::hgetall "asynhronous" operation (command), also on line 103. Inside RedisHashAsyncCommands.hgetall(..) is also where we find the dispatch(..) method call to which you are referring.

The connection.invoke() method returns a SD Redis LettuceInvoker instance, where the just(..) method will be called with the command to execute (an asynchronous invocation). As you can see, this makes use of a Synchronizer, here to invoke (and handle) our (asynchronous) operation/command (i.e. RedisHashAsycnCommands.hgetall(..)).

The Synchronizer implementation was provided by the LettuceConnection back in the doInvoke(..) method, here. It is the 2nd argument to the LettuceInvoker constructor, with conditional construction based on whether we opened a pipeline, are inside a transaction, or we are simply executing the command and wish to "wait" for the result, here, and specifically here, then here.

Let's assume you are using the default execution path (i.e. not in an open pipeline or transaction (referred to as isQueueing() or isMulti by the LettuceConnection)). Then the Lettuce driver provides a means to handle the RedisFuture using a timeout (here) that you configure on the connection, and in this case, the LettuceConnection.

SOLUTION:

I think you can configure the timeout for operations on the LettuceConnection using the LettuceConnectionFactory.

For example:

@Configuration
class ApplicationRedisConfiguration {

  @Bean
  LettuceConnectionFactory redisConnectionFactory() {

    return new LettuceConnectionFactory(<redisConfigurationImpl>, LettuceClientConfiguration.builder()
      .commandTimeout(Duration.ofSeconds(30L));
  }
}

The <redisConfigurationImpl> could be any of [ RedisConfiguration, RedisClusterConfiguration, RedisSentinelConfiguration, RedisStandaloneConfiguration ] depending on your Redis topology arrangement.

See LettuceConnectionFactory constructors in Javadoc for more details.

See the LettuceClientConfiguration Javadoc for more details.

Based on the source of the LettuceClientConfiguration, it also appears that the timeout can be possibly configured in the Lettuce RedisURI (i.e. the connection URL used to connect to your Redis server(s)/cluster) as well. So you might want to double check how this is configured in your respective environments (DEV, TEST, PROD) as you may not see the same behavior in different environments since the configuration might vary significantly.

In summary...

Although, I am not 100% certain (I have not tested), I think you might be seeing null return values when the server(s)/cluster is loaded because 1) the operations/commands invoked inside SD Redis are executed "asynchronously" with the Lettuce driver and 2) the operation is timing out when the servers are loaded (due to a large number of requests). Therefore, I think you need to tune your client connection and possibly the Redis servers in your cluster, in this case.

The asynchronous invocation of Redis commands inside SD Redis is not something that is likely to change either.

Let me know if this helps or not.

Cheers!

[Hwan-seok]

Hi @jxblum! Thanks for the answer 😄

Seems the default command timeout is 60 seconds based on here.
So I don't understand that changing command timeout from 60s to 30s makes different in this situation.

Could you explain a little more details about command timeout? Thanks!

[mp911de]

If you use it like the above, there will be cases where there is no data even if there is data

It would be good for us if you could provide us with a minimal reproducer along with either an rdb file or a redis script to populate the redis data so we can investigate at which point a mismatch happens. Alternatively, you now have guidance in terms of invoked methods that you could debug yourself.

The asynchronous invocation of Redis commands inside SD Redis is not something that is likely to change either.

Lettuce uses an event-loop based I/O approach as general mode of operation. The synchronous/asynchronous/reactive APIs are merely a facade towards on top of the event loop. We simplified the design of using Lettuce over the years from mixed sync/async towards using the asynchronous API only. Previously, when we used the synchronous API, Lettuce enforced the synchronization timeout. Now Spring Data Redis applies the command timeout to the RedisFuture when waiting for a result.