I usually post about HTTP stuff on Twitter - you can follow me there:

1. Overview

In this article, we will go over the basics of connection management within the HttpClient 4.

We’ll cover the use of BasichttpClientConnectionManager and PoolingHttpClientConnectionManager to enforce a safe, protocol compliant and efficient use of HTTP connections.

2. The BasicHttpClientConnectionManager for a Low Level, Single Threaded Connection

The BasicHttpClientConnectionManager is available since HttpClient 4.3.3 as the simplest implementation of an HTTP connection manager. It is used to create and manage a single connection that can only be used by one thread at a time.

Example 2.1. Getting a Connection Request for a Low Level Connection (HttpClientConnection)

BasicHttpClientConnectionManager connManager
 = new BasicHttpClientConnectionManager();
HttpRoute route = new HttpRoute(new HttpHost("www.baeldung.com", 80));
ConnectionRequest connRequest = connManager.requestConnection(route, null);

The requestConnection method gets from the manager a pool of connections for a specific route to connect to. The route parameter specifies a route of “proxy hops” to the target host, or the target host itself.

It is possible to execute a request using an HttpClientConnection directly, but keep in mind this low-level approach is verbose and difficult to manage. Low-level connections are useful to access socket and connection data such as timeouts and target host information, but for standard executions, the HttpClient is a much easier API to work against.

3. Using the PoolingHttpClientConnectionManager to Get and Manage a Pool of Multithreaded Connections

The PoolingHttpClientConnectionManager will create and manage a pool of connections for each route or target host we use. The default size of the pool of concurrent connections that can be open by the manager is 2 for each route or target host, and 20 for total open connections. First – let’s take a look at how to set up this connection manager on a simple HttpClient:

Example 3.1. Setting the PoolingHttpClientConnectionManager on a HttpClient

HttpClientConnectionManager poolingConnManager
  = new PoolingHttpClientConnectionManager();
CloseableHttpClient client
 = HttpClients.custom().setConnectionManager(poolingConnManager)
 .build();
client.execute(new HttpGet("/"));
assertTrue(poolingConnManager.getTotalStats().getLeased() == 1);

Next – let’s see how the same connection manager can be used by two HttpClients running in two different threads:

Example 3.2. Using Two HttpClients to Connect to One Target Host Each

HttpGet get1 = new HttpGet("/");
HttpGet get2 = new HttpGet("http://google.com"); 
PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager(); 
CloseableHttpClient client1 
  = HttpClients.custom().setConnectionManager(connManager).build();
CloseableHttpClient client2 
  = HttpClients.custom().setConnectionManager(connManager).build();

MultiHttpClientConnThread thread1
 = new MultiHttpClientConnThread(client1, get1); 
MultiHttpClientConnThread thread2
 = new MultiHttpClientConnThread(client2, get2); 
thread1.start();
thread2.start();
thread1.join();
thread2.join();

Notice that we’re using a very simple custom thread implementation – here it is:

Example 3.3. Custom Thread Executing a GET Request

public class MultiHttpClientConnThread extends Thread {
    private CloseableHttpClient client;
    private HttpGet get;
    
    // standard constructors
    public void run(){
        try {
            HttpResponse response = client.execute(get);  
            EntityUtils.consume(response.getEntity());
        } catch (ClientProtocolException ex) {    
        } catch (IOException ex) {
        }
    }
}

Notice the EntityUtils.consume(response.getEntity) call – necessary to consume the entire content of the response (entity) so that the manager can release the connection back to the pool.

4. Configure the Connection Manager

The defaults of the pooling connection manager are well chosen but – depending on your use case – may be too small. So – let’s take a look at how we can configure:

  • the total number of connections
  • the maximum number of connections per (any) route
  • the maximum number of connections per a single, specific route

Example 4.1. Increasing the Number of Connections that Can be Open and Managed Beyond the default Limits

PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager();
connManager.setMaxTotal(5);
connManager.setDefaultMaxPerRoute(4);
HttpHost host = new HttpHost("www.baeldung.com", 80);
connManager.setMaxPerRoute(new HttpRoute(host), 5);

Let’s recap the API:

  • setMaxTotal(int max): Set the maximum number of total open connections.
  • setDefaultMaxPerRoute(int max): Set the maximum number of concurrent connections per route, which is 2 by default.
  • setMaxPerRoute(int max): Set the total number of concurrent connections to a specific route, which is 2 by default.

So, without changing the default, we’re going to reach the limits of the connection manager quite easily – let’s see how that looks like:

