[jira] Commented: (THRIFT-669) Use Http chunk encoding to do full duplex transfer in a single post

["Tony Kinnis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987925#action_12987925 ] 

Tony Kinnis commented on THRIFT-669:
------------------------------------

It looks like this client makes assumptions in the read method that are not valid in some cases. While the initial request states it is using Transfer-Encoding: chunked (which is unnecessary) that does not mean that the server will respond with a response that is using Transfer-Encoding: chunked. There are other aspects of the HTTP specification that are also not implemented.

This client seems too limited to be used in many environments since it assumes that the server will always return a chunked response and nothing else.

There was a recent commit to THttpClient, THRIFT-970, that allows it to use apache httpcomponents client which is more complete and can support chunking. Maybe this implementation could be adapted to use apache httpcomponents based on that example instead of rolling its own http client?

THttpClient currently buffers the response in the flush method, in theory, to prevent clients from exhausting ephemeral ports and holding open connections on the servers. It would have to be implemented slightly differently in this class to achieve a buffer-less read but it wouldn't be too different from what is currently implemented in THttpClient.

> Use Http chunk encoding to do full duplex transfer in a single post
> -------------------------------------------------------------------
>
>                 Key: THRIFT-669
>                 URL: https://issues.apache.org/jira/browse/THRIFT-669
>             Project: Thrift
>          Issue Type: Bug
>    Affects Versions: 0.2
>            Reporter: Aron Sogor
>         Attachments: TFullDuplexHttpClient.java
>
>
> Instead of each method call being a separate post, use chunk-encoded request. If you look at the traffic in wireshark many times the payload is much smaller than the HTTP header. Using chunk encoding, the per method overhead of the http header is gone. Running a simple test of getting a time as i32, using http post vs chunk encoding I got from 100+ms to ~40ms per request as the servlet container did not have to process the overhead of a "new request".
> More I think with jetty and continuation the long running connections could actually scale and perform a lot better than the current HttpClient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.