Hi,
It looks like that may work..
I'd need to extend AsyncHandler and add a getWorkerExecutor() method to
it. Then in a custom 'FlowWorkerThreadPoolIOStrategy' grab the
HttpTransactionContext associated with the connection and then downcast the
AsyncHandler in order to obtain the Exectuor instance and use this instead
of the grizzly transport single shared worker thread pool.
I'm not trying to change anything significant, or have AHC work any
differently to normaly, just be able to specific the worker Executor that
will be used to process respones. Why do I want to do this? Well, it's
not stricly required, but by doing this I save the context switching or
parsing the request in the selector thread and then doing the thread hand
over later on when there is now more state.
The approach using AsyncHandler doesn't seem the most elegant, but other
than lots of signature changes I'm not sure of a better way that it would
be possible to pass this through.
Make sense?
Dan
On Wed, Apr 8, 2015 at 11:47 PM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> wrote:
> 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
>>
>
>