Example 4.2. Using Threads to Execute Connections

HttpGet get = new HttpGet("http://www.baeldung.com");
PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager();
CloseableHttpClient client = HttpClients.custom().
    setConnectionManager(connManager).build();
MultiHttpClientConnThread thread1 
  = new MultiHttpClientConnThread(client, get);
MultiHttpClientConnThread thread2 
  = new MultiHttpClientConnThread(client, get);
MultiHttpClientConnThread thread3 
  = new MultiHttpClientConnThread(client, get);
thread1.start();
thread2.start();
thread3.start();
thread1.join();
thread2.join();
thread3.join();

As we’ve already discussed, the per host connection limit is 2 by default. So, in this example, we’re trying to have 3 threads make 3 requests to the same host, but only 2 connections will be allocated in parallel.

Let’s take a look at the logs – we have three threads running but only 2 leased connections:

[Thread-0] INFO  o.b.h.c.MultiHttpClientConnThread
 - Before - Leased Connections = 0
[Thread-1] INFO  o.b.h.c.MultiHttpClientConnThread
 - Before - Leased Connections = 0
[Thread-2] INFO  o.b.h.c.MultiHttpClientConnThread
 - Before - Leased Connections = 0
[Thread-2] INFO  o.b.h.c.MultiHttpClientConnThread
 - After - Leased Connections = 2
[Thread-0] INFO  o.b.h.c.MultiHttpClientConnThread
 - After - Leased Connections = 2

5. Connection Keep-Alive Strategy

Quoting the HttpClient 4.3.3. reference: “If the Keep-Alive header is not present in the response, HttpClient assumes the connection can be kept alive indefinitely.” (See the HttpClient Reference).

To get around this, and be able to manage dead connections we need a customized strategy implementation and build it into the HttpClient.

Example 5.1. A Custom Keep Alive Strategy

ConnectionKeepAliveStrategy myStrategy = new ConnectionKeepAliveStrategy() {
    @Override
    public long getKeepAliveDuration(HttpResponse response, HttpContext context) {
        HeaderElementIterator it = new BasicHeaderElementIterator
            (response.headerIterator(HTTP.CONN_KEEP_ALIVE));
        while (it.hasNext()) {
            HeaderElement he = it.nextElement();
            String param = he.getName();
            String value = he.getValue();
            if (value != null && param.equalsIgnoreCase
               ("timeout")) {
                return Long.parseLong(value) * 1000;
            }
        }
        return 5 * 1000;
    }
};

This strategy will first try to apply the host’s Keep-Alive policy stated in the header. If that information is not present in the response header it will keep alive connections for 5 seconds.

Now – let’s create a client with this custom strategy:

PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager();
CloseableHttpClient client = HttpClients.custom()
  .setKeepAliveStrategy(myStrategy)
  .setConnectionManager(connManager)
  .build();

6. Connection Persistence / Re-Use

The HTTP/1.1 Spec states that connections can be re-used if they have not been closed – this is known as connection persistence.

Once a connection is released by the manager it stays open for re-use. When using a BasicHttpClientConnectionManager, which can only mange a single connection, the connection must be released before it is leased back again:

Example 6.1. BasicHttpClientConnectionManager Connection Reuse

BasicHttpClientConnectionManager basicConnManager = 
    new BasicHttpClientConnectionManager();
HttpClientContext context = HttpClientContext.create();

// low level
HttpRoute route = new HttpRoute(new HttpHost("www.baeldung.com", 80));
ConnectionRequest connRequest = basicConnManager.requestConnection(route, null);
HttpClientConnection conn = connRequest.get(10, TimeUnit.SECONDS);
basicConnManager.connect(conn, route, 1000, context);
basicConnManager.routeComplete(conn, route, context);

HttpRequestExecutor exeRequest = new HttpRequestExecutor();
context.setTargetHost((new HttpHost("www.baeldung.com", 80)));
HttpGet get = new HttpGet("http://www.baeldung.com");
exeRequest.execute(get, conn, context);

basicConnManager.releaseConnection(conn, null, 1, TimeUnit.SECONDS);

// high level
CloseableHttpClient client = HttpClients.custom()
  .setConnectionManager(basicConnManager)
  .build();
client.execute(get);

Let’s take a look at what happens.

First – notice that we’re using a low-level connection first, just so that we have full control over when the connection gets released, then a normal higher level connection with a HttpClient. The complex low-level logic is not very relevant here – the only thing we care about is the releaseConnection call. That releases the only available connection and allows it to be reused.

