Skip to content

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

Closed
garyrussell opened this issue Feb 28, 2020 · 1 comment · Fixed by #3200 or #3206
Closed

FailoverClientConnectionFactory does not cache shared connection #3199

garyrussell opened this issue Feb 28, 2020 · 1 comment · Fixed by #3200 or #3206
Assignees
Milestone

Comments

@garyrussell
Copy link
Contributor

garyrussell commented Feb 28, 2020

See https://stackoverflow.com/questions/60432039/failoverclientconnectionfactory-connected-with-fail-over-server-but-still-tryin

@SpringBootApplication
@EnableScheduling
public class So60432039Application {

	public static void main(String[] args) {
		SpringApplication.run(So60432039Application.class, args);
	}

	@Bean
	public AbstractServerConnectionFactory server1() {
		return Tcp.netServer(1234).get();
	}

	@Bean
	public AbstractServerConnectionFactory server2() {
		AbstractServerConnectionFactory factory = Tcp.netServer(1235).get();
		factory.registerListener(m -> {
			System.out.println(m.getPayload());
			return false;
		});
		return factory;
	}

	@Bean
	public AbstractClientConnectionFactory client1() {
		return Tcp.netClient("localhost", 1234).get();
	}

	@Bean
	public AbstractClientConnectionFactory client2() {
		return Tcp.netClient("localhost", 1235).get();
	}

	@Bean
	public FailoverClientConnectionFactory failover() {
		FailoverClientConnectionFactory factory =
				new FailoverClientConnectionFactory(Arrays.asList(client1(), client2()));
		factory.registerListener(m -> false);
		return factory;
	}

	@Scheduled(fixedDelay = 5_000)
	public void getConnection() {
		try {
			TcpConnectionSupport connection = failover().getConnection();
			connection.send(new GenericMessage<>("foo"));
			System.out.println(connection.getConnectionId());
		}
		catch (InterruptedException e) {
			Thread.currentThread().interrupt();
		}
		catch (RuntimeException e) {
			System.out.println(e.getMessage());
		}
	}

	@Bean
	public ApplicationRunner runner() {
		return args -> {
			client1().start();
			client2().start();
			failover().start();
			System.out.println("Hit enter to start server2");
			System.in.read();
			server2().start();
		};
	}

}
@garyrussell garyrussell added this to the 5.3.M3 milestone Feb 28, 2020
@garyrussell garyrussell self-assigned this Feb 28, 2020
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 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
@garyrussell
Copy link
Contributor Author

Long.MAX_VALUE does not prevent fail back.

@garyrussell garyrussell reopened this Mar 5, 2020
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