On Oct 12, 2012, at 6:46 AM, Stephane Bailliez <sbailliez_at_gmail.com> wrote:
> Hi,
>
> Just wanted to give some quick feedback on the current implementation of the non blocking client in the contribs module.
> I hope it may give some directions for the 2.0 implementation. (didn't check the code yet)
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.
> The current design in contrib prevents any override of the ning provider or even enhance the configuration of the asynchttpclient before creating an instance.
> This can be a bit problematic as one may need to be able to modify it in a heavy service-based environment, so some hooks are necessary.
> Right now if I want to modify it, I unfortunately need to copy/paste pretty much the entire non-blocking client code base and bring it into our ownlibrary.
>
> For example in our case it is not unusual to have a dozen of services with which one service interact, which means a dozen of clients, which all have different settings in term of timeout, pool size, etc...
> As a default asynchttpclient will create a pool size for the reaper threads equals to the number of detected cpu on the server... for a server with dual quad core cpus that means it will end up 16 threads. Multiply that by 10 clients and you may have 160 threads hanging in there not doing much. One could use system properties to workaround this but as this is global to the jvm this may also not be suitable.
I hear you. It would be good if you could open a Jira enhancement request (
http://java.net/jira/browse/jersey) and attach this feedback in a form of a list of configuration options you would like us to expose. Such feedback based on real-life experiences would help us a lot in exposing a more flexible and meaningful client configuration options.
>
> 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.
> Or we may have some specific extension related to async httpclient or one of the provider that we want to reuse.
>
> Hope that makes sense !
Totally!
Marek
>
> -- stephane