[zeromq-dev] assertion at mailbox.cpp:182

Pavel Gushcha pavimus at gmail.com
Mon Jan 31 10:33:11 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 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,
        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