what is a "write EPIPE" error?

[Mark Hahn]

I am trying to send a request with a file as the http body to couchdb from node.  I've done it a million times in the past but now I'm stuck on an error event.  Out of desperation I got rid of the pipe and wrote out the loop manually.  Here is the code ...

reqProx = http.request options, (resProx) ->

if +resProx.statusCode isnt 201

log 'dba: uploadAttachment bad status ' + compDoc._id + ' ' + resProx.statusCode

cb false

return

resProx.on 'error', (err) -> 

log 'dba: uploadAttachment res err event ' + compDoc._id + ' ' + resProx.statusCode, {err}

cb false

resProx.on 'data', (chunk) ->  respStr += chunk.toString()

resProx.on 'end', (chunk) ->

if chunk then respStr += chunk.toString()

resp = JSON.parse respStr

cb resp 

reqProx.on 'error', (err) ->

                        # Error happens here

log 'dba: readStream error event ' + compDoc._id , err

cb false

readStream.on 'data', (chunk) -> 

reqProx.write chunk

readStream.on 'end', (chunk) -> 

reqProx.end chunk

The error message just says "write EPIP".  What the heck does that mean?  Any ideas on what I'm doing wrong?

[Ben Noordhuis]

On Mon, Jan 30, 2012 at 21:40, Mark Hahn <ma...@hahnca.com> wrote:
> The error message just says "write EPIP".  What the heck does that mean?
>  Any ideas on what I'm doing wrong?

EPIPE means that writing of (presumably) the HTTP request failed
because the other end closed the connection.

[Mark Hahn]

thanks

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Mark Hahn]

I used wireshark to track down exactly what is happening on the wire.  The sequence of activity is ...

1) The request head is sent out in one tcp packet. 

2) Couch looks at the head and returns a normal error result 409 (out-of-date revision).  

3) The request body is sent out 

4) Couch closes the connection instead of acking, causing the write error

Couch shouldn't return anything until the whole request is in, correct?  It is as if couch wasn't expecting the body.  I know my request has all the needed headers like content-type and content-length.  I know this because I figured out how to kludge my way past the problem.  I loaded the body of the request (a jpeg) into memory with a `fileData = fs.readFileSync` before starting the request.  Then I sent the whole body in the first tick using `req.end fileData` right after the http.request call.

So it works if I jam the data out fast and fails if I send the body later (req.write and req.end from readstream events).  Can someone tell me what I'm doing wrong?

[Isaac Schlueter]

Mark, this is an unfortunate fact of reality with HTTP. Either end
can abruptly close the connection at any time for any or no reason.
You're not doing anything wrong, per se, and Couch is following the
rules also. You basically just need to catch and swallow this error,
and then stop sending anything.

We ought to be passing those errors up as error events on the request
object, as well as providing an event when the socket is disconnected.
If that's not happening, then that's a bug in node.

[Mark Hahn]

Let's assume for the moment that couch is doing the right thing.  My problem is that I can't figure out how to get the error response from couch that I see on the wire.

Here is some request code for my discussion ...

readStream = fs.createReadStream pathin

writeStream = http.request options, (result) ->

    # this callback never happens

writeStream.on 'error', (err) ->

    EPIPE error happens here

readStream.on 'data', (chunk) -> writeStream.write chunk

readStream.on 'end',  (chunk) -> writeStream.end  chunk

In this situation couch gets the header by itself in a tcp packet.  Then it returns a packet back with the 409 error.  Then the body is written in another packet.  Couch thinks it is garbage and closes the connection.  The closed connection then causes the writestream error event.  The error coming back is ignored by node.  I would like for it to be returned in the request callback.  It should show as an error with some way for me to see what was returned.

How do I get that error info that was returned?  If I don't have it I don't have any idea I should retry, which is the proper response for a 409.

This seems like a problem in node.

[wavded]

This may or may not be relevant to the above situation but...

It happened to me on a request where I was getting EPIPE because the request was too long (changing from a querystring to using POST data fixed it).  Totally could have been my unique sitution but... if it helps anyone.