[
https://issues.apache.org/jira/browse/THRIFT-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bradley Holbrook updated THRIFT-3218:
-------------------------------------
Summary: Large responses when using a MultiplexedProcessor fail to find
client after first read. (was: Large responses when using a
MultiplxedProcessor fail to find client after first read.)
> Large responses when using a MultiplexedProcessor fail to find client after
> first read.
> ---------------------------------------------------------------------------------------
>
> Key: THRIFT-3218
> URL: https://issues.apache.org/jira/browse/THRIFT-3218
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
> Affects Versions: 0.9.2
> Reporter: Bradley Holbrook
> Priority: Blocker
> Labels: easyfix, javascript
>
> Receiving a large response using a multiplexed processor fails to complete
> the read because the service is prematurely deleted in the connection data
> listener callback. Below shows the problem code and the solution deployed to
> solve it.
> {code:javascript|title=Original connection.js client creation}
> while (true) {
> var header = message.readMessageBegin();
> var dummy_seqid = header.rseqid * -1;
> var client = self.client;
> //The Multiplexed Protocol stores a hash of seqid to service names
> // in seqId2Service. If the SeqId is found in the hash we need to
> // lookup the appropriate client for this call.
> // The connection.client object is a single client object when not
> // multiplexing, when using multiplexing it is a service name keyed
> // hash of client objects.
> //NOTE: The 2 way interdependencies between protocols, transports,
> // connections and clients in the Node.js implementation are
> irregular
> // and make the implementation difficult to extend and maintain. We
> // should bring this stuff inline with typical thrift I/O stack
> // operation soon.
> // --ra
> var service_name = self.seqId2Service[header.rseqid];
> if (service_name) {
> client = self.client[service_name];
> delete self.seqId2Service[header.rseqid];
> }
> // ...
> }
> {code}
> {code:javascript|title=Working connection.js client creation}
> while (true) {
> var header = message.readMessageBegin();
> var dummy_seqid = header.rseqid * -1;
> var client = self.client;
> //The Multiplexed Protocol stores a hash of seqid to service names
> // in seqId2Service. If the SeqId is found in the hash we need to
> // lookup the appropriate client for this call.
> // The connection.client object is a single client object when not
> // multiplexing, when using multiplexing it is a service name keyed
> // hash of client objects.
> //NOTE: The 2 way interdependencies between protocols, transports,
> // connections and clients in the Node.js implementation are
> irregular
> // and make the implementation difficult to extend and maintain. We
> // should bring this stuff inline with typical thrift I/O stack
> // operation soon.
> // --ra
> var service_name = self.seqId2Service[header.rseqid];
> if (service_name) {
> client = self.client[service_name];
> }
> // ...
> }
> if(self.seqId2Service[header.rseqid]) {
> delete self.seqId2Service[header.rseqid];
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
