[
https://issues.apache.org/jira/browse/GERONIMO-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552830
]
Rick McGuire commented on GERONIMO-3707:
----------------------------------------
The previous comment was strangely posted by Jira...not sure what when wrong
there.
This is a fairly simple change to make, and having gone through the changes, I
question whether it's desirable to have the AsyncHttpClient perform the
lifecycle management. Currently, it is only performing that function for the
I/O thread pool, and not the even thread pool. Since the Executor is created
by the application and plugged in to the client, it seems wrong for the client
to be the one forcing it to close. This might have side effects on the
application if the application chooses to use the same thread pool for other
purposes.
> use Executor rather than ExecutorService for thread pools that are passed
> into AsyncHttpClient
> ----------------------------------------------------------------------------------------------
>
> Key: GERONIMO-3707
> URL: https://issues.apache.org/jira/browse/GERONIMO-3707
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
> Priority: Minor
>
> Currently AsyncHttpClient takes an ExecutorService as an argument for the
> thread pool that gets passed into the SocketConnector constructor. Also, it
> uses ExecutorService as the type for the event thread pool which is passed to
> the ExecutorFilter.
> In both cases, Mina APIs actually take simply Executor. Therefore, it is
> possible to simply pass in Executor rather than ExecutorService. This is
> very helpful because the caller may need to retrofit existing thread pool
> implementations. Implementing Executor is considerably easier than
> ExecutorService.
> One implication of this change is that AsyncHttpClient will no longer "own"
> and manage the thread pool that gets passed in. I believe that is also OK as
> the caller can (and perhaps should) handle the lifecycle of a thread pool
> that it created.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
