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