[
https://issues.apache.org/jira/browse/THRIFT-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636905#comment-14636905
]
Dylan Wen edited comment on THRIFT-3251 at 7/22/15 1:34 PM:
------------------------------------------------------------
net/http in standard libraray handles both http protocol and
connections/goroutine concurrency for a server. While current Go lib in Thrift
provides connections/goroutine concurrency handling only. To make Go server
communicate with http client(such as C++ async client in my case), we could
wrap Thrift RPC to call net/http lib, or add http protocol parsing to existing
SimpleServer codes.
It seems the later choice would be a minor change, since it would seamlessly
reuse most of the existing Server/Protocol layers codes, e.g.
Framed/BinaryProtocol. And it just requires to add basic http protocol
parsing(not supporting the complete http protocol, so no TLS or other stuff):
spliting header and body, supporting content length and chunk. The similiar
codes in C++ is in the repository for a long time. It sounded not a lot of
effort for me do that in Go and I just did it. After it's done, all I have to
do for switching the transport is to modify the default transport factory's
name, thanks to Thrift's clear and extendable design, and it works pretty fine
with C++ async client now.
I agree that using net/http in Go standard library is better in the long term.
To get it done, it seems we need to wrap the existing Protocols and map
http.Handler to the compiler generated RPC codes(changing the compiler behavior
is necessary?) What progress is it of THRIFT-3186 now? I'm happy to see its
accomplishment and adapt my application to it.
was (Author: hhkbp2):
net/http in standard libraray handles both http protocol and
connections/goroutine concurrency for a server. While current Go lib in Thrift
provides connections/goroutine concurrency handling only. To make Go server
communicate with http client(such as C++ async client in my case), we could
wrap Thrift RPC to call net/http lib, or add http protocol parsing to existing
SimpleServer codes.
It seems the later choice would be a minor change, since it would seamlessly
reuse most of the existing Server/Protocol layers codes, e.g.
Framed/BinaryProtocol. And it just requires to add basic http protocol
parsing(not supporting the complete http protocol, so no TLS or other stuff):
spliting header and body, supporting content length and chunk. The similiar
codes in C++ is in the repository long time ago. It sounded not a lot of effort
for me do that in Go and I just did it. After it's done, all I have to do for
switching the transport is to modify the default transport factory's name,
thanks to Thrift's clear and extendable design, and it works pretty fine with
C++ async client now.
I agree that using net/http in Go standard library is better in the long term.
To get it done, it seems we need to wrap the existing Protocols and map
http.Handler to the compiler generated RPC codes(changing the compiler behavior
is necessary?) What progress is it of THRIFT-3186 now? I'm happy to see its
accomplishment and adapt my application to it.
> Add http transport for server to Go lib
> ---------------------------------------
>
> Key: THRIFT-3251
> URL: https://issues.apache.org/jira/browse/THRIFT-3251
> Project: Thrift
> Issue Type: Sub-task
> Components: Go - Library
> Affects Versions: 0.9.2
> Reporter: Dylan Wen
> Assignee: Dylan Wen
> Priority: Minor
>
> There is a lack of http transport for server in Go lib, so the server could
> not communicate with client running http transport, e.g., client runs the Go
> code lib/go/thrift/http_client.go, or C++ async client which usually runs
> along with libevent and http transport.
> Some code similar to lib/cpp/src/thrift/transport/THttpTransport.cpp needs to
> be added to Go lib, in order to run a server written in Go to communicate
> with these http transport client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
