[
https://issues.apache.org/jira/browse/THRIFT-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905523#action_12905523
]
Bryan Duxbury commented on THRIFT-669:
--------------------------------------
I'd kind of like to commit this patch, but there are a few oddities I think we
might want to address.
In read(), there's an else case that prints some anonymous-looking variable to
stdout. Is this intentional, or debugging?
In write, the user agent is set as "BattleNet". Seems misleading. Maybe
"TFullDuplexHttpClient" instead?
Would be nice to move the constructor closer to the top of the file.
open() should probably throw TTransportExceptions in the case of problems
instead of just printing the stack trace.
The file is indented with tabs. We use spaces.
> 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.
