Hi,
I believe I fully understanding the use of IOStrategies when using
Grizzly as a Http Server, and am currently using the
WorkerThreadIOStrategy given that handling of http requests will not
be non-blocking in my scenario. It is also clear that with this
strategy a worker thread will be used to handle READ and CLOSE
IOEvents, but not ACCEPT events. This all makes sense.
That said, I'm slightly confused about the role of IOStrategies in
Client scenarios, particularly with the WorkerThreadIOStrategy:
- From examples I see that client implementations typically call
ctx.write to send the http request within an CompletionHandler after
asycronously establishing a connection.
- With this approach the kernal thread pool is used for the async
connection, but is also then used to perform the ctx.write including
HttpFilter processing etc. (this is because WorkerThreadIOStrategy
only provides threadpool for READ/CLOSE events).
- When the response is recieved from the remote server, this is a READ
event, and so the WorkerThreadIOStrategy provides workers such that
each response is handed off to a worker thread before HttpFilter is
processed.
What seems strange about this when using:
i) Why does sending of request occurs in selector thread and not a
worker thread when WorkerThreadIOStrategy is being used?
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.
Make sense? Is anyone able to shed any light on this?
thanks again,
Dan