Getting EWOULDBLOCK | EAGAIN errno about node-unix-dgram HOT 16 CLOSED

With these changes, if send fails with EAGAIN, it'll retry sending again 2 more times before exiting with an error. This isn't solving my problems though, because the error is happening on every try.

I've been able to solve it by handling the error in JS land (in unix_dgram.js) making new tries after nextTick's. Sometimes after 1 tick but sometimes after several ticks. So I don't know if the correct approach would be to handle this at a library level (maybe making configurable the number of retries), or should I just handle it at the application level. What do you think?

Thanks

from node-unix-dgram.

After investigating this issue a little, I think I've found out something.
In the Linux kernel implementation of unix datagram sockets, from what I can tell (please correct me if I'm wrong), the EAGAIN error is sent when the receiving buffer of the 'remote' peer is full:
https://github.com/torvalds/linux/blob/master/net/unix/af_unix.c#L1567-1571,
And, again correct me if I'm wrong, apparently we should receive a poll write event when the receiving buffer of the 'remote' peer is not full anymore:
https://github.com/torvalds/linux/blob/master/net/unix/af_unix.c#L2224-2238

Could we use this to generate an event similar to net.Socket drain to notify when I can send data again? If this could be possible I would like to 'listen' to UV_WRITABLE events only when needed. I know it's possible to start listening to UV_WRITABLE events by calling uv_poll_start, but is it possible to stop listening to write events while still listening to read events?

• I haven't looked to other Unix socket implementations to know if their behaviour is the same as the Linux

Thanks

from node-unix-dgram.

I'm also having this problem on some machines (namely some Ubuntu 12.04 machines running on AWS EC2), but not on others (namely my dev machine, running Ubuntu 13.10).

Making the socket blocking makes this problem disappear at the cost of some waiting: https://github.com/brikteknologier/node-unix-dgram/compare

Certainly, the solution @santigimeno proposes is preferable and more in tune with node.js design, but a workaround might also be usable for people :)

from node-unix-dgram.

I'm having this problem as well, on some Ubuntu Server 10.04 machines, and the changes committed by @santigimeno seem to have no effect. I'd rather not change this module to run synchronously as @briktop suggested, as our winston-syslog package is using it, and it'd be a performance issue to wait for every log message we send.

Is there any update on this issue? I notice that this is the only open issue for the project; what does @bnoordhuis have to say about this?

from node-unix-dgram.

I actually did some work on this last week but I got sidetracked by $DAY_JOB. I can't promise anything but I haven't forgotten about this issue.

from node-unix-dgram.

Thanks for the instant response!

I'm getting some of our C developers to take a look at this; we need to find some way around this issue by the end of the week.

from node-unix-dgram.

If you're willing to throw some money at it, get in touch with [email protected] to set up a one-time contracting gig. I basically need a few more hours to wrap up the work I did so far.

from node-unix-dgram.

@airandfingers What I've ended up doing is logging to syslog via TCP instead. This might be a realistic solution for the timeframe of within the week :) It probably requires configuration of the syslog daemon.

I'd be super happy if this were fixed and I could go back to unix-dgram-logging, however :)

from node-unix-dgram.

@airandfingers @briktop I ended up using the nextTick approach and for my use case it worked fine. See https://github.com/santigimeno/winston-syslog/commits/more_fixes that uses this https://github.com/santigimeno/node-unix-dgram/tree/my_branch

from node-unix-dgram.

It's great to know some work is being done to fix this. @bnoordhuis thanks!

from node-unix-dgram.

@bnoordhuis Thanks for the suggestion. We found our own workaround (see below).

@briktop Yeah, initially we were using TCP, but our logging configuration requires that we log to /dev/log.

@santigimeno This seems like a valid solution; we made a change of our own to unix_dgram.js (see below).

The way we found around this was to change Socket.prototype.send to always call its callback, instead of emitting an error. See https://gist.github.com/airandfingers/8564332

This seems to work for us; no "send 11" crashes so far.

from node-unix-dgram.

@airandfingers If I understand it correctly your solution avoid crashes but you are losing data. This might not be acceptable in some cases. The nextTick solution avoids this but can really slow down the app with high traffic load

from node-unix-dgram.

@santigimeno Losing data was something we were also worried about, but my interpretation of winston-syslog's onError function is that messages that get errors will just be pushed back onto the message queue, to be sent out later.

I could be wrong (I haven't tested this hypothesis), but I don't think we're losing data. I think your solution and mine are very similar, just performing the retry at different levels - yours within unix-dgram, and mine within winston-syslog, using its message queuing. I also think this was the winston-syslog's intention, since its onError function includes error-handling rather than watching for the "error" event.

One note: our fix doesn't discriminate between error types, so every message will always be retried. This is probably suboptimal - not every error code indicates that the message should be resent.

from node-unix-dgram.

@airandfingers You are right. I didnt remember that winston-syslog buffered unsent data. It's been a long time since I checkef that code. Sorry about that.

I agree you should be checking the error code

from node-unix-dgram.

@airandfingers Just in case you want to give it a try, I've pushed some changes at https://github.com/santigimeno/winston-syslog/tree/upgrade_unix_dgram so that winston-syslog uses unix-dgram from #12. I've done some load testing and I'm quite happy with it.

from node-unix-dgram.

Fixed in commit a41f755

from node-unix-dgram.