Comments (16)
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.
Related Issues (20)
- Failing to compile on Travis with Node 4.2.1 HOT 2
- does not work on node 4 or node 5 HOT 2
- getting a "make" error when building on CentOS 7 HOT 2
- Can't install in node 6 HOT 1
- Buffer limited to 2048 on Mac OS HOT 6
- Sending data in loop fails HOT 6
- - sorry -
- callback not used in case of congestion HOT 1
- Improve mismatched type handling. HOT 1
- Error | Failing build unix-dgram on solaris HOT 4
- Install failed using Node v10 HOT 2
- nodejs 12 support HOT 1
- Nan::NAN_METHOD_RETURN_TYPE HOT 1
- 2.0.3 causes hangs on Node < 12 HOT 2
- No buffer space available, write errror HOT 5
- Failing to build/install with Cannot open include file: 'unistd.h' on Windows HOT 4
- unix-dgram does not seem to work with Node v13? HOT 3
- Failing to build (ubuntu 20.04) HOT 1
- Is it possible to add Windows support? HOT 1
- Doesn't build on Node 20.9.0 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from node-unix-dgram.