No buffer space available, write errror

[filburt-turle]

I'm working on a project that uses unix_dgram. My app sends data to a Unix socket. I'm using unix_dgram to create the socket and read the incoming messages. From within node, I don't get any errors from your application, but my producer app that's pushing data on the socket create by unix_dgram lib complains about there is no buffer space available.

I'm pushing a lot of data through this socket, so a lot of the data get through fine, it's only a few messages that don't come out the other end.

Write error on Unix socket "/tmp/demo.socket": No buffer space available;

Do you know how I can make the buffer size larger within this lib or any methods for me to resolve this issue?

Thanks in advance.

[santigimeno]

Have you tried using connect() along with the congestion and writable events as in the example.

[filburt-turle]

Hi @santigimeno, I'm not able to change the functionality of the app producing messages, which is written in Rust. The app producing the messages only asks for the type of transport (unix_dgram) and the location of the socket (/tmp/demo.socket).

The only side I have control of is creating the socket w/unix_drgram and receiving the messages. I was looking into whether the library had any options when setting up the socket, but there seems to be none that I'm aware of.

From my understanding, the connect(), congestion, and writable are functionality to be used on the producing side (client)?

[bnoordhuis]

"No buffer space available" corresponds to ENOBUFS? Because that error means the kernel can't (or refuses to) allocate more memory for the send/receive queue.

If your producer sends data at a higher rate than the consumer can receive it, you'll hit that error sooner or later. The solution is to back off for a bit and retry.

Tuning SO_SNDBUF and SO_RCVBUF can make it less worse but that's not really a fix, more of a mitigation.

(Not that node-unix-dgram currently supports tuning SO_RCVBUF but that can be added if needed.)

[filburt-turle]

That sounds like a nice feature to have! Just to provide some metrics and I'm currently seeing these stats:

msg_sent_success: 35564
msg_sent_failure: 516

The numbers aren't astronomical, but it's roughly 1.45% of all messages. The timespan of this is less than one minute. The producer application is sending at theses level all throughout the day, but there's a time where the messages being sent drops lower (night time, etc) when there is not a lot of transactions being made.

[bnoordhuis]

I don't have much time to work on it myself right now but if you open a pull request, me or Santiago will review it.