[
https://issues.apache.org/jira/browse/THRIFT-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539043#comment-17539043
]
Sylwester Lachiewicz commented on THRIFT-5297:
----------------------------------------------
merged to v0.14.0
[https://github.com/apache/thrift/commit/7ae1ec3f1eb3218f8b623232436bc986e3f1f5c8]
> 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
> 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.7#820007)
