You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upon upgrading to 3.32.0 from 3.23.1, a new feature was introduced to specify retryInterval, retryAttempts, timeout per Redisson object. However, this functionality was not introduced for the RJsonBucket when executing JSON commands (code link). I believe it should be commandExecutor.copy(params) to give the commandExecutor the overridden parameters from JsonBucketOptions. Can you confirm whether this is expected behavior to not invoke copy(params)? Thanks!
Also, a question on how connectTimeout is configured and behaves. If we specify a connectTimeout of 5000ms on client configuration (due to the scale of our Redis cluster for client initialization) and a timeout of 30ms (we are a latency sensitive service), what does this look like in terms of latency incurred on a request (i.e. a connection is not available in the connection pool, Redis server is unavailable, etc.)?
i.e. For retryAttempt = 2, will it always be requestTimeout == (Timeout + RetryInterval + Timeout + RetryInterval + Timeout) as the upper bound on max time on the API call (i.e. bucket.get())
Please let me know, I would be happy to provide any additional data to clarify :)
Best,
Jonathan
The text was updated successfully, but these errors were encountered:
Hi,
Upon upgrading to 3.32.0 from 3.23.1, a new feature was introduced to specify retryInterval, retryAttempts, timeout per Redisson object. However, this functionality was not introduced for the RJsonBucket when executing JSON commands (code link). I believe it should be
commandExecutor.copy(params)
to give thecommandExecutor
the overridden parameters from JsonBucketOptions. Can you confirm whether this is expected behavior to not invokecopy(params)
? Thanks!Also, a question on how
connectTimeout
is configured and behaves. If we specify a connectTimeout of 5000ms on client configuration (due to the scale of our Redis cluster for client initialization) and a timeout of 30ms (we are a latency sensitive service), what does this look like in terms of latency incurred on a request (i.e. a connection is not available in the connection pool, Redis server is unavailable, etc.)?i.e. For retryAttempt = 2, will it always be requestTimeout == (Timeout + RetryInterval + Timeout + RetryInterval + Timeout) as the upper bound on max time on the API call (i.e. bucket.get())
Please let me know, I would be happy to provide any additional data to clarify :)
Best,
Jonathan
The text was updated successfully, but these errors were encountered: