[
https://issues.apache.org/jira/browse/THRIFT-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16277831#comment-16277831
]
Chet Murthy commented on THRIFT-3877:
-------------------------------------
Jens,
I agree 100%. What we're looking for is a response of any kind: *any* kind.
One (incomplete) solution: keep a counter of how many "must-discard" responses
we expect from the server. When we send a roundtrip RPC, and are reading for
*its* response, first read-and-discard the must-discard ones.
The problem with this is that we might deadlock ourselves, if a client sends a
*ton* of oneway RPCs down a transport. So we'd need to (perhaps in the writer
flush() operation) check to see if there's data to read, and if so,
read-and-discard responses. As long as the HTTP transport read-side is
buffered, this works. So we'd need to always have a TBufferedTransport between
the HTTPClient and whatever protocol is being used.
At least, that's what seems to be needed. What do you think?
> C++: library don't work with HTTP (csharp server, cpp client; need cross test
> enhancement)
> ------------------------------------------------------------------------------------------
>
> Key: THRIFT-3877
> URL: https://issues.apache.org/jira/browse/THRIFT-3877
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.3, 0.10.0
> Environment: Windows 7, Visual Studio 2013 (C#), Qt 5.7 (MSVC 12).
> Thrift from git repo, SHA-1: 5a3f855b4e6882184f13c698855c877241144a12 (master)
> Reporter: Sergey Fasman
> Assignee: James E. King, III
> Priority: Critical
>
> Client on C++.
> Tested on C# HTTP server and client — work ideal.
> Then create client on C++. Client after request starts infinitly wait for
> data.
> For example, JSON protocol read data symbol by symbol, when trying read: it
> always try to call recv function (even all data already received).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