Then, the client executes the GET request again with success. If we skip releasing the connection, we will get an IllegalStateException from the HttpClient:

java.lang.IllegalStateException: Connection is still allocated
  at o.a.h.u.Asserts.check(Asserts.java:34)
  at o.a.h.i.c.BasicHttpClientConnectionManager.getConnection
    (BasicHttpClientConnectionManager.java:248)

Note that the existing connection isn’t closed, just released and then re-used by the second request.

In contrast to the above example, The PoolingHttpClientConnectionManager allows connection re-use transparently without the need to release a connection implicitly:

Example 6.2. PoolingHttpClientConnectionManager: Re-Using Connections with Threads

HttpGet get = new HttpGet("http://echo.200please.com");
PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager();
connManager.setDefaultMaxPerRoute(5);
connManager.setMaxTotal(5);
CloseableHttpClient client = HttpClients.custom()
  .setConnectionManager(connManager)
  .build();
MultiHttpClientConnThread[] threads 
  = new  MultiHttpClientConnThread[10];
for(int i = 0; i < threads.length; i++){
    threads[i] = new MultiHttpClientConnThread(client, get, connManager);
}
for (MultiHttpClientConnThread thread: threads) {
     thread.start();
}
for (MultiHttpClientConnThread thread: threads) {
     thread.join(1000);     
}

The example above has 10 threads, executing 10 requests but only sharing 5 connections.

Of course, this example relies on the server’s Keep-Alive timeout. To make sure the connections don’t die before being re-used it is recommended to configure the client with a Keep-Alive strategy (See Example 5.1.).

7. Configuring Timeouts – Socket Timeout Using The Connection Manager

The only timeout that can be set at the time when connection manager is configured is the socket timeout:

Example 7.1. Setting Socket Timeout to 5 Seconds

HttpRoute route = new HttpRoute(new HttpHost("www.baeldung.com", 80));
PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager();
connManager.setSocketConfig(route.getTargetHost(),SocketConfig.custom().
    setSoTimeout(5000).build());

For a more in-depth discussion of timeouts in the HttpClient – see this.

8. Connection Eviction

Connection eviction is used to detect idle and expired connections and close them; there are two options to do this.

  1. Relying on the HttpClient to check if the connection is stale before executing a request. This is an expensive option that is not always reliable.
  2. Create a monitor thread to close idle and/or closed connections.

Example 8.1. Setting the HttpClient to Check for Stale Connections

PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager();
CloseableHttpClient client = HttpClients.custom().setDefaultRequestConfig(
    RequestConfig.custom().setStaleConnectionCheckEnabled(true).build()
).setConnectionManager(connManager).build();

Example 8.2. Using a Stale Connection Monitor Thread

PoolingHttpClientConnectionManager connManager 
  = new PoolingHttpClientConnectionManager();
CloseableHttpClient client = HttpClients.custom()
  .setConnectionManager(connManager).build();
IdleConnectionMonitorThread staleMonitor
 = new IdleConnectionMonitorThread(connManager);
staleMonitor.start();
staleMonitor.join(1000);

The IdleConnectionMonitorThread class is listed below:

public class IdleConnectionMonitorThread extends Thread {
    private final HttpClientConnectionManager connMgr;
    private volatile boolean shutdown;

    public IdleConnectionMonitorThread(
      PoolingHttpClientConnectionManager connMgr) {
        super();
        this.connMgr = connMgr;
    }
    @Override
    public void run() {
        try {
            while (!shutdown) {
                synchronized (this) {
                    wait(1000);
                    connMgr.closeExpiredConnections();
                    connMgr.closeIdleConnections(30, TimeUnit.SECONDS);
                }
            }
        } catch (InterruptedException ex) {
            shutdown();
        }
    }
    public void shutdown() {
        shutdown = true;
        synchronized (this) {
            notifyAll();
        }
    }
}

9. Connection Closing

A connection can be closed gracefully (an attempt to flush the output buffer prior to closing is made), or forcefully, by calling the shutdown method (the output buffer is not flushed).

To properly close connections we need to do all of the following:

  • consume and close the response (if closeable)
  • close the client
  • close and shut down the connection manager

Example 8.1. Closing Connection and Releasing Resources

connManager = new PoolingHttpClientConnectionManager();
CloseableHttpClient client = HttpClients.custom()
  .setConnectionManager(connManager).build();
HttpGet get = new HttpGet("http://google.com");
CloseableHttpResponse response = client.execute(get);

