HTTP connection management in Axis

[Glen Daniels <gl...@thoughtcraft.com>]

(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.

* 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

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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.
>
> * 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/

Re: HTTP connection management in Axis

[Andreas Veithen <an...@gmail.com>]

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
<am...@gmail.com> wrote:
>
>
> On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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

Re: HTTP connection management in Axis

[Andreas Veithen <an...@gmail.com>]

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
<am...@gmail.com> wrote:
>
>
> On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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

Re: HTTP connection management in Axis

[Andreas Veithen <an...@gmail.com>]

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
<am...@gmail.com> wrote:
>
>
> On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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

Re: HTTP connection management in Axis

[Andreas Veithen <an...@gmail.com>]

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
<am...@gmail.com> wrote:
>
>
> On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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

Re: HTTP connection management in Axis

[Andreas Veithen <an...@gmail.com>]

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
<am...@gmail.com> wrote:
>
>
> On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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.
>
> * 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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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.
>
> * 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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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.
>
> * 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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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/

Re: HTTP connection management in Axis

[Amila Suriarachchi <am...@gmail.com>]

On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <gl...@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.
>
> * 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/