Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
Date: Wed, 5 Jul 2017 13:56:00 +0000 (UTC)
From: "pirDOL (JIRA)" <jira@apache.org>
To: dev@thrift.apache.org
Message-ID: <JIRA.13084848.1499262876000.173540.1499262960203@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 13:56:05 -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?

{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:golang}
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?
> {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)