[
https://issues.apache.org/jira/browse/THRIFT-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury updated THRIFT-714:
---------------------------------
Attachment: thrift-714.patch
After reading up on it some more, I think this change is what we actually want.
Up until the min number of threads, new "core" pool threads will be created.
Once we pass this limit, new threads will be created up to the max number of
threads, at which point the server will start rejecting executions. After
(default) 60 seconds of idleness, the pool will start to kill threads, but go
no lower than the min number of threads.
This patch is probably incomplete, as if we get a rejected execution exception
when trying to queue an invocation, we should respond to the client with an
error immediately.
> 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.
