[
https://issues.apache.org/jira/browse/THRIFT-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury updated THRIFT-417:
---------------------------------
Attachment: thrift-417.patch
Ok, I think I've resolved the issue, at least partially. It comes down to the
fact that the pure-ruby binary protocol was calling "read_all" on its
transport, while the thrift_native version was calling "read". I'm still not
100% sure how this lead to an infinite loop, but hey, it was happening and now
it's not.
What I do know is that zero-length strings on the wire would cause
BinaryProtocolAccelerated to lock up the process trying to do reads. Switching
from read to read_all makes the problem go away. I should also note that
FramedTransport isn't affected by this issue, and a bare Socket will throw an
exception when you ask to read 0 bytes.
One thing we might want to consider is evaluating the contract of our read
methods. Should read(0) be a valid request? If so what should it return? It
seems to me in scenarios where you might call read(0), you could just check if
it's zero and skip the read. Not sure it'll make it that much cleaner, though.
Anyways, this patch contains the fix to the thrift_native READ macro. It also
adds 6 new test cases to the shared binary protocol specs, which required some
reorganization in DebugProtoTest.thrift. Finally, there is some minor cleanup
in binary_protocol_accelerated.c, removing some commented code and using the
native method table for one of the methods that was mistakenly omitted.
> BufferedTransport can enter an infinite loop
> --------------------------------------------
>
> Key: THRIFT-417
> URL: https://issues.apache.org/jira/browse/THRIFT-417
> Project: Thrift
> Issue Type: Bug
> Components: Library (Ruby)
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Priority: Blocker
> Fix For: 0.1
>
> Attachments: thrift-417.patch
>
>
> I'm not 100% sure of the circumstances yet, but it looks like if you ask
> BufferedTransport to read 0 bytes, you will enter an infinite loop. This may
> be particularly related to using the BinaryProtocolAccelerated protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
