Hi,
I am witnessing something in my system that I didn't expect. I am processing
data at a data rate of 100Mbps, with occasional peaks of 5s of data (=5 *
100Mbps) delivered as fast as possible because an internal buffer is
flushed. I use ZeroMQ internally, but I have to deliver the data on a TCP
plain socket at the endpoint of my system. Here, I use a ZMQ_STREAM socket
where clients connect. Basically, I keep track of connected clients and send
the data to all clients as a copy of the message. The main loop here looks
like
for(auto const& c: clientIdMessages) {
bool eagain = !socket.send(c.copy(), ZMQ_DONTWAIT | ZMQ_SNDMORE);
if (!eagain) {
eagain = !socket.send(msg.copy(), ZMQ_DONTWAIT | ZMQ_SNDMORE);
}
}
This usually works fine, but from time to time a message is skipped because
send returns with EAGAIN. If I understand the docs correctly, this happens
if the peer is unknown (ZMQ_STREAM behavior) or when the message cannot be
queued. I can exclude the first case, so I must a high HWM for sending
messages. However, I tried to increase the HWM to a huge value of 50 times
the expected message rate and it did not solve the problem. I also tried to
disable the HWM by setting it to 0, which means "no limit". Still, I am
getting an EAGAIN which I don't expect.
I can exclude any previous loss because I have counters showing me that the
full data stream is delivered to the ZMQ_STREAM socket code above. I also
added an assertion on !eagain after sending, and this fires. Are there any
other conditions when I can get EAGAIN from a ZMQ_STREAM socket?
Best wishes,
Jens
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
