[
https://issues.apache.org/jira/browse/THRIFT-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634885#comment-17634885
]
Stamatis Zampetakis commented on THRIFT-5297:
---------------------------------------------
Note that this is a breaking change with quite some impact. It changes the
existing behavior of the threadpool and also removes public APIs.
> Improve TThreadPoolServer Handling of Incoming Connections
> ----------------------------------------------------------
>
> Key: THRIFT-5297
> URL: https://issues.apache.org/jira/browse/THRIFT-5297
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
> Environment: th
> Reporter: David Mollitor
> Assignee: David Mollitor
> Priority: Major
> Fix For: 0.14.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> * Uses a confusing variable {{stopTimeoutVal}} to control TTL for threads in
> its thread pools. This configuration is also used to configure how long to
> wait for server to shutdown. Just set a reasonable default TTL and leave it
> at that unless someone can demonstrate a strong need
> * If the thread pool is full, there is a configurable back-off time waited
> for more room to become available in the pool. This adds a lot of complexity
> to the code and doesn't make a whole lot of sense. Any kind of back-off
> should be implemented on the client side. The server should simply reject
> requests if it is overloaded and allow the clients to back off. Right now,
> since the main thread has to sleep some number of milliseconds, it could be
> the case that N slots have opened in the pool, but the main thread is still
> waiting for its sleep cycle to end, thus wasting time. The behavior should
> be to simply reject the connection if the work queue is saturated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
