[ 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)