Community
Participate
Working Groups
Build Identifier: jetty-client-7.4.5.v20110725.jar Package org.eclipse.jetty.client The Jetty HttpClient, when connectorType is set to CONNECTOR_SELECT_CHANNEL creates a connector of type SelectConnector SelectConnector has a HashMap of ConnectTimeout tasks for connections that time out. This hash map is called _connectingChannels. The Eclipse Memory Analyzer illustrates that _connectingChannels is holding onto Timeout Tasks that in turn reference exchanges, sockets, and destination classes. I went to an eclipse mirror web site and grabbed the code for jetty.client. SelectConnector.java. https://oss.sonatype.org/content/groups/jetty/org/eclipse/jetty/jetty-client/7.4.5.v20110725/ if (!_httpClient.isConnectBlocking()) { channel.configureBlocking( false ); channel.connect(address.toSocketAddress()); _selectorManager.register( channel, destination ); ConnectTimeout connectTimeout = new ConnectTimeout(channel, destination); _httpClient.schedule(connectTimeout,_httpClient.getConnectTimeout()); _connectingChannels.put(channel, connectTimeout); There is only one method which removes the entry and that only happens on a successful connection. protected SelectChannelEndPoint newEndPoint(SocketChannel channel, SelectSet selectSet, SelectionKey key) throws IOException { // We're connected, cancel the connect timeout Timeout.Task connectTimeout = _connectingChannels.remove(channel); if (connectTimeout != null) connectTimeout.cancel() On exceptions or actual timeouts, I do not believe there is code to remove the hashmap entry. Thus, I patched the source file, and fixed my symptoms. Patch will be attached. Reproducible: Always Steps to Reproduce: 1. use select connector in non-blocking mode 2. attempt to send asynchronous request to a non-responding address 3. use eclipse memory analyzer to illustrate that _connectingChannels has a memory leak.
Created attachment 205561 [details] A copy of my file that fixed the memory leak for me
I like issues with patches!
fixed for 7.5.4