[
https://issues.apache.org/jira/browse/THRIFT-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046285#comment-13046285
]
Steve Jiang commented on THRIFT-1167:
-------------------------------------
The sockets are currently owned by a single thread (assigned round-robin at
accept time) for the lifetime of the connection. The server allows overriding
"createSelectorThreadLoadBalancer" to provide a smarter assignment strategy.
However, this is only balancing at accept time so a particular thread may still
be assigned a disproportionate number of long-lived, high-throughput
connections but no worse than the current single select thread model.
I haven't run into this problem, but this could be changed so that there's an
opportunity to re-assign a connection whenever a request is completed. However,
that strategy might introduce more context switches in the non-problematic
cases. Did you have other ideas in mind?
> Java nonblocking server with more than one thread for select and handling IO
> ----------------------------------------------------------------------------
>
> Key: THRIFT-1167
> URL: https://issues.apache.org/jira/browse/THRIFT-1167
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Library
> Reporter: Steve Jiang
> Assignee: Bryan Duxbury
> Attachments: threadedselectorthrift3.diff
>
>
> I've used the HsHa server model to write a server that uses a thread for
> accept and a separate, configurable number of Selector threads to handle IO.
> I'd like to contribute this back to Thrift.
> For apps that are RPC-heavy and require little computation from the executor
> pool running on multi-core architectures, this server allows gets throughput
> as IO is not limited by one CPU.
> Please take a look at the attached patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
