Hey Jens,
Thanks for checking in -- I'm still trying to find the root cause -- I'm
pretty sure the outputProtocols flush internally and the problem is
actually in the ruby implementation of SSLSocket only returning 16K chunks,
which slowly fills the Thrift::Bytes buffer and makes it look like golang
isn't flushing properly.
Sorry for the noise on the list, I'll be back if I can find a fix in Ruby.
cheers,
-jason
On Sun, Jan 31, 2016 at 10:52 AM, Jens Geyer <jensge...@hotmail.com> wrote:
> Hi Jason,
>
> any news here? Feel free to ask if you need help!
>
> Have fun,
> JensG
>
> -----Ursprüngliche Nachricht----- From: Jason Freidman
> Sent: Wednesday, January 27, 2016 12:48 AM
> To: dev@thrift.apache.org
> Subject: Adding a flush in the golang simple_server implementation.
>
> Hello,
> I've been running into very slow responses for large (20MB payloads)
> using the BufferedTransport and SimpleServer in go.
>
> It seems my buffer isn't being flushed after processing the request,
> resulting in ~6 seconds total RPC call time.
>
> If I add a Flush() in simple_server.go:186, my RPC times drop to ~1.2
> seconds
> if err := outputProtocol.Flush(); err != nil {
> log.Printf("error flush request: %s", err)
> return err
> }
>
> When I use an unbuffered transport, the average request is slower but these
> large requests are faster. With the flush, everything seems faster.
>
> I didn't find any discussion on JIRA, what is the correct way to propose
> and send a patch?
>
>
> cheers,
> -ja
>
