axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: HTTP connection management in Axis
Date Tue, 28 Sep 2010 14:23:21 GMT
What are actually valid use cases for explicitly setting one's own
HttpClient instance? With "valid" I mean use cases other than working
around the broken connection management in the HTTP transport?

Andreas

On Sat, Sep 18, 2010 at 10:51, Amila Suriarachchi
<amilasuriarachchi@gmail.com> wrote:
>
>
> On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <glen@thoughtcraft.com>
> wrote:
>>
>> (New thread for discussing $subject.)
>>
>> So, for 1.6 it would be great if we could finalize our HTTP management
>> stuff,
>> and have a clean set of APIs / patterns that we can have documented and
>> FAQ'ed.
>>
>> This thread can break off into sub-threads if desired, but things I think
>> we
>> need to get right include the following:
>>
>> * Do we re-use HTTPClient / MultithreadedHTTPConnectionManager by default?
>>
>> My answer here would be yes, but the code currently uses any MHCM that it
>> finds in the context hierarchy - so if you want to have a separate one
>> per-operation or per-message, you can just drop it in to the right
>> context.
>> I think it's critical that the default behavior is as friendly as possible
>> to
>> the common use-cases, though.
>
> So we need to define what the common use-case is.
>
> I think the httpClient look up algorithm should looks like this,
>
> looks for cached http client object and if found use it
> looks for cached MHCM object and if found create a new httpClient per
> invocation.
> if both options not available create a new http Client per invocation.
>
> All lookups should happen in the message context.
>
> So the default is to create new httpClient. This way users can override
> default option for high load situations.
>
> thanks,
> Amila.
>
>
>>
>> * Can we upgrade to HTTPClient v4?
>>
>> I haven't investigated this yet - has anyone played with this to know how
>> challenging or not the migration is?
>>
>> * Are our APIs good enough?
>>
>> In particular, can we offer enough flexibility to the end-user via
>> easy-to-understand APIs / properties?
>>
>> * Are our tests adequate?
>>
>> I think not yet.  We need at least to have small tests that prove re-use
>> is
>> working, tests for ServiceClient/OperationClient/Stubs, tests for
>> rejiggering
>> various properties, and ideally a full build will run a 5000-iteration
>> loop
>> sequence to test that the connection starvation problem hasn't snuck back
>> in
>> (particularly critical on Windows).
>>
>> * Other stuff?
>>
>> What am I missing?
>>
>> Thanks,
>> --G
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message