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

["Bradley Holbrook (JIRA)" <ji...@apache.org>]

Bradley Holbrook created THRIFT-3218:
----------------------------------------

             Summary: Large responses when using a MultiplxedProcessor 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


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)