You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Zezeng Wang (Jira)" <ji...@apache.org> on 2020/10/24 02:05:00 UTC

[jira] [Commented] (THRIFT-5297) Improve TThreadPoolServer Handling of Incoming Connections

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