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

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885984#action_12885984 ] 

Jonathan Ellis commented on THRIFT-714:
---------------------------------------

I'd rather have min threads = max threads, than reject requests just because we had a brief spike to more than min (queue size) + max (thread count).

Document it and it's a feature. :)

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