hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Question about IOReactorConfig.soTimeout and IOReactorConfig.ioThreadCount
Date Fri, 09 Nov 2012 22:19:38 GMT
On Fri, 2012-11-09 at 16:17 -0500, Sachin Nikumbh wrote:
> Hi Oleg,
> 
> Thanks a lot for your response.
> 
> > Hi,
> > >
> > > I am evaluating HTTP Async client and have following questions.
> > >
> > > How's IOReactorConfig.soTimeout different
> > > from CoreConnectionPNames.SO_TIMEOUT? I am looking into the code but it's
> > > not very obvious to me yet.
> >
> > IOReactorConfig applies to the lower level components (such as I/O
> > session components) whereas CoreConnectionPNames apply to the protocol
> > (HTTP level) components. CoreConnectionPNames and everything HttpParams
> > related will be deprecated in the next series of releases (4.3), which,
> > hopefully, should make HC configuration API more obvious and easier to
> > use.
> 
> 
> If this is the case, shouldn't the CoreConnectionPNames.SO_TIMEOUT value
> eventually drive IOReactorConfig.soTimeout? What if they have different
> values? While looking into the source, I didn't find a connection
> between CoreConnectionPNames.SO_TIMEOUT and IOReactorConfig.soTimeout. From
> my application point of view, which of these should I be setting? Which of
> these values will eventually cause a SocketTimeoutException? I have tested
> with CoreConnectionPNames.SO_TIMEOUT and it seems to be working. I haven't
> tried IOReactorConfig.soTimeout yet. If CoreConnectionPNames.SO_TIMEOUT is
> going to be deprecated, should I be using  IOReactorConfig.soTimeout?
> 

IOReactorConfig.soTimeout is used when the connection socket is
initialized by the i/o reactor. It can be overridden at a later point by
individual HTTP requests using CoreConnectionPNames.SO_TIMEOUT. Consider
IOReactorConfig as defaults.

> 
> 
> > >  Also, what parameter should be taken into
> > > account while setting value of IOReactorConfig.ioThreadCount? I see that
> > > it's being defaulted to number of processors. But if my client
> > application
> > > is going to generate hundreds of simultaneous requests, should I be
> > > changing this parameter?
> > >
> >
> > No, you should not. You do not want to have any CPU cores underutilized.
> > At the same time there is no point having more I/O selectors that the
> > CPU cores capable of running them.
> 
> 
> That makes sense. Say, I am on an 8 core machine (resulting in 8 threads)
> and have an application that makes 100 simultaneous requests (let's assume
> that it is always 100). Does it mean that at any given time only 8 requests
> will be executed with the rest being queued? 

No, it does not. Each individual i/o thread can handle thousands of
concurrent connections. That is the whole point of non-blocking i/o. You
just want to spread connections evenly across all available cores.

> Does it makes sense for me to
> increase the IOReactorConfig.ioThreadCount value? 

No, it does not.

> In response to one of my
> other posts, you have pointed out PoolingClientAsyncConnectionManager that
> should be used to control number of connections per address. I guess,
>  defaultMaxPerRoute/maxPerRoute properties of this class will also play a
> role in effective management of resources, right?
> 

Correct.

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message