[
https://issues.apache.org/jira/browse/THRIFT-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870811#comment-13870811
]
Hudson commented on THRIFT-2313:
--------------------------------
SUCCESS: Integrated in Thrift #1001 (See
[https://builds.apache.org/job/Thrift/1001/])
THRIFT-2313 nodejs server crash after processing the first request when using
MultiplexedProcessor/FramedBuffer/BinaryProtocol (henrique: rev
216374ec4a72cbabf7c76dd9284362aba4d30f1c)
* test/nodejs/multiplex_client.js
* test/nodejs/thrift_test_driver.js
* test/nodejs/Makefile.am
* lib/nodejs/lib/thrift/transport.js
* lib/nodejs/lib/thrift/multiplexed_processor.js
> 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)
