[
https://issues.apache.org/jira/browse/THRIFT-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wire updated THRIFT-4663:
-------------------------------
Description:
Originally encountered as a 500 error received from our server.
Investigating the logs on the server came up with this:
{{02:52:33 _elem152 = iprot.readString().decode('utf-8') if sys.version_info[0]
== 2 else iprot.readString()}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 184, in readString}}
{{02:52:33 return binary_to_str(self.readBinary())}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 233, in readBinary}}
{{02:52:33 self._check_string_length(size)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 47, in _check_string_length}}
{{02:52:33 self._check_length(self.string_length_limit, length)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 58, in _check_length}}
{{02:52:33 'Negative length: %d' % length)}}
{{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
-2147418111}}
It also turned out that this was hitting a different a different processor than
expected.
Upon inspection of the request in the browser client I noticed that the payload
was two processors concatenated together, in this particular case
'get_usersget_episodes'. The failure, I believe, is because it's executing the
get_users processor and trying to turn get_episodes into the parameters for
that processor.
Finally, we realized that we were trying to make get_users request with the
user_ids array (one of the parameters) containing only a null element. [null].
This request is never sent and seems to hang out waiting for the next request
to be sent.
I would expect thrift to send this poorly formed request, with the [null]
parameter, to the server where it could generate an exception or for it to
generate an exception on the client side that we can track. Having the
half-formed request payload sent along with the next request produced an issue
which was unnecessarily hard to root cause.
was:
Originally encountered as a 500 error received from our server.
Investigating the logs on the server came up with this:
{{02:52:33 _elem152 = iprot.readString().decode('utf-8') if sys.version_info[0]
== 2 else iprot.readString()}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 184, in readString}}
{{02:52:33 return binary_to_str(self.readBinary())}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 233, in readBinary}}
{{02:52:33 self._check_string_length(size)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 47, in _check_string_length}}
{{02:52:33 self._check_length(self.string_length_limit, length)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 58, in _check_length}}
{{02:52:33 'Negative length: %d' % length)}}
{{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
-2147418111}}
It also turned out that this was hitting a different a different processor than
expected.
Upon inspection of the request in the browser client I noticed that the payload
was two processors concatenated together, in this particular case
'get_usersget_episodes'. The failure, I believe, is because it's executing the
get_users processor and trying to turn get_episodes into the parameters for
that processor.
Finally, we realized that we were trying to make get_users request with the
user_ids array (one of the parameters) containing only a null element. [null].
This request is never sent and seems to hang out waiting for the next request
to be sent.
> Request payload is two endpoints concatenated together
> ------------------------------------------------------
>
> Key: THRIFT-4663
> URL: https://issues.apache.org/jira/browse/THRIFT-4663
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
> Affects Versions: 0.11.0
> Environment: Python backend
> React Javascript frontend
> Reporter: David Wire
> Priority: Major
>
> Originally encountered as a 500 error received from our server.
> Investigating the logs on the server came up with this:
> {{02:52:33 _elem152 = iprot.readString().decode('utf-8') if
> sys.version_info[0] == 2 else iprot.readString()}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
> line 184, in readString}}
> {{02:52:33 return binary_to_str(self.readBinary())}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
> line 233, in readBinary}}
> {{02:52:33 self._check_string_length(size)}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
> line 47, in _check_string_length}}
> {{02:52:33 self._check_length(self.string_length_limit, length)}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
> line 58, in _check_length}}
> {{02:52:33 'Negative length: %d' % length)}}
> {{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
> -2147418111}}
> It also turned out that this was hitting a different a different processor
> than expected.
> Upon inspection of the request in the browser client I noticed that the
> payload was two processors concatenated together, in this particular case
> 'get_usersget_episodes'. The failure, I believe, is because it's executing
> the get_users processor and trying to turn get_episodes into the parameters
> for that processor.
> Finally, we realized that we were trying to make get_users request with the
> user_ids array (one of the parameters) containing only a null element.
> [null]. This request is never sent and seems to hang out waiting for the next
> request to be sent.
> I would expect thrift to send this poorly formed request, with the [null]
> parameter, to the server where it could generate an exception or for it to
> generate an exception on the client side that we can track. Having the
> half-formed request payload sent along with the next request produced an
> issue which was unnecessarily hard to root cause.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
