Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Date: 18 Apr 2003 17:03:35 -0000
Message-ID: <20030418170335.25777.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: axis-dev@ws.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 19155] New:  -
    make CommonsHTTPSender connection pool, connections configurable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19155>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19155

make CommonsHTTPSender connection pool, connections configurable

           Summary: make CommonsHTTPSender connection pool, connections
                    configurable
           Product: Axis
           Version: 1.1rc2
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Basic Architecture
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: Eric.D.Friedman@wellsfargo.com


There's a comment (written by me) in CommonsHTTPSender that says we need to make
the size of the HTTP Commons connection pool configurable in addition to making
the connections themselves configurable (w.r.t timeouts and the like).  This bug
report is to track progress on this enhancement.

Dims suggested that the right way to do this was to extend the
TransportClientProperties model.  This sounds good, though I have some questions
about how exactly the committers would like to see this implemented:

Should we literally extend TransportClientProperties and its factory to add the
new configurable properties? or

should we create a new CommonsHttpClientProperties interface + factory that
resembles but is otherwise independent of the existing TransportClientProperties
implementation?

I'm inclined toward the latter, for what it's worth.

The following properties are the ones I think will need to be made configurable:

connectionsPerHost // how many open sockets can you have for a given host?
connectionPoolSize // how many total connections can you have open (note: this
isn't supported (yet) by commons httpclient, but it should be and so this might
be a reasonable placeholder

connectionPoolTimeout // how long will a thread wait for a connection from the pool?

soTimeout // timeout for network traffic (i.e. SO_TIMEOUT)

connectionTimeout // how long should HTTPClient be willing to wait when creating
a connection