Stubs & Options Configuration

[David Rees <dr...@gmail.com>]

Hi,

I'm using Axis2 1.4.1 and WSDL2Java created stubs to access a web service.

I'm trying to enable keep-alive and gzip encoding to reduce network
latency and improve throughput, but am not having any luck.

I would have expected to need to call
Stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED,
Boolean.FALSE) to get keep alive working from the documentation, but
then I realised that I'm not even seeing any chunked headers in the
request (it doesn't affect operation, either).

So what exactly do I need to do to get this working?  Anyone have a
code snippet or example?  My searches thus far have turned up blank.

Thanks!

Dave

Re: Stubs & Options Configuration

[keith chapman <ke...@gmail.com>]

Thanks Dave for posting your findings. I'm sure our users would appreciate
it.

Thanks,
Keith.

On Thu, Apr 23, 2009 at 7:42 AM, David Rees <dr...@gmail.com> wrote:

> On Wed, Apr 22, 2009 at 6:30 PM, David Rees <dr...@gmail.com> wrote:
> > OK, more reading and now I realize that keep-alive should be on by
> > default, but to get any performance benefit, I also need to
> > REUSE_HTTP_CLIENT.  So I've done that and yes, performance has
> > improved now, but I run into the default limit of only 2 concurrent
> > connections per host limit.
> >
> > How can I set my own MULTITHREAD_HTTP_CONNECTION_MANAGER or raise the
> > default limit?  This is a custom application so I am not worried about
> > exceeding RFC specifications for concurrent connections.
>
> Talking to myself a bit more, but I finally figured out how to do it
> with the help of this thread[1] on the axis-dev list.  The key is to
> set both REUSE_HTTP_CLIENT to true and CACHED_HTTP_CLIENT to my own
> HttpClient class.
>
> Here's what I am doing is pseudo code:
>
> Wrap the creation of new stubs in a function which then calls these
> functions:
>
> Options o = stub._getServiceClient().getOptions();
> o.setProperty(HTTPConstants.CHUNKED, Boolean.FALSE);
> o.setProperty(HTTPConstants.MC_ACCEPT_GZIP, Boolean.TRUE);
> o.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);
> o.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, getHttpClient());
>
> getHttpClient creates a cached HttpClient with my own
> MultiThreadedHttpConnectionManager:
>
> MultiThreadedHttpConnectionManager manager = new
> MultiThreadedHttpConnectionManager();
> manager.getParams().setDefaultMaxConnectionsPerHost(20);
> httpClient = new HttpClient(manager);
> httpClient.getParams().setVersion(HttpVersion.HTTP_1_1);
>
> So far this appears to work well and significantly reduces response
> time and improves performance when making a lot of requests in a row.
>
> Would be nice if this were documented somewhere official, but at least
> now it will be in the mail archives. :-)
>
> -Dave
>
> [1] http://markmail.org/message/e4wdlwgnkkttqiov
>



-- 
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/

blog: http://www.keith-chapman.org

Re: Stubs & Options Configuration

[David Rees <dr...@gmail.com>]

On Wed, Apr 22, 2009 at 6:30 PM, David Rees <dr...@gmail.com> wrote:
> OK, more reading and now I realize that keep-alive should be on by
> default, but to get any performance benefit, I also need to
> REUSE_HTTP_CLIENT.  So I've done that and yes, performance has
> improved now, but I run into the default limit of only 2 concurrent
> connections per host limit.
>
> How can I set my own MULTITHREAD_HTTP_CONNECTION_MANAGER or raise the
> default limit?  This is a custom application so I am not worried about
> exceeding RFC specifications for concurrent connections.

Talking to myself a bit more, but I finally figured out how to do it
with the help of this thread[1] on the axis-dev list.  The key is to
set both REUSE_HTTP_CLIENT to true and CACHED_HTTP_CLIENT to my own
HttpClient class.

Here's what I am doing is pseudo code:

Wrap the creation of new stubs in a function which then calls these functions:

Options o = stub._getServiceClient().getOptions();
o.setProperty(HTTPConstants.CHUNKED, Boolean.FALSE);
o.setProperty(HTTPConstants.MC_ACCEPT_GZIP, Boolean.TRUE);
o.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);
o.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, getHttpClient());

getHttpClient creates a cached HttpClient with my own
MultiThreadedHttpConnectionManager:

MultiThreadedHttpConnectionManager manager = new
MultiThreadedHttpConnectionManager();
manager.getParams().setDefaultMaxConnectionsPerHost(20);
httpClient = new HttpClient(manager);
httpClient.getParams().setVersion(HttpVersion.HTTP_1_1);

So far this appears to work well and significantly reduces response
time and improves performance when making a lot of requests in a row.

Would be nice if this were documented somewhere official, but at least
now it will be in the mail archives. :-)

-Dave

[1] http://markmail.org/message/e4wdlwgnkkttqiov

Re: Stubs & Options Configuration

[David Rees <dr...@gmail.com>]

On Wed, Apr 22, 2009 at 5:06 PM, David Rees <dr...@gmail.com> wrote:
> I would have expected to need to call
> Stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED,
> Boolean.FALSE) to get keep alive working from the documentation, but
> then I realised that I'm not even seeing any chunked headers in the
> request (it doesn't affect operation, either).

OK, more reading and now I realize that keep-alive should be on by
default, but to get any performance benefit, I also need to
REUSE_HTTP_CLIENT.  So I've done that and yes, performance has
improved now, but I run into the default limit of only 2 concurrent
connections per host limit.

How can I set my own MULTITHREAD_HTTP_CONNECTION_MANAGER or raise the
default limit?  This is a custom application so I am not worried about
exceeding RFC specifications for concurrent connections.

Is it as simple as
Stub._getServiceClient().getOptions().setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
myConnMan)?  Are there any gotchas I should keep in mind?

Thanks

Dave