Jumping on this again regarding the ability to customize AHC.
By default AHC creates a pool with a number of reaper threads that are set
to the number of available proc detected on a machine. This default can be
set globally via system properties, however short of doing that as a band
aid, if you cannot configure the config, assuming you have a fair number of
services to interact with in your app and you all have different
settings/timeout, etc,,,, it creates a massive number of threads (10
clients on a dual quadcore cpu will lead to 160 threads created)
(it's not exposed through the nonblocking client feature, so to be able to
configure this I needed to pretty much duplicate the entire code since
important classes are final)
The pattern that we have been doing for now across several http clients
impl to minimize resources generally involve having by default a shared
instance of the http client as a singleton so that low traffic service
clients with similar access pattern can share a common resource and if
needed we can configure service clients to have its own instance of a http
client (thus specific thread pool, etc... depending on http client impl. )
On Fri, Oct 12, 2012 at 10:11 AM, Stephane Bailliez <sbailliez_at_gmail.com>wrote:
> On Fri, Oct 12, 2012 at 6:37 AM, Marek Potociar <marek.potociar_at_oracle.com
> > wrote:
>
>>
>> Please check the 2.0 impl here if you want:
>> https://github.com/jersey/jersey
>> You may be interested in core-client and connectors/grizzly-connector
>> modules. As usual, we would appreciate your feedback.
>>
>
> Thanks ! wil try to check it out asap.
>
>
>> Other scenario is that we may want to substitute grizzly2 by netty
>> provider.
>>
>>
>> If I'm correct, there is some refactoring work being done in the Ning
>> client that should make it easier in the future (sometime soon). We'll then
>> need to update our Ning client connector integration code to be more
>> generic to accept any Ning transport provider. Btw., just curious - why do
>> you want to replace Grizzly with Netty? Let us know and I'll make sure to
>> forward your feedback to Grizzly guys so that thay know where they need to
>> improve.
>>
>
> There is not a specific technical reason (at least as of now) to do that
> between netty/grizzly, but generally I try to set an environment with
> libraries that are as homogeneous as possible.
>
> it takes a very long time to be familiar with a library codebase, its
> behavior in a variety of situations and the related tuning of it, so for
> example it would make sense to be able to stick to one single http lib
> rather than a service ending up using grizzly in one case, apache http
> client 4 in another, netty, commons http client or the jdk url... or at
> least trying to minimize it as much as possible.
>
> It can be hard to avoid that diversity of clients, but definitely offer
> some benefits, there are for example a lot of libraries that provides
> integrates only with commons http client while cxf has only a http
> transport based on the jdk url, so if you're using jersey client, you may
> be in a situation quickly where interacting to 3 services over http require
> you 3 different http libs... when in addition you already have some
> extensions that provide filtering or instrumentation for monitoring
> purposes, it can be helpful to not have to do 3 different implementations.
>
> -- stephane
>