EntityUtils.consume(response.getEntity());
response.close();
client.close();
connManager.close();

If the manager is shut down without connections being closed already – all connections will be closed and all resources released.

It’s important to keep in mind that this will not flush any data that may have been ongoing for the existing connections.

10. Conclusion

In this article we discussed how to use the HTTP Connection Management API of HttpClient to handle the entire process of managing connections – from opening and allocating them, through managing their concurrent use by multiple agents, to finally closing them.

We saw how the BasicHttpClientConnectionManager is a simple solution to handle single connections, and how it can manage low-level connections. We also saw how the PoolingHttpClientConnectionManager combined with the HttpClient API provide for an efficient and protocol compliant uses of HTTP connections.

I usually post about HTTP stuff on Twitter - you can follow me there:


  • Sachin

    Hi, I am new to HttpClient lib and working on an existing framework which is on HttpClient 3.x version. Would you please tell me what benifits PoolledConnectionManager offers over ThreadSafeClientConnManager ?

    • Elena Eidson

      Hey Sachin, The ThreadSafeClientConnManager has been deprecated, and you should use the PoolingHttpClientConnectionManager instead.

  • Kisna

    How is poolinghttpclientconnectionmanager different from poolingclientconnectionmanager?

    • Hey Kisna – the difference between the two is simply that the first is now deprecated by the second. There were a lot of API changes between 4.2 and 4.3, and the introduction of some builders, more fluent utilities, etc in 4.3, and so, if you’re using 4.3 (or 4.4), it’s a good idea to use the PoolingHttpClientConnectionManager. Also – the deprecated versions are removed sooner or later – which is another reason to go with the non-deprecated version. Other than that – they’re quite similar.

      • Kisna

        Thanks so much, could not figure out if we really needed it for better performance or not

        • Kisna

          One more: does httpclient socket connection pooling benefit from massive retrieval of resources such as, say, images/files from CDN as they are all resource GETs from same client host to the same CDN host? especially given CDN will resolve to an optimized server (from many) based on location, availability, and other metrics and that server will handle the request?

          • Hey Kisna – that’s going to vary widely from case to case. My suggestion is – don’t try to make a determination based on general things about the client. Instead – test it out. You can use Jmeter (it delegates to HttpClient) or you can orchestrate your own test – but do a proper test and see how much of a difference it makes. Hope that helps. Cheers,
            Eugen.

  • Subhash Sreeram

    Can I benefit from PoolingHttpClientManager if multiple threads are connecting to same route. But calling different service:

    http://ww.xyz.com:7992/move/create?=id

    My rest service make call to following service for getting the information, for every request.

    http://ww.xyz.com:7990/setup/location/search?=
    http://ww.xyz.com:7991/inventory/container/search?=

    As per our current design, to request above services we does this.

    @singleton

    class getcontainer
    {
    private IRestClient restClient;
    getContianer(IrestClient restclient)
    {
    this.restClient = restclient;
    }
    resp = restclient.InvokeGetResource(xyz, wuv)
    }

    class RestClient implements IRestClient
    {
    InvokeGetResource(xyz, wuv)
    {
    webresource.get(uri);
    }
    }

    How does it help if I use poolinghttpconnection Manager

    • You can definitely make good use of the pooling manager regardless of the fact that you’re connecting to the same host or not.

  • Kisna

    One more :), do both PoolingClientConnectionManagers enable KeepAlive by default, because, I would assume the other side of client would want to terminate such long living connections abruptly most of the time or do this connection manager do some sort of a sanity check if connections are alive routinely and terminate/recycle them if it sees any issue? Is there any related configuration/settings to manage these times.

    • The releaseConnection API has a maximum period for which the connection will be kept alive, so it won’t be alive indefinitely. There is also a ConnectionKeepAliveStrategy if you need to fine-tune that behavior for the connection manager. Hope that helps. Cheers,
      Eugen.

      • Kisna

        Apparently, we keep getting
        java.net.SocketTimeoutException: Read timed out

        The next attempt works fine. I thought the httpclient-4.2.3 is supposed to know if the other side some thing else in between has dropped the connection?

        restTemplate = new RestTemplate(httpClientFactory);

  • rubi

    By calling response.close(), does it close and remove the connection from PoolingHttpClientConnectionManager or just release this connection to the pool? Thank you in advance.

    • It should close the connection – the pool has a mechanism responsible with creating new connections when needed.

      • Sanjoy

        Hello Eugen, great article, do you recommend closing the response after each execute method, as u say not closing the response will not close the connection and its better for the connection manager, what do you recommend and why ? I was of the impression that closing the response will return the connection to the pool.

        • So, there are a few different ways to release low level resources. You can either close the content stream – which will keep the connection alive, or you can close the response – which will shut down the connection. So – if your goal is to release the connection back to the pool for reuse, consuming and closing the content stream is the way to go. Here’s an interesting, in-depth exploration of this here. Hope it helps. Cheers,
          Eugen.

  • arobert

    Hello, I’m trying to create a class that handles the network interactions from our application. We need to send multiple XML documents to a solr server using an apache flume channel. Since the Apache flume is a little bit slower, we need to wait until it sends 100k records before continuing with the next set. But this wait can be of 15-20min. So when the application tries to start again, we get an error message “Broken pipe”. This results in a few 50 records getting lost in the way, they are never sent. But the application recovers after those 50 records.
    Is there a way to prevent the socket from closing during our time off?

    • Hey Arobert – interesting problem. An initial question is – can you decrease the batch size? That will help you deal with the long wait at least. Then – I’m assuming you’re using the HttpClient for this – but it may be worth looking into specific clients for the specific technologies you’re using – such as Flume, or a SOLR client, or even Spring Integration.
      Moving on to your open connection problem – there are ways you can indeed configure it – but you may instead want to look into a proper resource cleanup mechanism. Especially if you can decrease the batch size – and cleanup after your sends – a connection pool will get you a long way. Hope that helps. Cheers,
      Eugen.

      • arobert

        Thanks Eugen .
        Removing/minimizing the waiting time does help (since no data is lost), but sending smaller groups increases the job for the flume. And it takes longer to send all the data.
        I know we should be using the API from flume or Solr, but right now that is not an option.

        Thanks again for your help.
        Your article is really well written and helps a lot.

        • So – sending smaller batches of data may mean that the other side needs to be able to deal with these requests – yes. And that might mean scaling that part of the system. However, I think it’s the right thing to do – it’s usually easier to send out small batches and retry in case of failure. You can’t really do that if your batch is 100k – but you could easily do it if your batch is 1k for instance. Best of luck with getting it solved.

  • transcordia

    In section 9 you show a call to shutdown(). In the source code, shutdown() just calls close(), so I think that line can be omitted.
    connManager.close();
    connManager.shutdown();

    • Nice catch Transcordia – it’s definitely redundant – I’ll update that section. Thanks,
      Eugen.

  • Jaganath Devarajan

    Hi,

    Is there any real benefit in configuring a connection keep-alive strategy despite having a connection eviction strategy?

    • Jaganath Devarajan

      Hi Eugen,

      Can you please help with the above query? Doesn’t a connection evictions strategy by itself take care of broken connections? Do we still need to have a keep-alive strategy along with connection evication?

      • Keep-Alive is a separate concept and has another set of semantics than connection eviction. The idea behind keep-alive is basically to re-use the underlying TCP connection instead of creating a new one. The reason that’s important is simply because the TCP connection is an expensive resource so if you know you’re going to be using it again, it’s a good idea to reuse the already established one. Hope that helps. Cheers,
        Eugen.

        • Ivan Brencsics

          Hi Eugen! I have the same dilemma like Jaganath. I added a KeepAliveStrategy to my client, but by itself it does not seem to have any effect. The connections are still kept alive forever. On the contrary, using connection eviction with the IdleConnectionThread is doing the right thing, it is closing the pending connections. But it does it independently of the keep alive settings. To me the keep alive setting looks like having no effect at all on the connection life cycle.

          • Hey Ivan – since it looks like there’s a bit of confusion around this subject, I’m adding an article about HttpClient and KeepAlive to the content calendar of the site. Hope that will help – keep an eye on the RSS feed to get it when it comes out. Cheers,
            Eugen.

  • nala

    Hi,

    you explain some about using one connectionManager in two different http clients, and that works fine. But, what about using multiple connectionManagers in a single app i.e. have multiple httpclients with their own connection pools running in different threads? It seems on the top level, there shouldn’t be any problems, but I’m interested whether there could be any problems at the socket level, when creating all of them. For example say I have 10 http clients running in 10 different threads, with their own private instance of PoolingHttpClientConnectionManager, each of which maintains a pool of 20-30 connections. Does that mean all of them maintain the same 20-30 sockets, or separate ones?

    Or maybe someone suggest a way to test this?

    • Hey Nala – that’s an interesting question, and once that I’ve not written about here on the site. Yes – you always need to be aware of what’s happening at the OS level, in terms of connection handling. You’re right – if you run multiple connection pools, they’ll all be entirely separate – so no, nothing will be shared, and you’ll need to make sure you don’t hit any OS level limits.
      Now – that being said, I haven’t done any in-depth research into the possibility of the OS being smart enough to optimize the connection usage, since everything is coming out of the same JVM, hence the same process. So there’s always a possibility that there is actually an optimization that helps with the reuse of connections. Let me know if you find anything to that effect.
      Cheers,
      Eugen.

      • nala

        Great, thanks for the hints! I’ll look into it some more and see what I can find

  • Milind

    Hi,

    This is a nice information. Came to know few things that I am not aware of.

    We are currently facing an issue where Spring REST calls are hanging without any reason.
    Restemplate either make networks calls or to the same host. We recently started using HttpComponentsClientHttpRequestFactory(4.4.1 http client) with all defaults. Even the socket read and connection timeout is not set. Does that cause any issue?
    I see in netstat out many connections in CLOSE_WAIT state.

    @Bean
    public RestTemplate restTemplate() throws Exception {
    SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, new TrustSelfSignedStrategy()).build();
    SSLConnectionSocketFactory sslConnectionSocketFactory =
    new SSLConnectionSocketFactory(sslContext, new NoopHostnameVerifier());
    HttpClient httpClient = HttpClientBuilder.create(). useSystemProperties().setSSLSocketFactory(sslConnectionSocketFactory).build();
    HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(httpClient);
    factory.setReadTimeout(0);
    factory.setConnectTimeout(0);
    return new RestTemplate(factory);
    }

    • Hey Milind,
      The best way to ask this kind of very practical, code-focused question is to first isolate the problem in a sample project. That should be as simple as you can get it as long as it’s still reproducing the issue.
      Then, post the question over on StackOverflow and email me the link – I’d be happy to have a look. Cheers,
      Eugen.

  • bedew

    Hi,

    first, thank you for the amazing post, from which I really learnt a lot.
    Here though I have some confusions about several points in your post, and I hope you could clarify them for me. It’d be very appreciated.

    In chapter 5, you said that keep-alive strategy is based on the non-standard ‘Keep-Alive’ response header. In case of ‘Keep-Alive’ missing, however, connection is likely to be given to consumer while it has been closed by its peer end (perhaps the custom keep-alive strategy is too optimistic, setting a rather long duration, which is longer than that of server side). What I want to substantiate is what will happen in this case. Will connection manager handle it for me?

    And the same thing could happen to chapter 8 – when the connection is closed by peer end in between two eviction call, consumer will still get a broken connection. If I’m right, then will connection manager handle it for me, or just an exception thrown?

    And finally, why is the first option of connection eviction not reliable? I think checking the connection right before using it is definitely safer and more efficient than checking it repetitively, especially when the interval between each check is relatively long.

    Thanks again, really appreciate your help in this post.

    • If the connection is not persistent, then there’s no chance of a connection being handed to a client while being closed. Any connection that’s being handed to the client will be new in that case.

      Now – negotiation of the close conditions is an interesting topic – but that’s going to be very client and server specific. Generally speaking, the client can request certain conditions, but if these are larger than what the server supports – you’ll have to see exactly what your particular server is configured to do.

      Finally – let’s talk about race conditions. Persistent connections are all about the underlying TCP connection – with HTTP sitting on top of that. In the case of a race condition where you have the TCP connection being closed right when the client sends a request – I’m not entirely sure what happens. There is a ConnectionKeepAliveStrategy you can have a look at, but I would expect an exception in that case – although it’s definitely something I recommend you try to test for yourself.

      Hope that helps. Cheers,
      Eugen.

  • Varun

    Hi Eugen,

    Thanks for your informative posts!

    I am curious to know whether the PoolingHttpClientConnectionManager specifically needs to be used in a multithreaded fashion as implemented in MultiHttpClientConnThread to be able to benefit from its client pools and connection reusability.

    Or can the CloseableHttpClient object that is built with a pooling manager be passed to any caller (GET requester) and the connection manager will handle all the underlying pooling and threading complexities ? (Avoiding the getThread essentialy)

    Also, is the IdleConnectionMonitorThread a best practice for evicting connections ? I’ve seen it in a few posts and again I thought the PoolingHttpClientManager would do evict connections internally without further configuration.

    Thanks,
    Varun

    • Hey Varun,
      You can certainly use a connection pool with a single threaded system – yes. They’re entirely unconnected.
      Cheers,
      Eugen.