-
Notifications
You must be signed in to change notification settings - Fork 1.1k
FailoverClientConnectionFactory does not cache shared connection #3199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
garyrussell
added a commit
to garyrussell/spring-integration
that referenced
this issue
Feb 28, 2020
Resolves: spring-projects#3199 Previously, the FCCF did not cache a shared connection; if server 1 is down and server 2 is up, this caused an attempt to connect to server 1 every time we got the connection. Add 2 options: `refreshSharedInterval` and `closeOnRefresh`, defaulting to 0 and false respectively, to maintain the same behavior as before the options existed. Disallow caching of the single shared connection if the delegate factories are `CachingClientConnectionFactory` instances. **cherry-pick to 5.2.x** I will backport to 5.1.x, 4.3.x after review/merge.
artembilan
pushed a commit
that referenced
this issue
Feb 28, 2020
Resolves: #3199 Previously, the FCCF did not cache a shared connection; if server 1 is down and server 2 is up, this caused an attempt to connect to server 1 every time we got the connection. Add 2 options: `refreshSharedInterval` and `closeOnRefresh`, defaulting to 0 and false respectively, to maintain the same behavior as before the options existed. Disallow caching of the single shared connection if the delegate factories are `CachingClientConnectionFactory` instances. **cherry-pick to 5.2.x** I will backport to 5.1.x, 4.3.x after review/merge. * Polish javadocs and fix typo in docs
garyrussell
added a commit
that referenced
this issue
Feb 28, 2020
Resolves: #3199 Previously, the FCCF did not cache a shared connection; if server 1 is down and server 2 is up, this caused an attempt to connect to server 1 every time we got the connection. Add 2 options: `refreshSharedInterval` and `closeOnRefresh`, defaulting to 0 and false respectively, to maintain the same behavior as before the options existed. Disallow caching of the single shared connection if the delegate factories are `CachingClientConnectionFactory` instances. **cherry-pick to 5.2.x** I will backport to 5.1.x, 4.3.x after review/merge. * Polish javadocs and fix typo in docs
garyrussell
added a commit
that referenced
this issue
Feb 28, 2020
Resolves: #3199 Previously, the FCCF did not cache a shared connection; if server 1 is down and server 2 is up, this caused an attempt to connect to server 1 every time we got the connection. Add 2 options: `refreshSharedInterval` and `closeOnRefresh`, defaulting to 0 and false respectively, to maintain the same behavior as before the options existed. Disallow caching of the single shared connection if the delegate factories are `CachingClientConnectionFactory` instances. **cherry-pick to 5.2.x** I will backport to 5.1.x, 4.3.x after review/merge. * Polish javadocs and fix typo in docs
garyrussell
added a commit
that referenced
this issue
Feb 28, 2020
Resolves: #3199 Previously, the FCCF did not cache a shared connection; if server 1 is down and server 2 is up, this caused an attempt to connect to server 1 every time we got the connection. Add 2 options: `refreshSharedInterval` and `closeOnRefresh`, defaulting to 0 and false respectively, to maintain the same behavior as before the options existed. Disallow caching of the single shared connection if the delegate factories are `CachingClientConnectionFactory` instances. **cherry-pick to 5.2.x** I will backport to 5.1.x, 4.3.x after review/merge. * Polish javadocs and fix typo in docs
garyrussell
added a commit
that referenced
this issue
Feb 28, 2020
garyrussell
added a commit
that referenced
this issue
Feb 28, 2020
garyrussell
added a commit
that referenced
this issue
Feb 28, 2020
garyrussell
added a commit
to garyrussell/spring-integration
that referenced
this issue
Mar 2, 2020
Resolves spring-projects#3199 - change the default behavior to not fail back until the current connection fails - reduce method complexity (Sonar) - 5.3 only
garyrussell
added a commit
to garyrussell/spring-integration
that referenced
this issue
Mar 2, 2020
Resolves spring-projects#3199 - change the default behavior to not fail back until the current connection fails - reduce method complexity (Sonar) - 5.3 only
artembilan
pushed a commit
that referenced
this issue
Mar 2, 2020
Resolves #3199 - change the default behavior to not fail back until the current connection fails - reduce method complexity (Sonar) - 5.3 only
garyrussell
added a commit
that referenced
this issue
Mar 3, 2020
Long.MAX_VALUE does not prevent fail back. |
garyrussell
added a commit
to garyrussell/spring-integration
that referenced
this issue
Mar 5, 2020
Resolves spring-projects#3199 Wheen the `refreshSharedInterval` was `Long.MAX_VALUE` the test for whether the interval was exceeded always returned true. Use a boolean instead (already in place on master). I will backport to 5.1.x, 4.3.x after merge.
artembilan
pushed a commit
that referenced
this issue
Mar 5, 2020
Resolves #3199 Wheen the `refreshSharedInterval` was `Long.MAX_VALUE` the test for whether the interval was exceeded always returned true. Use a boolean instead (already in place on master). I will backport to 5.1.x, 4.3.x after merge.
garyrussell
added a commit
that referenced
this issue
Mar 5, 2020
Resolves #3199 When the `refreshSharedInterval` was `Long.MAX_VALUE` the test for whether the interval was exceeded always returned true. Use a boolean instead (already in place on master). I will backport to 5.1.x, 4.3.x after merge.
garyrussell
added a commit
that referenced
this issue
Mar 5, 2020
Resolves #3199 When the `refreshSharedInterval` was `Long.MAX_VALUE` the test for whether the interval was exceeded always returned true. Use a boolean instead (already in place on master). I will backport to 5.1.x, 4.3.x after merge.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://stackoverflow.com/questions/60432039/failoverclientconnectionfactory-connected-with-fail-over-server-but-still-tryin
The text was updated successfully, but these errors were encountered: