You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2008/06/30 23:32:45 UTC

[jira] Assigned: (THRIFT-5) Need a thread pool server that is fair in terms of invocations, not sockets

     [ https://issues.apache.org/jira/browse/THRIFT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Duxbury reassigned THRIFT-5:
----------------------------------

    Assignee: Bryan Duxbury

> Need a thread pool server that is fair in terms of invocations, not sockets
> ---------------------------------------------------------------------------
>
>                 Key: THRIFT-5
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Library (Java)
>            Reporter: Bryan Duxbury
>            Assignee: Bryan Duxbury
>         Attachments: thrift-5-v2.patch, thrift-5-v3.patch, thrift-5-v4.patch, thrift-5-v6.patch, thrift-5-v7.patch, thrift-5.patch
>
>
> The current TThreadPoolServer in the Java libraries is suboptimal. If you actually limit the upper bound of threads, and you have long-lived clients, and you have more clients than you have max allowed threads, then any clients in excess of the max number of threads will never be given a time slice to execute. 
> Conceptually, it seems like the correct behavior here is for the individual method invocations to be the items that end up on the thread pool's execution queue, not the individual client sockets (as it is now). This would support this and other use cases better. 
> Perhaps we should do a Half-Sync/Half-Async server to fulfill this goal?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.