You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Xiaoshuang LU (JIRA)" <ji...@apache.org> on 2015/03/30 12:52:52 UTC

[jira] [Created] (THRIFT-3059) Performance issues of "TThreadedSelectorServer"

Xiaoshuang LU created THRIFT-3059:
-------------------------------------

             Summary: Performance issues of "TThreadedSelectorServer"
                 Key: THRIFT-3059
                 URL: https://issues.apache.org/jira/browse/THRIFT-3059
             Project: Thrift
          Issue Type: Improvement
          Components: Java - Library
    Affects Versions: 0.9.2
            Reporter: Xiaoshuang LU
            Priority: Critical


Assuming there is a client or a thread talks with "TThreadedSelectorServer" by a transport, no other clients or threads could send or receive data via this transport during this period, i.e. the transport is exclusive.  As a result, the performance/throughput  of the server could not be utilized as much as possible.

On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads?  As far as I know, the answer is negative.  Even we suppose that both reading messages from and writing messages to transport are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream.

We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)