Make HttpTransactionContext#getAsyncHandler public

[elrodro83]

In our application, we need to access the work manager, since we are using a custom implementation of org.glassfish.grizzly.strategies.AbstractIOStrategy to get the Executor we need.

Making this method public allows us to properly implement that.

[oleksiys]

Could you pls. share how exactly you update the strategy?
Did you try to modify the Executor via com.ning.http.client.providers.grizzly.TransportCustomizer?

    final GrizzlyAsyncHttpProviderConfig config = new GrizzlyAsyncHttpProviderConfig();
    config.addProperty(TRANSPORT_CUSTOMIZER, new TransportCustomizer() {
        @Override
        public void customize(TCPNIOTransport transport, FilterChainBuilder builder) {
               // modify transport here
        }
    });

[elrodro83]

Yes, that's what we're doing to set the strategy. Then, from within that strategy (on the getThreadPool() method), we need to get the asyncHandler that was sent with the request when calling

httpProvider.execute(request, asyncHandler);

since we are sending there the executor where the response has to be processed.

[slandelle]

Is this PR still valid?

[elrodro83]

Yes it is. Even if it won't be merged, we need to discuss how to obtain that object through another way.

[slandelle]

OK, I'll let @oleksiys handle this then :)

[LucianoGandini]

Hi @oleksiys we are near to a new release, did you have time to review this PR?
We'll really appreciate your help.

Thanks in advance.

[oleksiys]

Hi guys,

sorry for the delay, I'm currently on vacation. Will check and fix this next week.

Thank you!

[LucianoGandini]

Thank you Alexey, We'll wait for you to be back then, enjoy your vacations!

Best.

[oleksiys]

Hi guys,

I want to understand more your usecase. If you need all of these just to set the custom thread pool - there is easier way to do that.
Is there anything else you're concerned about besides thread pool?

[dfeist]

@oleksiys This was just to pass threadPool yes, which is not available statically. What other approach would you use for this?

[oleksiys]

@dfeist do you guys need to set a thread pool per request, or it's per client instance?

[dfeist]

@oleksiys Per-request. It's not there there is a new/different thread pool for each request of course, just that a single client is being reused for multiple 'flows' and each flow has it's own thread-pool, if that makes sense. The options I see are:
i) We use multiple client instances, which we want to avoid.
ii) We continue to use this hack
iii) We use SameThreadIOStrategy and do the thread hand-off to our own thread-pool only once HTTP client return, but the idea was to avoid this, and dispatch to worker thread as soon as possible.
iv) We work out a cleaner way to provide reference to Thread Pool per request.

[oleksiys]

Ok, I merge the pull request. I don't see better way to pass the request related information w/o changing AHC API.
Thank you guys!