[ 
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)

Reply via email to