net.Conn.Write is failing in golang

[vijayan jay]

We are using net.Conn.Write(response) in our program were response is a json data of length 84317829 bytes.

Is there any chance for failure of write in golang when length of data is more ?

Because i could see that in one more scenario when length is 3585632 then write is working fine.

I have copied the error which i printed in the program,

(EXTRA string=write tcp 127.0.0.1:3988->127.0.0.1:28459: write: broken pipe)

So could you please help here what could be reason for this issue ?

Please let me know if you need any other information.

[James Bardin]

On Thursday, January 28, 2016 at 12:06:38 PM UTC-5, vijayan jay wrote:

We are using net.Conn.Write(response) in our program were response is a json data of length 84317829 bytes.

Is there any chance for failure of write in golang when length of data is more ?

Because i could see that in one more scenario when length is 3585632 then write is working fine.

I have copied the error which i printed in the program,

(EXTRA string=write tcp 127.0.0.1:3988->127.0.0.1:28459: write: broken pipe)

"broken pipe" is just the OS telling you that the socket was closed, but you kept on writing.  Regardless of what the error message is, the write failed, and you need to handle it accordingly. 

[Ian Lance Taylor]

The Write method can handle writes of that size.

The "broken pipe" error means that the other end of the socket has closed it.

Ian

[silia...@grabtaxi.com]

I found it's hard to match this particular error ("broken pipe"), and handle it accordingly, is there a solution?

Grab is hiring. Learn more at https://grab.careers

By communicating with Grab Inc and/or its subsidiaries, associate companies and jointly controlled entities (“Grab Group”), you are deemed to have consented to processing of your personal data as set out in the Privacy Notice which can be viewed at https://grab.com/privacy/

This email contains confidential information and is only for the intended recipient(s). If you are not the intended recipient(s), please do not disseminate, distribute or copy this email and notify Grab Group immediately if you have received this by mistake and delete this email from your system. Email transmission cannot be guaranteed to be secure or error-free as any information therein could be intercepted, corrupted, lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do not accept liability for any errors or omissions in the contents of this email arises as a result of email transmission. All intellectual property rights in this email and attachments therein shall remain vested in Grab Group, unless otherwise provided by law.

[James Bardin]

On Fri, Aug 26, 2016 at 5:46 AM, <silia...@grabtaxi.com> wrote:

I found it's hard to match this particular error ("broken pipe"), and handle it accordingly, is there a solution?

What do you want to do with this particular error? How would you handle it differently than any other permanent error? 

The error is exactly the same as you would encounter using the C socket api, on linux it's syscall.EPIPE. 

[Aliaksandr Valialkin]

It looks like there is a timeout (aka deadline) set on the connection, so small responses are sent without problems, while large responses are interrupted by the timeout. See https://blog.cloudflare.com/the-curious-case-of-slow-downloads/ for details.