[jira] Closed: (THRIFT-714) maxWorkerThreads parameter to THsHaServer has no effect

["Bryan Duxbury (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Duxbury closed THRIFT-714.
--------------------------------

    Fix Version/s: 0.4
       Resolution: Fixed

I committed a patch to remove maxWorkerThreads and rename minWorkerThreads to workerThreads. This will keep the behavior the same and remove the ineffectual parameter.

> maxWorkerThreads parameter to THsHaServer has no effect
> -------------------------------------------------------
>
>                 Key: THRIFT-714
>                 URL: https://issues.apache.org/jira/browse/THRIFT-714
>             Project: Thrift
>          Issue Type: Bug
>          Components: Library (Java)
>    Affects Versions: 0.2
>            Reporter: Eric Jensen
>            Assignee: Bryan Duxbury
>             Fix For: 0.4
>
>         Attachments: thrift-714.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> THsHaServer instantiates its ThreadPoolExecutor with a LinkedBlockingQueue.  That behavior is documented in java as:
> There are three general strategies for queuing:
> ...
>    2. Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to wait in the queue when all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.) This may be appropriate when each task is completely independent of others, so tasks cannot affect each others execution; for example, in a web page server. While this style of queuing can be useful in smoothing out transient bursts of requests, it admits the possibility of unbounded work queue growth when commands continue to arrive on average faster than they can be processed. 
> therefore changing maxWorkerThreads (passed as maximumPoolSize) has no effect.  The parameter should probably just be removed and minWorkerThreads renamed to numThreads, since setting minWorkerThreads does have an effect and is a workaround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.