mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
GitBook: [master] 326 pages and 16 assets modified
This commit is contained in:
committed by
gitbook-bot
parent
8b7ba5c3bb
commit
fb0d5c8355
8
developing-with-nats/intro-1/README.md
Normal file
8
developing-with-nats/intro-1/README.md
Normal file
@@ -0,0 +1,8 @@
|
||||
# Automatic Reconnections
|
||||
|
||||
Most, if not all, of the client libraries will reconnect to the NATS system if they are disconnected for any reason. The reconnect logic can differ by library, so check your client library's documentation.
|
||||
|
||||
In general, the client will try to connect to all of the servers it knows about, either through the URLs provided in the `connect` call or the URLs provided by the NATS system itself. The NATS system will inform clients of new endpoints that can be used to reconnect. The library may have several options to help control reconnect behavior.
|
||||
|
||||
The list of servers used during reconnect is library dependent, but generally is constructed from connect function/options and the list of servers provided by the NATS system itself. This feature allows NATS applications and the NATS system itself to self heal and reconfigure itself with no additional configuration or intervention.
|
||||
|
||||
14
developing-with-nats/intro-1/buffer.md
Normal file
14
developing-with-nats/intro-1/buffer.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# Buffering Messages During Reconnect Attempts
|
||||
|
||||
The NATS client libraries try as much as possible to be fire and forget. One of the features that may be included in the library you are using is the ability to buffer outgoing messages when the connection is down.
|
||||
|
||||
During a short reconnect, these client can allow applications to publish messages that, because the server is offline, will be cached in the client. The library will then send those messages on reconnect. When the maximum reconnect buffer is reached, messages will no longer be publishable by the client.
|
||||
|
||||
Be aware, while the message appears to be sent to the application it is possible that it is never sent because the connection is never remade. Your applications should use patterns like acknowledgements to ensure delivery.
|
||||
|
||||
For clients that support this feature, you are able to configure the size of this buffer with bytes, messages or both.
|
||||
|
||||
!INCLUDE "../../\_examples/reconnect\_5mb.html"
|
||||
|
||||
> _As mentioned throughout this document, each client library may behave slightly differently. Please check the documentation for the library you are using._
|
||||
|
||||
6
developing-with-nats/intro-1/disable.md
Normal file
6
developing-with-nats/intro-1/disable.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# Disabling Reconnect
|
||||
|
||||
You can disable automatic reconnect with connection options:
|
||||
|
||||
!INCLUDE "../../\_examples/reconnect\_none.html"
|
||||
|
||||
6
developing-with-nats/intro-1/events.md
Normal file
6
developing-with-nats/intro-1/events.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# Listening for Reconnect Events
|
||||
|
||||
Because reconnect is primarily under the covers many libraries provide an event listener you can use to be notified of reconnect events. This event can be especially important for applications sending a lot of messages.
|
||||
|
||||
!INCLUDE "../../\_examples/reconnect\_event.html"
|
||||
|
||||
6
developing-with-nats/intro-1/max.md
Normal file
6
developing-with-nats/intro-1/max.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# Set the Number of Reconnect Attempts
|
||||
|
||||
Applications can set the maximum reconnect attempts. Generally, this will limit the actual number of attempts total, but check your library documentation. For example, in Java, if the client knows about 3 servers and the maximum reconnects is set to 2, it will not try all of the servers. On the other hand, if the maximum is set to 6 it will try all of the servers twice before considering the reconnect a failure and closing.
|
||||
|
||||
!INCLUDE "../../\_examples/reconnect\_10x.html"
|
||||
|
||||
8
developing-with-nats/intro-1/random.md
Normal file
8
developing-with-nats/intro-1/random.md
Normal file
@@ -0,0 +1,8 @@
|
||||
# Avoiding the Thundering Herd
|
||||
|
||||
When a server goes down, there is a possible anti-pattern called the _Thundering Herd_ where all of the clients try to reconnect immediately, thus creating a denial of service attack. In order to prevent this, most NATS client libraries randomize the servers they attempt to connect to. This setting has no effect if only a single server is used, but in the case of a cluster, randomization, or shuffling, will ensure that no one server bears the brunt of the client reconnect attempts.
|
||||
|
||||
However, if you want to disable the randomization process, so that servers are always checked in the same order, you can do that in most libraries with a connection options:
|
||||
|
||||
!INCLUDE "../../\_examples/reconnect\_no\_random.html"
|
||||
|
||||
6
developing-with-nats/intro-1/wait.md
Normal file
6
developing-with-nats/intro-1/wait.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# Pausing Between Reconnect Attempts
|
||||
|
||||
It doesn’t make much sense to try to connect to the same server over and over. To prevent this sort of thrashing, and wasted reconnect attempts, libraries provide a wait setting. This setting will pause the reconnect logic if the same server is being tried multiple times **in a row**. In the previous example, if you have 3 servers and 6 attempts, the Java library would loop over the three servers. If none were connectable, it will then try all three again. However, the Java client doesn’t wait between each attempt, only when trying the same server again, so in that example the library may never wait. If on the other hand, you only provide a single server URL and 6 attempts, the library will wait between each attempt.
|
||||
|
||||
!INCLUDE "../../\_examples/reconnect\_10s.html"
|
||||
|
||||
Reference in New Issue
Block a user