[
https://issues.apache.org/jira/browse/THRIFT-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532709#comment-16532709
]
ASF GitHub Bot commented on THRIFT-4591:
----------------------------------------
jeking3 commented on issue #1566: THRIFT-4591:cannot read call result via lua
lib
URL: https://github.com/apache/thrift/pull/1566#issuecomment-402468549
I believe the error is in the implementation of TFramedTransport in the C++
library. Specifically, TFramedTransport readSlow() attempts to read a size off
the underlying transport and then attempts to read as much as possible from the
underlying transport. If it doesn't read the entire message indicated by the
size, it will return a partial read. The upper layer will then call readSlow
again, which will try to read another size off the wire, destroying message
integrity. It's amazing to see such a bug in code that's been around for a
long time. Funny thing is I have been adding support for message bus
transports based on TFramedTransport being correct, and obviously it is not.
So the lua library is just fine writing size and then writing payload. I
think that's still better than copying the size and payload into another buffer
(increasing memory requirements to write by 2x) and then writing all at once.
So you correctly identified there was a problem but the issue is on the C++
side, not on the lua side. If another client did the same thing, the C++
server would fail the same way.
That said, I'd like to take over this issue in Jira and I will fix
TFramedTransport, hopefully this week. My current employer is providing me
with the time to work on message bus support for thrift, and I need
TFramedTransport to work properly. In fact, I may add a test that specifically
targets this issue to see if it is present on any other library implementation.
I'm closing this PR as this change is not necessary. Thanks.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> cannot read call result via lua lib
> -----------------------------------
>
> Key: THRIFT-4591
> URL: https://issues.apache.org/jira/browse/THRIFT-4591
> Project: Thrift
> Issue Type: Bug
> Components: Lua - Library
> Affects Versions: 0.11.0
> Reporter: allen_lee
> Priority: Blocker
> Fix For: 0.12.0
>
> Attachments: 9090.pcap, 9090_1.pcap
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> 1) realize thrift server with TNonblockingServer via c++;
> 2) realize thrift client via lua lib and choose frame transport.
> 3) call remote interface failed with "TTransportException:0: Default
> (unknown)" print, and the server show "TConnection::workSocket():
> THRIFT_EAGAIN (unavailable resources)" error.
> 4)investigate this fault with tcpdump tool, attachment 9090.pcap show the
> frame msg doesnot contains frame size field, the rifht situation of
> attachment 9090_1.pcap show the frame msg contains 4 bytes (00 00 00 25)
> before protocol id field.
> 5) dig into the fault and tried to find root cause, then i found there is an
> fault in TFramedTransport:flush function in TFramedTransport.lua file. the
> original realization is:
> -----
> function TFramedTransport:flush()
> if self.doWrite == false then
> return self.trans:flush()
> end
> -- If the write fails we still want wBuf to be clear
> local tmp = self.wBuf
> self.wBuf = ''
> local frame_len_buf = libluabpack.bpack("i", string.len(tmp))
> self.trans:write(frame_len_buf)
> self.trans:write(tmp)
> self.trans:flush()
> end
> -----
> which send frame size file and reset msg content independently.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
