Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
Date: Wed, 5 Jul 2017 14:07:00 +0000 (UTC)
From: "pirDOL (JIRA)" <jira@apache.org>
To: dev@thrift.apache.org
Message-ID: <JIRA.13084848.1499262876000.173673.1499263620066@Atlassian.JIRA>
In-Reply-To: <JIRA.13084848.1499262876000@Atlassian.JIRA>
References: <JIRA.13084848.1499262876000@Atlassian.JIRA> <JIRA.13084848.1499262876876@jira-lw-us.apache.org>
Subject: [jira] [Updated] (THRIFT-4245) Golang TFramedTransport's
 writeBuffer increases if writes to transport failed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 05 Jul 2017 14:07:04 -0000


     [ https://issues.apache.org/jira/browse/THRIFT-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

pirDOL updated THRIFT-4245:
---------------------------
    Description: 
https://github.com/apache/thrift/blob/master/lib/go/thrift/framed_transport.go#L143
if p.transport.Write fails, p.buf will not be truncated, which leads to thrift client's memory increasing forever. 

Is it more reasonable to truncate p.buf when write to transport fails? here are my pull request, https://github.com/apache/thrift/pull/1303

i'm new in github&jira, if more details are needed, please tell me, thx.

{code:none}
func (p *TFramedTransport) Flush() error {
	size := p.buf.Len()
	buf := p.buffer[:4]
	binary.BigEndian.PutUint32(buf, uint32(size))
	_, err := p.transport.Write(buf)
	if err != nil {
		return NewTTransportExceptionFromError(err)
	}
	if size > 0 {
		if n, err := p.buf.WriteTo(p.transport); err != nil {
			print("Error while flushing write buffer of size ", size, " to transport, only wrote ", n, " bytes: ", err.Error(), "\n")
			return NewTTransportExceptionFromError(err)
		}
	}
	err = p.transport.Flush()
	return NewTTransportExceptionFromError(err)
}
{code}


  was:
https://github.com/apache/thrift/blob/master/lib/go/thrift/framed_transport.go#L143
if p.transport.Write fails, p.buf will not be truncated, which leads to thrift client's memory increasing forever. 

Is it more reasonable to truncate p.buf when write to transport fails?

{code:none}
func (p *TFramedTransport) Flush() error {
	size := p.buf.Len()
	buf := p.buffer[:4]
	binary.BigEndian.PutUint32(buf, uint32(size))
	_, err := p.transport.Write(buf)
	if err != nil {
		return NewTTransportExceptionFromError(err)
	}
	if size > 0 {
		if n, err := p.buf.WriteTo(p.transport); err != nil {
			print("Error while flushing write buffer of size ", size, " to transport, only wrote ", n, " bytes: ", err.Error(), "\n")
			return NewTTransportExceptionFromError(err)
		}
	}
	err = p.transport.Flush()
	return NewTTransportExceptionFromError(err)
}
{code}


> Golang TFramedTransport's writeBuffer increases if writes to transport failed
> -----------------------------------------------------------------------------
>
>                 Key: THRIFT-4245
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4245
>             Project: Thrift
>          Issue Type: Bug
>            Reporter: pirDOL
>
> https://github.com/apache/thrift/blob/master/lib/go/thrift/framed_transport.go#L143
> if p.transport.Write fails, p.buf will not be truncated, which leads to thrift client's memory increasing forever. 
> Is it more reasonable to truncate p.buf when write to transport fails? here are my pull request, https://github.com/apache/thrift/pull/1303
> i'm new in github&jira, if more details are needed, please tell me, thx.
> {code:none}
> func (p *TFramedTransport) Flush() error {
> 	size := p.buf.Len()
> 	buf := p.buffer[:4]
> 	binary.BigEndian.PutUint32(buf, uint32(size))
> 	_, err := p.transport.Write(buf)
> 	if err != nil {
> 		return NewTTransportExceptionFromError(err)
> 	}
> 	if size > 0 {
> 		if n, err := p.buf.WriteTo(p.transport); err != nil {
> 			print("Error while flushing write buffer of size ", size, " to transport, only wrote ", n, " bytes: ", err.Error(), "\n")
> 			return NewTTransportExceptionFromError(err)
> 		}
> 	}
> 	err = p.transport.Flush()
> 	return NewTTransportExceptionFromError(err)
> }
> {code}


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)