[
https://issues.apache.org/jira/browse/THRIFT-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Lamot updated THRIFT-2313:
---------------------------------
Attachment: 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
add patches
0001 -> fix this issue
0002 -> remove dependency upon Harmony as discussed
[here|https://issues.apache.org/jira/browse/THRIFT-2205?focusedCommentId=13867914&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13867914]
0003 -> split very long lines in nodes tests as suggested
[here|https://issues.apache.org/jira/browse/THRIFT-2205?focusedCommentId=13868263&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13868263]
> 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
> 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)
