geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick McGuire (JIRA)" <>
Subject [jira] Commented: (GERONIMO-3707) use Executor rather than ExecutorService for thread pools that are passed into AsyncHttpClient
Date Tue, 18 Dec 2007 17:36:49 GMT


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:
>             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.

View raw message