[jira] [Updated] (THRIFT-3218) Large responses when using a MultiplexedProcessor fail to find client after first read.

["James E. King III (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James E. King III updated THRIFT-3218:
--------------------------------------
    Priority: Major  (was: Critical)

> 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
>            Assignee: Randy Abernethy
>            Priority: Major
>              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
(v7.6.14#76016)