-
Bug
-
Resolution: Done
-
Major
-
12.0.0.Final
-
None
The Java Hot Rod client has a maxRetries configuration option which tells it how many times to retry an operation after a failure (default: 10).
When the number of retries is exceeded, the client does not fail immediately: instead, it tries to switch to another site, and tries maxRetries times on the new site as well. The client doesn't keep track of the clusters it switched off of, so it seems possible to go in an infinite loop, switching from one site to the next.
If the client cannot switch to another site (e.g. because it was configured with a single site), it logs a debug message (`Cluster might have completely shut down, try resetting transport layer and topology id`) and tries the current site again for maxRetries times. So the actual number of retries with a single site is 2 * maxRetries (or 1, if maxRetries == 0).
Maybe automatic site switching is a good idea in some cases, but I'm not convinced it should be the default behaviour. At the very least, site switching should be decided at the remote cache manager level, when the client fails to open a new connection to any server in the current site, and not based on the number of retries done for any particular operation.
- is cloned by
-
JDG-4860 [8.3] Hot Rod java client retries too many times
- Closed
- is related to
-
ISPN-11630 Server and client get out of sync after multimap get with metadata operation
- Closed
-
ISPN-12596 Hotrod client tries to read one byte to much when Multimap returns KeyDoesNotExist
- Closed
-
ISPN-13264 Hot Rod client cluster switch never happens if max-retries < cluster size
- Closed
-
ISPN-5510 Provide better Hot Rod client socket timeout and retry defaults
- Closed
- relates to
-
ISPN-13216 Client should not close server connection after timeout
- Resolved
-
ISPN-13220 Initial server list switch should increment topology age
- Closed