[ 
https://issues.apache.org/jira/browse/THRIFT-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220954#comment-17220954
 ] 

Qinghui Xu commented on THRIFT-5297:
------------------------------------

Hello [~belugabehr] Thanks for bringing this up.
I though have a remark regarding to your proposal:
> 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
Is there some specific error code for this rejection? Otherwise I'm not sure 
how this would be possible for clients to decide to retry.

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

Reply via email to