Hi Dan,
may be it's a naive suggestion, did you think about have AHC
AsyncHandler per flow? So each AsyncHandler is aware of flaw and knows
how to dispatch the response.
If it's not you're looking for - it would be great to have more context
on what you're trying to achieve.
Thanks.
WBR,
Alexey.
On 07.04.15 18:13, Daniel Feist wrote:
> Hi,
>
> Looking for ideas for how I might do this:
>
> - I have a single shared Grizzzly/AHC 'client' instance.
> - This client can be used by multiple "flows" as it doesn't make sense
> to have multiple instances of AHC each with it's own set of selectors.
> - Each "flow" has it's own context, worker thread pool and error
> handling etc.
>
> Because further processing may occur in a given "flow" after a
> callback caused by a http response being recieved I want to be able to
> use the "flow's" thread pool, and not i) SameThreadIOStrategy ii) A
> WorkerThreadIOStrategy with a shared worker thread pool.
>
> I'm happy to create my own IOStrategy, thats a must, and I assume it's
> easy enough to
> implement org.glassfish.grizzly.strategies.AbstractIOStrategy#getThreadPoolFor()
> and pull the Flow/Executor instance from the connection context via an
> "Attribute".
>
> But where I'm stuck and could do with some ideas, is the best way to
> associate a "flow" or "Executor" instance with a given
> request/connection in the first place, so that I have it available in
> the connection context when the response comes back in. Ideally I'd
> be able to do this without hacking AHC GrizzlyHttpProvider, but if
> that's not possible then I might need to.
>
> thanks!
>
> Dan