Project

General

Profile

Story #2246

refactor libclient_java connection management

Added by Rob Nahf almost 10 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
d1_libclient_java
Target version:
Start date:
2012-07-09
Due date:
% Done:

100%

Story Points:
Sprint:

Description

The current design of libclient_java connection management is inflexible, inefficient, and difficult to maintain.

Inflexible in that there is only one way of doing connection management, when in reality, different applications call for different strategies, for example in multithreading, timeout setting, etc.
Inefficient in that the current implementation opens and closes http connections and ssl sockets on each call. That places a higher load on the server, which has to spend more time performing handshakes than is necessary.
It's difficult to maintain, as each api method (55+) is responsible for handling connection close.

All advice is about use of HttpClient is for the application to share 1 instance of HttpClient and it's underlying HttpConnectionManager. This solves all three of the above problems, so the key is to implement without major change to the existing interface.

Accordingly, the proposed design changes are:

to share the httpClient within the D1Node method calls.

to implement the bridge pattern (to separate connection-management from service api logic) through addition of a new constructor: D1Node(String baseUrl, HttpClient client)

maintain backward compatibility by keeping the old constructor and providing a DefaultHttpClient

share the httpClient across D1Node instances by exposing the underlying httpClient (D1Node.getHttpClient()) and holding this shared httpClient in D1Client. All D1Nodes instantiated via D1Client will share the same httpClient instance (and it's connection manager)

upgrade to use apache HttpClient 4.2 (GA), released May 2012.

revisit the CLOSE_WAIT situation, and test to see if the CLOSE_WAIT problem reappears.


Subtasks

Task #3057: retest CLOSE_WAIT issue once the lib client is complete.In ProgressRob Nahf


Related issues

Related to Infrastructure - Bug #2211: Use of d1_libclient_java may lead to open file descriptors Closed 2012-01-19
Related to Java Client - Story #2253: refactor libclient_java communication to enable unit testing via mock client Rejected 2012-01-23 2015-01-06
Related to Java Client - Story #6509: libclient_java 2.0 Release Closed 2014-10-06

History

#1 Updated by Rob Nahf over 9 years ago

  • Milestone changed from None to CCI-1.1

needs to wait until after initial release. This is a high impact activity.

#2 Updated by Rob Nahf over 9 years ago

  • Milestone changed from CCI-1.1 to None
  • Priority changed from Low to Normal

#3 Updated by Rob Nahf over 7 years ago

  • Status changed from New to In Progress

created branches/d1_libclient_java_httpClient_refactor as a temporary work branch.
abstracted out HttpClient from the implementation to hand over control to the application. At this time the latest version of HttpClient is 4.3.3, and this version deprecated some of the classes we use for both HttpClient and setting up SSL.

#4 Updated by Robert Waltz over 7 years ago

  • Milestone changed from None to CCI-1.4
  • Product Version set to 1.4.0

#5 Updated by Robert Waltz about 7 years ago

  • Due date set to 2014-09-04
  • Target version set to Release Backlog
  • Start date set to 2014-09-04
  • Product Version changed from 1.4.0 to *

#6 Updated by Rob Nahf about 7 years ago

  • Due date changed from 2014-09-04 to 2014-09-23
  • Milestone changed from CCI-1.4 to CCI-2.0

#7 Updated by Rob Nahf about 7 years ago

  • Target version changed from Release Backlog to CCI-2.0.0
  • Due date changed from 2014-09-23 to 2014-09-24

#8 Updated by Rob Nahf about 7 years ago

  • Due date changed from 2014-10-02 to 2014-10-06
  • Product Version changed from * to 2.0.0

#9 Updated by Rob Nahf almost 7 years ago

  • Category deleted (d1_libclient_java)
  • Target version changed from CCI-2.0.0 to CLJ-2.0.0
  • % Done changed from 90 to 30
  • Project changed from Infrastructure to Java Client

#10 Updated by Rob Nahf almost 7 years ago

  • Category set to d1_libclient_java

#11 Updated by Rob Nahf over 6 years ago

  • % Done changed from 30 to 100
  • Status changed from In Progress to Closed

de facto closing - it's part of the libclient design.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)