[
https://issues.apache.org/jira/browse/THRIFT-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219996#comment-17219996
]
Zezeng Wang commented on THRIFT-5297:
-------------------------------------
Hi [~belugabehr],
I found tickets for this code THRIFT-1869, THRIFT-2046... Looks like there's
something else to do. You can check it out.
> 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: 10m
> 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.3.4#803005)
