[
https://issues.apache.org/jira/browse/THRIFT-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-4190:
-------------------------------
Description:
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]
was:
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 both 0 (or negative) to enforce the
system's defaults. Since this will be a breaking change, as it changes the
crrent 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]
> 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
>
> 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)
