0

The code that is being referred to is under this question on codereview forum.

When you do this HttpClientPool.getClient().execute(request), r) in the query method, you have used the client to send the HttpRequest.. Don't you need to release / clean up any resources ?

Does the monitor thread's

while ((stopRequest = stopSignal.poll(5, TimeUnit.SECONDS)) == null) {
      // Close expired connections
      cm.closeExpiredConnections();
      // Optionally, close connections that have been idle too long.
      cm.closeIdleConnections(60, TimeUnit.SECONDS);
      // Look at pool stats.
      log.trace("Stats: {}", cm.getTotalStats());
    }

suffice to release the connection that is used by the client obtained from the pool.

A Few Questions :

  • Does this mean that we let the connection expire OR go idle for them to be reclaimed by the pool ?
  • What is the difference between expiry and going idle ?
  • How are the physical connections, Connection objects, ConnectionManager objects, HttpClient objects' life cycles maintained and what is the relation between them ?

Sorry about the amateur questions. I am new to HttpClient.

Community
  • 1
  • 1
acthota
  • 557
  • 5
  • 22
  • @OldCurmudgeon : I think you can provide the latest updated answer to the question : http://stackoverflow.com/questions/1281219/best-practice-to-use-httpclient-in-multithreaded-environment - Please check and reply. Your answer would definitely help others. – acthota Apr 14 '15 at 19:29

1 Answers1

2

The primary cleanup happens in the readResponse method where content.close(); and then response.close();.

The core of the mechanism is:

    // Start a conversation.
    CloseableHttpResponse response = HttpClientPool.getClient().execute(request);

getClient() pulls a CloseableHttpClient from the client pool. This is actually a Singleton thread-safe client an so does not need to be tidied up, it manages multiple uses internally.

execute executes the request and returns the CloseableHttpResponse for parsing and processing. This is cleaned up by calling close on it in readResponse. Note that it is closed in a finally clause to ensure it does not leak.

    // Roll out the results
    HttpEntity entity = response.getEntity();
    if (entity != null) {
      InputStream content = entity.getContent();

Within readResponse a new InputStream is created to gather the content of the response - this is also cleaned properly through closure in a finally clause.

The idle thread is only intended for hanging connections left by unexpected events, it is certainly not the primary cleanup mechanism.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
  • Sure. Will wait for your further updates to this answer. Thanks for looking into this. – acthota Apr 14 '15 at 19:37
  • Small correction: idle connection thread is intended to evict _idle_ connections which might have gone stale (half-closed) while sitting idly in the connection pool. +1 otherwise. – ok2c Apr 15 '15 at 09:07
  • @acthota - Details filled out - hope that is sufficient. – OldCurmudgeon Apr 15 '15 at 09:39