[jira] [Updated] (THRIFT-3059) Performance issues of "TThreadedSelectorServer"
[ https://issues.apache.org/jira/browse/THRIFT-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-3059: -- Priority: Major (was: Critical) > 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: Major > > Let's assume that there is a client or a thread talks with > "TThreadedSelectorServer" by a transport. During this period, no other > clients or threads could send or receive data via this transport, 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? I am afraid that the > answer is negative. Even we suppose that both reading messages from > transports and writing messages to transports 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 (v7.6.3#76005)
[jira] [Updated] (THRIFT-3059) Performance issues of TThreadedSelectorServer
[ https://issues.apache.org/jira/browse/THRIFT-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaoshuang LU updated THRIFT-3059: -- Description: Let's assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, 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? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports 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. was: Let's Assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, 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? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports 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. 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 Let's assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, 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? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports 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)
[jira] [Updated] (THRIFT-3059) Performance issues of TThreadedSelectorServer
[ https://issues.apache.org/jira/browse/THRIFT-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaoshuang LU updated THRIFT-3059: -- Description: Let's Assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, 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? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports 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. was: 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. 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 Let's Assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, 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? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports 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)
