jxblum
commented
1 year ago 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 theio.lettuce.core.api.StatefulConnectioninterface. 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](https://docs.spring.io/spring-data/redis/docs/current/api/org/springframework/data/redis/connection/lettuce/LettuceConnection.html#openPipeline()), are [inside a transaction](https://docs.spring.io/spring-data/redis/docs/current/api/org/springframework/data/redis/connection/lettuce/LettuceConnection.html#multi()), 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
mp911de
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 theio.lettuce.core.api.StatefulConnection.interface. Is it related?Is there a way to make the data reconciliation come out non-null?