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-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
