taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

Update acks.md

Browse Source
This commit is contained in:
Ginger Collison 2019-10-04 11:05:32 -05:00 committed by GitHub
parent 2543cb12c6
commit 5caaf26e2d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
developer/concepts/acks.md
View File

@ -2,30 +2,6 @@
In a system with at-most-once semantics, there are times when messages can be lost. If your application is doing request-reply it should use timeouts to handle any network or application failures. It is always a good idea to place a timeout on a requests and have code that deals with timeouts. When you are publishing an event or data stream, one way to ensure message delivery is to turn it into a request-reply with the concept of an acknowledgement message, or ACKs. In NATS an ACK can simply be an empty message, a message with no payload.
<div class="graphviz"><code data-viz="dot">
digraph nats_request_reply {
rankdir=LR
subgraph {
publisher [shape=box, style="rounded", label="Publisher"];
}
subgraph {
subject [shape=circle, label="Subject"];
reply [shape=circle, label="Reply"];
{rank = same subject reply}
}
subgraph {
sub1[shape=box, style="rounded", label="Subscriber"];
}
publisher -> subject [label="msg1"];
publisher -> reply [style="invis", weight=2];
subject -> sub1 [label="msg1"];
sub1 -> reply [label="ack"];
reply -> publisher;
}
</code></div>
![acks](/assets/images/acks.svg)
Because the ACK can be empty it can take up very little network bandwidth, but the idea of the ACK turns a simple fire-and-forget into a fire-and-know world where the sender can be sure that the message was received by the other side, or with a [scatter-gather pattern](reqreply.md), several other sides.