GitBook: [master] 326 pages and 16 assets modified

nats-streaming-concepts/channels/subscriptions/README.md

@@ -0,0 +1,12 @@
+# Subscriptions
+
+A client creates a subscription on a given channel. Remember, there is no support for wildcards, so a subscription is really tied to one and only one channel. The server will maintain the subscription state on behalf of the client until the later closes the subscription \(or its connection\).
+
+If there are messages in the log for this channel, messages will be sent to the consumer when the subscription is created. The server will send up to the maximum number of inflight messages as given by the client when creating the subscription.
+
+When receiving ACKs from the consumer, the server will then deliver more messages, if more are available.
+
+A subscription can be created to start at any point in the message log, either by message sequence, or by time.
+
+The following pages describe all the types of subscriptions.
+

nats-streaming-concepts/channels/subscriptions/durable.md

@@ -0,0 +1,10 @@
+# Durable
+
+If an application wishes to resume message consumption from where it previously stopped, it needs to create a durable subscription. It does so by providing a durable name, which is combined with the client ID provided when the client created its connection. The server then maintains the state for this subscription even after the client connection is closed.
+
+_**Note: The starting position given by the client when restarting a durable subscription is ignored.**_
+
+When the application wants to stop receiving messages on a durable subscription, it should close - but _not unsubscribe_ - this subscription. If a given client library does not have the option to close a subscription, the application should close the connection instead.
+
+When the application wants to delete the subscription, it must unsubscribe it. Once unsubscribed, the state is removed and it is then possible to re-use the durable name, but it will be considered a brand new durable subscription, with the start position being the one given by the client when creating the durable subscription.
+

nats-streaming-concepts/channels/subscriptions/queue-group.md

@@ -0,0 +1,12 @@
+# Queue Group
+
+When consumers want to consume from the same channel but each receive a different message, as opposed to all receiving the same messages, they need to create a queue subscription. When a queue group name is specified, the server will send each messages from the log to a single consumer in the group. The distribution of these messages is not specified, therefore applications should not rely on an expected delivery scheme.
+
+After the first queue member is created, any other member joining the group will receive messages based on where the server is in the message log for that particular group. That means that the starting position given by joining members is ignored by the server.
+
+When the last member of the group leaves \(subscription unsubscribed/closed/or connection closed\), the group is removed from the server. The next application creating a subscription with the same name will create a new group, starting at the start position given in the subscription request.
+
+A queue subscription can also be durable. For that, the client needs to provide a queue and durable name. The behavior is, as you would expect, a combination of queue and durable subscription. Though unlike a durable subscription, the client ID is not part of the queue group name since the client ID must be unique, and would prevent more than one connection to participate in the queue group. The main difference between a queue subscription and a durable one, is that when the last member leaves the group, the state of the group will be maintained by the server. Later, when a member rejoins the group, the delivery will resume.
+
+_**Note: For a durable queue subscription, the last member to**_  **unsubscribe**  _**\(not simply close\) causes the group to be removed from the server.**_
+

nats-streaming-concepts/channels/subscriptions/redelivery.md

@@ -0,0 +1,12 @@
+# Redelivery
+
+When the server sends a message to a consumer, it expects to receive an ACK from this consumer. The consumer is the one specifying how long the server should wait before resending all unacknowledged messages to the consumer.
+
+When the server restarts and recovers unacknowledged messages for a subscription, it will first attempt to redeliver those messages before sending new messages. However, if during the initial redelivery some messages don't make it to the client, the server cannot know that and will enable delivery of new messages.
+
+_**So it is possible for an application to receive redelivered messages mixed with new messages. This is typically what happens outside of the server restart scenario.**_
+
+For queue subscriptions, if a member has unacknowledged messages, when this member's `AckWait` \(which is the duration given to the server before the server should attempt to redeliver unacknowledged messages\) time elapses, the messages are redelivered to any other member in the group \(including itself\).
+
+If a queue member leaves the group, its unacknowledged messages are redistributed to other queue members.
+

nats-streaming-concepts/channels/subscriptions/regular.md

@@ -0,0 +1,4 @@
+# Regular
+
+The state of these subscriptions is removed when they are unsubscribed or closed \(which is equivalent for this type of subscription\) or the client connection is closed \(explicitly by the client, or closed by the server due to timeout\). They do, however, survive a _server_ failure \(if running with a persistent store\).
+