squaremo
REP / WORKER description seems inaccurate [documents clarification]
From the main page:
PUSH / WORKER: a WORKER socket is similar to a PULL socket, but requires that you call #ack on it to acknowledge that you have processed each message. Any messages left unacknowledged when the socket closes, or crashes, will be requeued and delivered to another connected socket (should there be one). A worker socket is read-only, and has the additional method #ack which acknowledges the oldest unacknowledged message, and must be called once only for each message.
A way to maintain ordering for REP and WORKER sockets is shown in the "ordering" example.
But the ordering example doesn't use WORKER sockets, it uses REQ/REP sockets. It's confusing -- is the REQ socket the same as a WORKER socket?
That sentence is supposed to indicate that the technique in the ordering example can also be used for worker sockets. Would it be better to say,
It is important to acknowledge messages in the right order. A way to maintain ordering for REP sockets, which can be adapted to WORKER sockets, is shown in the "ordering" example.
(Is it reasonably clear how to adapt the example, do you think?)
Yes that makes more sense. Maybe you could add that a sample of working with REP/WORKER sockets can be found in the test directory. As it is, I was expecting the ordering example to be a REP/WORKER sample.
On Wed, Jun 17, 2015 at 11:29 AM Michael Bridgen [email protected] wrote:
That sentence is supposed to indicate that the technique in the ordering example can also be used for worker sockets. Would it be better to say,
It is important to acknowledge messages in the right order. A way to maintain ordering for REP sockets, which can be adapted to WORKER sockets, is shown in the "ordering" example.
(Is it reasonably clear how to adapt the example, do you think?)
— Reply to this email directly or view it on GitHub https://github.com/squaremo/rabbit.js/issues/102#issuecomment-112905422.
It would be really nice to have an example of a streaming worker which handles ack's in order. I'm okay with items down the stream to wait sending an ack until the low water mark catches up. So if you had a prefetch of 100, messages 2-100 were complete but still waiting on message 1 to finish, I'm okay holding 2-100 in the buffer until 1 is acked at which point 2-100 will very quickly be acked as well. Hopefully that made sense.
