Memory leak through TcpSendingMessageHandler's connections map

[gigermocas]

TcpSendingMessageHandler connections map is not being cleared properly when using a TcpConnectionInterceptor and is causing a memory leak

From what I could ascertain, TcpConnectionSupport.close() doesn't see the tcp senders as they were registered on TcpConnectionInterceptor
A workaround involves overriding registerSenders() in the custom interceptor implementation:

@Override
public void registerSenders(List<TcpSender> sendersToRegister) {
	TcpConnectionSupport theConnection = getTheConnection();
	while (theConnection instanceof TcpConnectionInterceptorSupport) {
		theConnection = ((TcpConnectionInterceptorSupport) theConnection).getTheConnection();
	}
	theConnection.registerSenders(sendersToRegister);
}

I've created a sample project to replicate the issue:
spring-integration-ip-leak-test

Analysing the heap dump in Eclipse Memory Analyzer showed the following report:

One instance of "org.springframework.integration.ip.tcp.TcpSendingMessageHandler" loaded by "jdk.internal.loader.ClassLoaders$AppClassLoader @ 0x68c79c400" occupies 1,506,280 (17.24%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Node[]", loaded by "<system class loader>", which occupies 1,505,920 (17.24%) bytes.

Keywords
org.springframework.integration.ip.tcp.TcpSendingMessageHandler
jdk.internal.loader.ClassLoaders$AppClassLoader @ 0x68c79c400
java.util.concurrent.ConcurrentHashMap$Node[]

spring-integration version used is 5.4.4

[artembilan]

So, sounds like we have to fix it on that TcpConnectionInterceptorSupport.
We do have over there this one:

@Override
	public void registerSender(TcpSender sender) {
		this.tcpSender = sender;
		this.theConnection.registerSender(this);
	}

But looks like have missed to override newly introduced registerSenders().

Thank you for the report and we would appreciate if you issue a Pull Request with the fix and some tests to cover the problem!