[zeromq-dev] Monitor current input queue length

[Benjamin Errouane]

On another note:
I just found out that pushing messages as fast as possible when using the
PGM transport leads to dropped messages. Checking the input queue length
before pushing on the application side would help in that case. Is there no
qay to check the queue length?

Pieter Hintjens <ph at imatix.com> schrieb am Fr., 15. Jan. 2016 um 18:39 Uhr:

> That's a router replying to a dealer. Not the same as a dealer sending
> to a router. Routers can't block because they handle many clients.
> They will drop if sending pipe for any given client is full. So you
> use credit based flow control on such cases (e.g. download large file
> in chunks).
>
> On Fri, Jan 15, 2016 at 4:13 PM, Tom Quarendon
> <tom.quarendon at teamwpc.co.uk> wrote:
> > But I *have* read it, and it says a ROUTER socket:
> >
> > For processing outgoing messages:
> > SHALL either silently drop the message, or return an error, depending on
> configuration, if the queue does not exist, or is full.
> >
> > What am I not understanding?
> > Thanks.
> >
> > -----Original Message-----
> > From: zeromq-dev-bounces at lists.zeromq.org [mailto:
> zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
> > Sent: 15 January 2016 10:19
> > To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> > Subject: Re: [zeromq-dev] Monitor current input queue length
> >
> > A DEALER will never drop a message unless you do weird stuff like kill a
> peer and never restart it.
> >
> > You will not get dropped replies either. This is not how it works.
> > Please read http://rfc.zeromq.org/spec:28 for the details.
> >
> > -Pieter
> >
> > On Fri, Jan 15, 2016 at 9:54 AM, Tom Quarendon <
> tom.quarendon at teamwpc.co.uk> wrote:
> >> So with a request reply model, with REQ or DEALER clients, you
> basically never get dropped messages?
> >> I could theoretically get dropped replies if I have lots and lots of
> clients? If the thread inside zeromq that's actually putting the replies
> onto the right sockets can't keep up with the rate I'm generating the
> replies?
> >>
> >>
> >> -----Original Message-----
> >> From: zeromq-dev-bounces at lists.zeromq.org
> >> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter
> >> Hintjens
> >> Sent: 14 January 2016 17:03
> >> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> >> Subject: Re: [zeromq-dev] Monitor current input queue length
> >>
> >> No, DEALER clients won't drop messages. When the buffers at both sides
> are full, they will block on sending new messages. You can test this quite
> simply. The router will drop outgoing messages (replies) it cannot deal
> with, so when sending large volumes, you need to use credit-based flow
> control (it's explained in the Guide).
> >>
> >> On Thu, Jan 14, 2016 at 4:16 PM, Tom Quarendon <
> tom.quarendon at teamwpc.co.uk> wrote:
> >>> Is there any way to get the current input queue length for a socket,
> >>> or determine whether input messages are being dropped?
> >>>
> >>> I’m writing a server that sits on a ROUTER socket and processes
> >>> messages from potentially multiple clients, using multiple threads.
> >>>
> >>>
> >>>
> >>> What I’d really like to know is “is my server coping with demand”?
> >>>
> >>>
> >>>
> >>> I *think* that the symptom of it not (correct me if I’m wrong) is
> >>> that input messages sent by clients will be silently dropped, but I’d
> >>> quite like to find a way of knowing that that has happened.
> >>>
> >>> I’d like to be able to report something like “average input queue
> length”.
> >>> It might be enough to get an event on the zmq_socket_monitor socket
> >>> when the socket enters and exits such a state.
> >>>
> >>>
> >>>
> >>> I appreciate that what I ask may not make sense, I probably don’t
> >>> fully understand 0MQ. If so, please enlighten me!
> >>>
> >>>
> >>>
> >>> Thanks.
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> zeromq-dev mailing list
> >>> zeromq-dev at lists.zeromq.org
> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160116/95e9f3dd/attachment.htm>