[
https://issues.apache.org/jira/browse/THRIFT-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-4190.
--------------------------------
Resolution: Fixed
Fix Version/s: 0.11.0
Committed.
> improve C# TThreadPoolServer defaults
> -------------------------------------
>
> Key: THRIFT-4190
> URL: https://issues.apache.org/jira/browse/THRIFT-4190
> Project: Thrift
> Issue Type: Improvement
> Components: C# - Library
> Reporter: Jens Geyer
> Assignee: Jens Geyer
> Fix For: 0.11.0
>
>
> The TThreadPoolServer uses hardcoded values to specify min/max number of
> threads, if the caller does not specify them. This is rather unexpected in my
> opinion, since the global C# ThreadPool (which is used internally) comes with
> its own defaults for all 4 values - yes, 4, not 2: there are different
> settings for the number of threads on one hand and the number of asyn IO
> completion ports on the other, and they are not necessary identical numbers.
> For example, on my machine I get these numbers by default:
> - min 4 threads and 4 I/O completion ports
> - max 37267 threads and 1000 I/O completion ports
> There are several *problems* with this approach:
> # There is really no way to bypass the defaults of min 10/10 and max 100/100
> that are hard-coded into TThreadPoolServer and use the defaults provided by
> the NET framework instead, since we can only pass number which is then used
> for threads AND io ports. In my example, no matter what value I pass, 37267
> or 1000, it will be something other than the defaults.
> # It is rather unexpected to have Thrift override the default settings of the
> global thread pool object if I don't even provide values by calling one of
> the simpler TThreadPoolServer CTORs.
> # I'm not sure where the defaults are come from. Both numbers look like wild
> guesswork to me. The defaults provided by the runtime make much more sense,
> as they automatically adapt to the machine's capabilities.
> My *proposal* to solve it comes in two parts:
> # Change the CTOR in a way that interprets 0 or negative values as intention
> to stick with the NET default settings. I think that is the best way to
> handle it, as the current implementation would just throw in a very defined
> way, so we don't get any compatibility conflicts here that pass undetectedly.
> # Additionally make the default values {{DEFAULT_MAX_THREADS}} and
> {{DEFAULT_MIN_THREADS}} both 0 (or negative) to enforce the system's
> defaults. Since this will be a breaking change, as it changes the current
> default behaviour, I'd like to know the opinions of the community before I
> commit that part of the changes.
> Further reference
> - [SetMinThreads
> method|https://msdn.microsoft.com/en-us/library/system.threading.threadpool.setminthreads(v=vs.110).aspx]
> - [SetMaxThreads
> method|https://msdn.microsoft.com/en-us/library/system.threading.threadpool.setmaxthreads(v=vs.110).aspx]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
