Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-9833

HttpComponentsHttpInvokerRequestExecutor does not explicitly release connection

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 3.1.2
    • Fix Version/s: 3.1.3, 3.2 RC1
    • Component/s: Remoting
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      We are using HttpComponentsHttpInvokerRequestExecutor with HttpClient v4.2.1 with PoolingClientConnectionManager. We notice in our live environment, that in case of an error, the connection is not gracefully released.
      I have attached a TestCase. The first one consumes the entity at the end (by default there are callback handler registered, which releases the connection after consuming the entity). Otherwise explicitly releasing connection is also possible to fix the problem.
      But currently the HttpComponentsHttpInvokerRequestExecutor does not consume the entity after an HTTP error (or releasing connection explicitly) so the connection is not released and not available for other requests.

        Issue Links

          Activity

          Hide
          gbrehmer Gerrit Brehmer added a comment -

          Fix is quite simple:

              protected RemoteInvocationResult doExecuteRequest(
                      HttpInvokerClientConfiguration config, ByteArrayOutputStream baos)
                      throws IOException, ClassNotFoundException {
           
                  HttpPost postMethod = createHttpPost(config);
                  setRequestBody(config, postMethod, baos);
                  try {
                      HttpResponse response = executeHttpPost(config, getHttpClient(), postMethod);
                      validateResponse(config, response);
                      InputStream responseBody = getResponseBody(config, response);
                      return readRemoteInvocationResult(responseBody, config.getCodebaseUrl());
                  } finally {
                      postMethod.releaseConnection();
                  }
              }

          Show
          gbrehmer Gerrit Brehmer added a comment - Fix is quite simple: protected RemoteInvocationResult doExecuteRequest( HttpInvokerClientConfiguration config, ByteArrayOutputStream baos) throws IOException, ClassNotFoundException {   HttpPost postMethod = createHttpPost(config); setRequestBody(config, postMethod, baos); try { HttpResponse response = executeHttpPost(config, getHttpClient(), postMethod); validateResponse(config, response); InputStream responseBody = getResponseBody(config, response); return readRemoteInvocationResult(responseBody, config.getCodebaseUrl()); } finally { postMethod.releaseConnection(); } }
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          Good catch! I've addressed this through using HttpComponents 4.2's PoolingClientConnectionManager and the HttpPost.releaseConnection() now, which also got introduced as late as HttpComponents 4.2. Since Spring 3.1 aims to be compatible with HttpComponents 4.0 and higher, we're calling the releaseConnection method reflectively there if available. Spring 3.2 requires HttpComponents 4.2, so it's more straightforward there.

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - Good catch! I've addressed this through using HttpComponents 4.2's PoolingClientConnectionManager and the HttpPost.releaseConnection() now, which also got introduced as late as HttpComponents 4.2. Since Spring 3.1 aims to be compatible with HttpComponents 4.0 and higher, we're calling the releaseConnection method reflectively there if available. Spring 3.2 requires HttpComponents 4.2, so it's more straightforward there. Juergen

            People

            • Assignee:
              juergen.hoeller Juergen Hoeller
              Reporter:
              gbrehmer Gerrit Brehmer
              Last updater:
              Chris Beams
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                5 years, 9 weeks, 2 days ago