Ok, so I got something working even though it's kinda ugly.
Why is it ugly:
- Feels like i'm abusing AsyncHandler to pass something through,
especaially given downcast is required.
- WorkerThreadIOStrategy cannot be extended due to private
constructor, so a lot of repeated code is requird for custom
implementation.
- HttpTransactionContext only has package level visability, so my
custom IOStrategy must be in the package
"com.ning.http.client.providers.grizzly" which isn't ideal.
Any futher ideas, would be very interesting to hear.
thanks!
Dan
On Thu, Apr 9, 2015 at 12:48 AM, Daniel Feist <dfeist_at_gmail.com> wrote:
> 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
>>
>>
>