[
https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin....
]
Wolf-Dieter Fink commented on ISPN-3947:
----------------------------------------
Initially my idea was to have both,
max-per-server to prevent from retrying the same server x-times
max-in-total to stop after a number of retries in a big cluster
so retries = max-in-total > (max-per-server*noOfServers) ?
(max-per-server*noOfServers) : max-in-total
In this case it is ensured that there is a threshold of retries but it's possible to
try each server in a growing cluster.
But I think it will be difficult to set the retries independent from a bit environment
knowlege ;)
HotRod client keep trying recover connections to a failed cluster
-----------------------------------------------------------------
Key: ISPN-3947
URL:
https://issues.jboss.org/browse/ISPN-3947
Project: Infinispan
Issue Type: Feature Request
Components: Remote Protocols
Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
Reporter: Wolf-Dieter Fink
Assignee: Galder ZamarreƱo
Labels: hotrod, hotrod-java-client
If an infinispan-server cluster is not longer reachable for some reason, i.e. network
disconnect, the hot-rod client try to re-establish the lost connections.
The client library will retry this by a fixed calculation based on the max numbers of
connections from the pool or 10 multiplied with the number of available servers.
This can lead in a very long time until the application can continue and react as it will
wait for the read- or connect-timeout for each try.
To improve this behaviour there should be a configurable limit of retries per server
and/or a timeout in total.
This will give the application the chance to handle a remote-cache failure and reply to
the user instead of hanging for minutes (with the default settings)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira