You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Eric Jensen (JIRA)" <ji...@apache.org> on 2010/02/24 17:22:27 UTC
[jira] Created: (THRIFT-714) maxWorkerThreads parameter to
THsHaServer has no effect
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
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.
[jira] Commented: (THRIFT-714) maxWorkerThreads parameter to
THsHaServer has no effect
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837897#action_12837897 ]
Bryan Duxbury commented on THRIFT-714:
--------------------------------------
Hm, good catch. I'll work up a fix when I have a moment.
> 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
> 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.
[jira] Updated: (THRIFT-714) maxWorkerThreads parameter to
THsHaServer has no effect
Posted by "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 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.
[jira] Assigned: (THRIFT-714) maxWorkerThreads parameter to
THsHaServer has no effect
Posted by "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 reassigned THRIFT-714:
------------------------------------
Assignee: Bryan Duxbury
> 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
> 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.
[jira] Commented: (THRIFT-714) maxWorkerThreads parameter to
THsHaServer has no effect
Posted by "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.
[jira] Closed: (THRIFT-714) maxWorkerThreads parameter to
THsHaServer has no effect
Posted by "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.