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)
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.
Other scenario is that we may want to substitute grizzly2 by netty provider.
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 !
-- stephane