[
https://issues.apache.org/jira/browse/THRIFT-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16277868#comment-16277868
]
Chet Murthy edited comment on THRIFT-3877 at 12/5/17 3:07 AM:
--------------------------------------------------------------
James, wait, I'm not sure you want that.
(1) first, to echo back: you're proposing that a "oneway" be a roundtrip from
client to server's HTTP stack, but not all the way into the server's handler.
I think this is not what you'd want, and certainly not consistent with the
semantics that a oneway over the TCP transport provides.
EDIT: After all, the TCP transport doesn't even really guarantee that the
message left the client's kernel buffers, when it returns to the client
application, right?
EDIT2: Nor with the semantics of oneway over http in the cpp library, either.
(2) What I proposed, was that the client HTTP stack, would "somewhat lazily and
silently" consume the (as Jens notes) "possibly highly abbreviated responses"
from the server. If there's a buffer between the HTTP Transport and the
Protocol, this isn't hard to implement.
(3) I'd be a little leery of making a big change like switching to Boost.Beast,
without at least evaluating what Facebook's doing. Not because I think they're
doing the right thing, but b/c they at least have large-scale experience to
guide them.
was (Author: chetmurthy):
James, wait, I'm not sure you want that.
(1) first, to echo back: you're proposing that a "oneway" be a roundtrip from
client to server's HTTP stack, but not all the way into the server's handler.
I think this is not what you'd want, and certainly not consistent with the
semantics that a oneway over the TCP transport provides.
EDIT: After all, the TCP transport doesn't even really guarantee that the
message left the client's kernel buffers, when it returns to the client
application, right?
(2) What I proposed, was that the client HTTP stack, would "somewhat lazily and
silently" consume the (as Jens notes) "possibly highly abbreviated responses"
from the server. If there's a buffer between the HTTP Transport and the
Protocol, this isn't hard to implement.
(3) I'd be a little leery of making a big change like switching to Boost.Beast,
without at least evaluating what Facebook's doing. Not because I think they're
doing the right thing, but b/c they at least have large-scale experience to
guide them.
> 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)
