From e22bcf3938419b0f5a4288779ff4fbd5e9a034f4 Mon Sep 17 00:00:00 2001 From: Waldemar Quevedo Date: Wed, 5 Jun 2019 15:06:39 -0700 Subject: [PATCH 1/4] Replace go-nats with nats.go in examples Signed-off-by: Waldemar Quevedo --- developer/tutorials/custom_dialer.md | 4 ++-- developer/tutorials/queues.md | 8 ++++---- nats_admin/upgrading_cluster.md | 4 ++-- nats_streaming/swarm.md | 10 +++++----- nats_tools/natsbench.md | 4 ++-- nats_tools/nsc/nsc.md | 4 ++-- nats_tools/nsc/services.md | 6 +++--- 7 files changed, 20 insertions(+), 20 deletions(-) diff --git a/developer/tutorials/custom_dialer.md b/developer/tutorials/custom_dialer.md index 5e23c8a..590f93f 100644 --- a/developer/tutorials/custom_dialer.md +++ b/developer/tutorials/custom_dialer.md @@ -15,7 +15,7 @@ import ( "net" "time" - "github.com/nats-io/go-nats" + "github.com/nats-io/nats.go" ) type customDialer struct { @@ -129,4 +129,4 @@ WaitForEstablishedConnection: } log.Println("Disconnected") } -``` \ No newline at end of file +``` diff --git a/developer/tutorials/queues.md b/developer/tutorials/queues.md index d996f12..e7ccc03 100644 --- a/developer/tutorials/queues.md +++ b/developer/tutorials/queues.md @@ -15,7 +15,7 @@ nats-server ### 2. Clone the repositories for each client examples ```sh -go get github.com/nats-io/go-nats +go get github.com/nats-io/nats.go git clone https://github.com/nats-io/node-nats.git git clone https://github.com/nats-io/ruby-nats.git ``` @@ -23,7 +23,7 @@ git clone https://github.com/nats-io/ruby-nats.git ### 3. Run the Go client subscriber with queue group name ```sh -cd $GOPATH/src/github.com/nats-io/go-nats/examples +cd $GOPATH/src/github.com/nats-io/nats.go/examples go run nats-qsub.go foo my-queue ``` @@ -45,14 +45,14 @@ nats-queue foo my-queue & ### 6. Run another Go client subscriber *without* the queue group. ```sh -cd $GOPATH/src/github.com/nats-io/go-nats/examples +cd $GOPATH/src/github.com/nats-io/nats.go/examples go run nats-sub.go foo ``` ### 7. Publish a NATS message using the Go client ```sh -cd $GOPATH/src/github.com/nats-io/go-nats/examples +cd $GOPATH/src/github.com/nats-io/nats.go/examples go run nats-pub.go foo "Hello NATS!" ``` diff --git a/nats_admin/upgrading_cluster.md b/nats_admin/upgrading_cluster.md index 112da96..2be07a6 100644 --- a/nats_admin/upgrading_cluster.md +++ b/nats_admin/upgrading_cluster.md @@ -34,7 +34,7 @@ Let's get one client, so we can observe it moving between servers as servers get nats-sub -s nats://localhost:4222 ">" ``` -Nats-sub is a subscriber sample included with all NATS clients. Nats-sub subscribes to a subject and prints out any messages received. You can find the source code to the go version of nats-sub [here)(https://github.com/nats-io/go-nats/tree/master/examples). After starting the subscriber you should see a message on 'A' that a new client connected. +`nats-sub` is a subscriber sample included with all NATS clients. `nats-sub` subscribes to a subject and prints out any messages received. You can find the source code to the go version of `nats-sub` [here)(https://github.com/nats-io/nats.go/tree/master/examples). After starting the subscriber you should see a message on 'A' that a new client connected. We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.' Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go besides 'A.' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](/developer/reconnect/random.md/). Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'T.' @@ -83,4 +83,4 @@ nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6 nats-server -D -p 4444 -cluster nats://localhost:6444 -routes nats://localhost:6222 ``` -Once they connect to the 'seed server', the will learn about all the other servers and connect to each other forming the full mesh. \ No newline at end of file +Once they connect to the 'seed server', the will learn about all the other servers and connect to each other forming the full mesh. diff --git a/nats_streaming/swarm.md b/nats_streaming/swarm.md index 16437cb..da3b3d5 100644 --- a/nats_streaming/swarm.md +++ b/nats_streaming/swarm.md @@ -47,18 +47,18 @@ be routing the messages so that they will be processed to the NATS Streaming clu ```sh $ sudo docker run --network nats-streaming-example -it golang:latest -root@d12f9f3fcdde:/go# cd src/github.com/nats-io/go-nats-streaming/ +root@d12f9f3fcdde:/go# cd src/github.com/nats-io/stan.go/ # Publishing 3 messages -root@d12f9f3fcdde:/go/src/github.com/nats-io/go-nats-streaming# go run examples/stan-pub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm hello world +root@d12f9f3fcdde:/go/src/github.com/nats-io/stan.go# go run examples/stan-pub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm hello world Published [hello] : 'world' -root@d12f9f3fcdde:/go/src/github.com/nats-io/go-nats-streaming# go run examples/stan-pub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm hello world +root@d12f9f3fcdde:/go/src/github.com/nats-io/stan.go# go run examples/stan-pub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm hello world Published [hello] : 'world' -root@d12f9f3fcdde:/go/src/github.com/nats-io/go-nats-streaming# go run examples/stan-pub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm hello world +root@d12f9f3fcdde:/go/src/github.com/nats-io/stan.go# go run examples/stan-pub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm hello world Published [hello] : 'world' # Replaying the messages from the beginning -root@d12f9f3fcdde:/go/src/github.com/nats-io/go-nats-streaming# go run examples/stan-sub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm -id $RANDOM --all hello +root@d12f9f3fcdde:/go/src/github.com/nats-io/stan.go# go run examples/stan-sub/main.go -s nats://nats-cluster-node-1:4222 --cluster swarm -id $RANDOM --all hello Connected to nats://nats-cluster-node-1:4222 clusterID: [swarm] clientID: [17010] subscribing with DeliverAllAvailable Listening on [hello], clientID=[17010], qgroup=[] durable=[] diff --git a/nats_tools/natsbench.md b/nats_tools/natsbench.md index b31c531..10b9a3a 100644 --- a/nats_tools/natsbench.md +++ b/nats_tools/natsbench.md @@ -29,13 +29,13 @@ The NATS benchmark can be installed and run via Go. Ensure your golang environm There are two approaches; you can either install the `nats-bench` utility in the directory specified in your `GOBIN` environment variable: ```sh -% go install $GOPATH/src/github.com/nats-io/go-nats/examples/nats-bench.go +% go install $GOPATH/src/github.com/nats-io/nats.go/examples/nats-bench.go ``` ... or you can simply run it via `go run`: ```sh -% go run $GOPATH/src/github.com/nats-io/go-nats/examples/nats-bench.go +% go run $GOPATH/src/github.com/nats-io/nats.go/examples/nats-bench.go ``` *On windows use the % environment variable syntax, replacing `$GOPATH` with `%GOPATH%`.* diff --git a/nats_tools/nsc/nsc.md b/nats_tools/nsc/nsc.md index 69570f9..7b20f44 100644 --- a/nats_tools/nsc/nsc.md +++ b/nats_tools/nsc/nsc.md @@ -216,9 +216,9 @@ At minimum the server requires the `operator` JWT, which we have pointed at dire Let’s install some tooling: ```text -> go get github.com/nats-io/go-nats/examples/nats-pub +> go get github.com/nats-io/nats.go/examples/nats-pub -> go get github.com/nats-io/go-nats/examples/nats-sub +> go get github.com/nats-io/nats.go/examples/nats-sub ``` Create a subscriber: diff --git a/nats_tools/nsc/services.md b/nats_tools/nsc/services.md index 13b0528..7902923 100644 --- a/nats_tools/nsc/services.md +++ b/nats_tools/nsc/services.md @@ -100,7 +100,7 @@ To test the service, we can install the `nats-req` and `nats-rply` tools: Set up a process to handle the request: ```text -> go get github.com/nats-io/go-nats/examples/nats-rply +> go get github.com/nats-io/nats.go/examples/nats-rply > nats-rply -creds ~/.nkeys/Test/accounts/AccountB/users/userb.creds "help" "I will help" Listening on [help] @@ -108,7 +108,7 @@ Listening on [help] Send the request: ```text -> go get github.com/nats-io/go-nats/examples/nats-req +> go get github.com/nats-io/nats.go/examples/nats-req > nats-req -creds ~/.nkeys/Test/accounts/AccountB/users/userb.creds help me Published [help] : 'me' ``` @@ -290,4 +290,4 @@ The service receives the message: The requester receives its response: ```text Received [_INBOX.N3IiqWbiAQfPoINCBpBrUM.ZjBNtkB3] : 'I will help' -``` \ No newline at end of file +``` From acfbe94a623c6e01a0e0c3bc466ea441a5d4174a Mon Sep 17 00:00:00 2001 From: Ginger Collison Date: Wed, 5 Jun 2019 17:11:27 -0500 Subject: [PATCH 2/4] Update upgrading_cluster.md --- nats_admin/upgrading_cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nats_admin/upgrading_cluster.md b/nats_admin/upgrading_cluster.md index 2be07a6..98946cc 100644 --- a/nats_admin/upgrading_cluster.md +++ b/nats_admin/upgrading_cluster.md @@ -83,4 +83,4 @@ nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6 nats-server -D -p 4444 -cluster nats://localhost:6444 -routes nats://localhost:6222 ``` -Once they connect to the 'seed server', the will learn about all the other servers and connect to each other forming the full mesh. +Once they connect to the 'seed server', they will learn about all the other servers and connect to each other forming the full mesh. From 91fe174dc532d831eb5a208d58db38ec6fb60d6a Mon Sep 17 00:00:00 2001 From: Ginger Collison Date: Wed, 5 Jun 2019 17:16:56 -0500 Subject: [PATCH 3/4] Update upgrading_cluster.md --- nats_admin/upgrading_cluster.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/nats_admin/upgrading_cluster.md b/nats_admin/upgrading_cluster.md index 98946cc..fe7e1ae 100644 --- a/nats_admin/upgrading_cluster.md +++ b/nats_admin/upgrading_cluster.md @@ -1,6 +1,6 @@ ## Cluster Upgrading -The basic strategy for upgrading a cluster revolves around the server's ability to gossip cluster configuration to clients and other servers. When cluster configuration changes, clients become aware of new servers automatically. In case of a disconnect, a client has a list of servers that joined the cluster in addition to the ones it knew about from its connection settings. +The basic strategy for upgrading a cluster revolves around the server's ability to gossip cluster configuration to clients and other servers. When cluster configuration changes, clients become aware of new servers automatically. In the case of a disconnect, a client has a list of servers that joined the cluster in addition to the ones it knew about from its connection settings. Note that since each server stores it's own permission and authentication configuration, new servers added to a cluster should provide the same users and authorization to prevent clients from getting rejected or gaining unexpected privileges. @@ -36,7 +36,7 @@ nats-sub -s nats://localhost:4222 ">" `nats-sub` is a subscriber sample included with all NATS clients. `nats-sub` subscribes to a subject and prints out any messages received. You can find the source code to the go version of `nats-sub` [here)(https://github.com/nats-io/nats.go/tree/master/examples). After starting the subscriber you should see a message on 'A' that a new client connected. -We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.' Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go besides 'A.' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](/developer/reconnect/random.md/). +We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.' Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go other than 'A.' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](/developer/reconnect/random.md/). Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'T.' Let's start our temporary server: From a30c45072f87de66ae9b36b79e8e79f76a7538ce Mon Sep 17 00:00:00 2001 From: Ginger Collison Date: Wed, 5 Jun 2019 17:28:05 -0500 Subject: [PATCH 4/4] Update upgrading_cluster.md --- nats_admin/upgrading_cluster.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/nats_admin/upgrading_cluster.md b/nats_admin/upgrading_cluster.md index fe7e1ae..f3997cd 100644 --- a/nats_admin/upgrading_cluster.md +++ b/nats_admin/upgrading_cluster.md @@ -27,7 +27,7 @@ Let's fix that, by starting the second server: ```bash nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6222,nats://localhost:6333 ``` -The second server was started on port 4333 with its cluster port on 6333. Otherwise the same as 'A.' +The second server was started on port 4333 with its cluster port on 6333. Otherwise the same as 'A'. Let's get one client, so we can observe it moving between servers as servers get removed: ```bash @@ -36,8 +36,8 @@ nats-sub -s nats://localhost:4222 ">" `nats-sub` is a subscriber sample included with all NATS clients. `nats-sub` subscribes to a subject and prints out any messages received. You can find the source code to the go version of `nats-sub` [here)(https://github.com/nats-io/nats.go/tree/master/examples). After starting the subscriber you should see a message on 'A' that a new client connected. -We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.' Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go other than 'A.' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](/developer/reconnect/random.md/). -Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'T.' +We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A', let's introduce a new server 'C'. Server 'C' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go other than 'A' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](/developer/reconnect/random.md/). +Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'C'. Let's start our temporary server: @@ -45,9 +45,9 @@ Let's start our temporary server: nats-server -D -p 4444 -cluster nats://localhost:6444 -routes nats://localhost:6222,nats://localhost:6333 ``` -After an instant or so, clients on 'A' learn of the new cluster member that joined. On our hands-on tutorial, `nats-sub` is now aware of 3 possible servers, 'A' (specified when we started the tool) and 'B' and 'T' learned from the cluster gossip. +After an instant or so, clients on 'A' learn of the new cluster member that joined. On our hands-on tutorial, `nats-sub` is now aware of 3 possible servers, 'A' (specified when we started the tool) and 'B' and 'C' learned from the cluster gossip. -We invoke our admin powers and turn off 'A' by issuing a `CTRL+C` to the terminal on 'A,' and observe that either 'B' or 'T' reports that a new client connected. That is our `nats-sub` client. +We invoke our admin powers and turn off 'A' by issuing a `CTRL+C` to the terminal on 'A' and observe that either 'B' or 'C' reports that a new client connected. That is our `nats-sub` client. We perform the upgrade process, update the binary for 'A', and restart 'A': @@ -55,13 +55,13 @@ We perform the upgrade process, update the binary for 'A', and restart 'A': nats-server -D -p 4222 -cluster nats://localhost:6222 -routes nats://localhost:6222,nats://localhost:6333 ``` -We move on to upgrade 'B'. Notice that clients from 'B' reconnect to 'A' and 'T'. We upgrade and restart 'B': +We move on to upgrade 'B'. Notice that clients from 'B' reconnect to 'A' and 'C'. We upgrade and restart 'B': ```bash nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6222,nats://localhost:6333 ``` -If we had more servers, we would continue the stop, update, restart rotation as we did for 'A' and 'B.' After restarting the last server, we can go ahead and turn off 'T.' Any clients on 'T' will redistribute to our permanent cluster members. +If we had more servers, we would continue the stop, update, restart rotation as we did for 'A' and 'B'. After restarting the last server, we can go ahead and turn off 'C.' Any clients on 'C' will redistribute to our permanent cluster members. ### Seed Servers