[zeromq-dev] Fwd: assertion at mailbox.cpp:182
Pavel Gushcha
pavimus at gmail.com
Mon Jan 31 16:57:24 CET 2011
> > I'm not very involved into zmq2 internals, but as i understood, socket
> > buffer must have bigger size, that message_t class. And message_t has
> > relatively small size than my net.core.wmem_default = 126976. May be
> > zmq::mailbox_t::send tries to increase socket buffer in case when it
> > have big size but is full too?
> >
> We don't have api plumbing to change mailbox socket buffer sizes yet,
> ie. ZMQ_SNDBUF and ZMQ_RCVBUF don't apply.
> You'd have to change them manually, can you try changing wmem_default
> and rmem_default?
> Note wmem_default and rmem_default are capped by wmem_max and
> rmem_max, so you'd have to change them too.
Thanks you for reply, Dhammika!
which value you suggest try to set for wmem_default and rmem_default,
the default value 124kb is not enough?
For me is not 100% unclear, in which case zmq try to increase buffer by:
// Attempt to increase mailbox SNDBUF if the send failed.
if (nbytes == -1 && errno == EAGAIN) {
int old_sndbuf, new_sndbuf;
socklen_t sndbuf_size = sizeof old_sndbuf;
// Retrieve current send buffer size.
int rc = getsockopt (w, SOL_SOCKET, SO_SNDBUF, &old_sndbuf,
&sndbuf_size);
errno_assert (rc == 0);
new_sndbuf = old_sndbuf * 2;
// Double the new send buffer size.
rc = setsockopt (w, SOL_SOCKET, SO_SNDBUF, &new_sndbuf, sndbuf_size);
errno_assert (rc == 0);
// Verify that the OS actually honored the request.
rc = getsockopt (w, SOL_SOCKET, SO_SNDBUF, &new_sndbuf, &sndbuf_size);
errno_assert (rc == 0);
zmq_assert (new_sndbuf > old_sndbuf);
// Retry the sending operation; at this point it must succeed.
do {
nbytes = ::send (w, &cmd_, sizeof (command_t), 0);
} while (nbytes == -1 && errno == EINTR);
}
I can only suppose, that this code try to increase buffer each time,
when it has no free space to send message_t. When this is correct,
theoretically in busy system buffer size may grow without limits.
Problem is very hard to reproduce. now my app have 1 day uptime...
More information about the zeromq-dev
mailing list