Dionakra
Joined 6 years ago
Joined 6 years ago
Imagine a client sending messages to RabbitMQ with some retry policy if it doesn't receive the ACK from the broker. If the client sends the message and it doesn't receive the ACK in the terms it has been defined (maybe a timeout of 30s), it will retry to send the message, as the consumer assumes that the message hasn't been received by the brokers, but it could be that the ACK back to the client is the one that failed to be sent to the client. The brokers actually saved the message, and they stored it, but the client doesn't know, so it retries the message.
If you don't have some control over the messages, this retried message is _new_ to RabbitMQ, so it will store it and send back the ACK. Maybe this time it is successful and no other retries are made.
With this scenario, the brokers would have received the same message twice. By adding this kind of control (Kafka does more or less the same by discarding messages with already processed IDs when configured as exactly-once) you can try to avoid duplicates. Of course it is limited by memory and it is not in fact exactly-once semantics, so they are calling it now _effectively exactly-once semantics_, as it is more precise.
Regarding the use of <span> is because the <p> tag with the chosen CSS leaves too much space after <h*> tags, while <span> doesn't, and as I wanted to just use HTML tags and not create my own version of the CSS, I found <span> the easiest way to achieve that.