>> i) Why does sending of request occurs in selector thread and not a
>> worker thread when WorkerThreadIOStrategy is being used?
>
> It is initiated by user, so Grizzly just sends the message in whatever
> thread picked by user.
Yes, although when async connection and a completion handler is used,
this will actually use a grizzly selector thread rather than the
application thread. This makes sense though, and is after-all an
implementation choice.
>> ii) There appears to be a mismatch between use of worker thread for
>> response processing but not request processing and I'm unsure why if
>> there is only a limited number of selectors sending requests (say 4),
>> I'd want a thread pool of (say up to 200) workers to handle responses.
>
> In general, if we know the code is not blocking - we suggest to not do or do
> as less as possible thread-context switches.
> The asymmetry may be explained by the fact, that writing we perform is
> non-blocking, but response processing might be blocking and we don't want to
> block Selector thread.
Makes sense. In my scenario, which for now is blocking
request-response, I'll be using SameThreadIOStrategy given that
responses once parsed are simply set on a waiting future in
application thread.
What got me thinking about use of worker threads for request
processing and if the IOStrategy should be defining this was the
following code in AHC;
https://github.com/AsyncHttpClient/async-http-client/blob/master/providers/grizzly/src/main/java/org/asynchttpclient/providers/grizzly/FeedableBodyGenerator.java#L182
Here, regardless of the IOStrategy in use the worker threadpool is
accessed directly and used. This of course breaks when
SameThreadIOStrategy is used, and a ThreadPoolConfig needs to be set
manually.
thanks!
>
> Thanks.
>
> WBR,
> Alexey.