You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Henrique Mendonça (JIRA)" <ji...@apache.org> on 2014/01/14 15:23:50 UTC

[jira] [Resolved] (THRIFT-2313) nodejs server crash after processing the first request when using MultiplexedProcessor/FramedBuffer/BinaryProtocol

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

Henrique Mendonça resolved THRIFT-2313.
---------------------------------------

    Resolution: Fixed

committed!
thanks for the patches Pierre! I had to change patch 3 a bit to apply it and also removed all the unnecessary tabs.

Cheers,
Henrique

> nodejs server crash after processing the first request when using MultiplexedProcessor/FramedBuffer/BinaryProtocol
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-2313
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2313
>             Project: Thrift
>          Issue Type: Bug
>          Components: Node.js - Library
>    Affects Versions: 0.9.1
>            Reporter: Pierre Lamot
>            Assignee: Henrique Mendonça
>             Fix For: 0.9.2
>
>         Attachments: 0001-THRIFT-2313-nodejs-server-crash-after-processing-the.patch, 0002-node-avoid-dependency-upon-harmony-Ecmas-in-multiple.patch, 0003-node-split-very-long-lines-in-tests.patch
>
>
> The problem is due to the way Protocols and Transports handle the end of streams.
> Basically what happens is that we read a first message correctly, then we try to read another message from the buffer we have no more data
> So, in TBinaryProtocol.readMessageBegin, we starts by reading an Int32 from the streambuffer, but as the buffer is empty, it return undefined, then the rest of the function is complete garbage (but it doesn't crash), so the exception is thrown from the processor. The MultiplexedProcessor see the error (by side effect), and throw a thrift.TException which is not catched by the server.
> It doesn't happens with:
>   - TBufferedTransport because ensureAvailable is called before each reads
>   - TJSONProtocol because we check for the stream length before reading it (borrow + readindex)
>   - Non Multiplexed Protocol: because MultiplexedPrcessor throw its own error (thrift.TException) which is not catched above, however what happens is that a thrift exception is thrown on the wire after *each* requests when using regularprocessor/framedtransport/binaryprotocol
> I think that the best way to handle it is to check that there is enough data before extracting it from the buffer in the functions TBinaryProtocol.readInt/String/.... and to throw a underbuffer error if necessary



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)