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

Randy Abernethy reassigned THRIFT-3218:
---------------------------------------

    Assignee: Randy Abernethy

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

Reply via email to