NATS Streaming System
Home Page: https://nats.io
License: Apache License 2.0
We're evaluating NATS Streaming Server for the PubSub system in a microservices architecture. We currently use it only for simple "fire-and-forget" messaging such as progress notifications.
While using that, we found that the number of goroutines in go-nats-streaming seems to be ever increasing. This is what we get after running the web server part for a while. It seems that the goroutines are stuck in stan.go:402.
goroutine profile: total 168
69 @ 0x3f20d 0x3f2fe 0x13b08 0x1380d 0x58d855 0x72111
# 0x58d854 github.com/meplato/cloud/vendor/github.com/nats-io/go-nats-streaming.(*conn).publishAsync.func1+0x144 /Users/oliver/gocode/src/github.com/meplato/cloud/vendor/github.com/nats-io/go-nats-streaming/stan.go:402
8 @ 0x3f20d 0x50133 0x4eddc 0x25167e 0x72111
# 0x25167d github.com/meplato/cloud/vendor/google.golang.org/grpc.newClientStream.func2+0x54d /Users/oliver/gocode/src/github.com/meplato/cloud/vendor/google.golang.org/grpc/stream.go:204
After a while, this number exceeds the number of goroutines that the race detector considers to be a problem (race: limit on 8192 simultaneously alive goroutines is exceeded, dying).
goroutine profile: total 1141
1042 @ 0x3f20d 0x3f2fe 0x13b08 0x1380d 0x58d855 0x72111
# 0x58d854 github.com/meplato/cloud/vendor/github.com/nats-io/go-nats-streaming.(*conn).publishAsync.func1+0x144 /Users/oliver/gocode/src/github.com/meplato/cloud/vendor/github.com/nats-io/go-nats-streaming/stan.go:402
8 @ 0x3f20d 0x50133 0x4eddc 0x25167e 0x72111
# 0x25167d github.com/meplato/cloud/vendor/google.golang.org/grpc.newClientStream.func2+0x54d /Users/oliver/gocode/src/github.com/meplato/cloud/vendor/google.golang.org/grpc/stream.go:204
Here's how we publish messages:
// PublishJSON publishes a message serialized as JSON.
// Strings, pointers to strings, and byte arrays get sent as-is,
// all other objects are serialized as JSON.
func (b *natsBroker) PublishJSON(ctx context.Context, topic string, msg interface{}) error {
switch msg := msg.(type) {
case string:
return b.conn.Publish(topic, []byte(msg))
case *string:
if msg == nil {
return b.conn.Publish(topic, nil)
}
return b.conn.Publish(topic, []byte(*msg))
case []byte:
return b.conn.Publish(topic, msg)
}
// Fallback to JSON encoding
data, err := json.Marshal(msg)
if err != nil {
return err
}
return b.conn.Publish(topic, data)
}
...
// Publish progress
sch.broker.PublishJSON(context.Background(), sync.ProgressTopic, sync.ProgressEvent{
Current: int(current),
Total: int(total),
ETA: eta.Unix(),
})
We're using the current version of NATS streaming server from the GitHub repository:
[52172] 2016/12/29 12:30:02.190442 [INF] Starting nats-streaming-server[cloud-nats] version 0.3.7
[52172] 2016/12/29 12:30:02.190681 [INF] Starting nats-server version 0.9.6
[52172] 2016/12/29 12:30:02.190712 [INF] Listening for client connections on 0.0.0.0:4222
[52172] 2016/12/29 12:30:02.190806 [INF] Server is ready
[52172] 2016/12/29 12:30:02.469346 [INF] STAN: Message store is MEMORY
[52172] 2016/12/29 12:30:02.469358 [INF] STAN: --------- Store Limits ---------
[52172] 2016/12/29 12:30:02.469362 [INF] STAN: Channels: 100 *
[52172] 2016/12/29 12:30:02.469369 [INF] STAN: -------- channels limits -------
[52172] 2016/12/29 12:30:02.469372 [INF] STAN: Subscriptions: 1000 *
[52172] 2016/12/29 12:30:02.469376 [INF] STAN: Messages : 1000000 *
[52172] 2016/12/29 12:30:02.469397 [INF] STAN: Bytes : 976.56 MB *
[52172] 2016/12/29 12:30:02.469399 [INF] STAN: Age : unlimited *
[52172] 2016/12/29 12:30:02.469400 [INF] STAN: --------------------------------
Of course, this could as well be a problem on our side. Can you give us a hint on how to debug this problem?
When an application crashes, it may not call the STAN Close() function, so STAN will hold the application's clientID as if it were connected. This leaves STAN in a state where it will prevent a connection with the same ClientID, erroneously indicating it is a duplicate.
I propose we:
a) Add a disconnected alert/advisory from NATS that STAN can listen to. Upon a client disconnect, the NATS server publishes an advisory message containing the client name, perhaps in JSON format.
b) STAN uses the client ID as the NATS client name to connect.
c) STAN listens on the advisory subject and removes the client ID when notified a client has been disconnected.
stan-server depends on go-stan imports to build, while go-stan depends on stan-server imports in order to test. Propose that we find a way to ensure that the server depends on the client (only), and not vice versa.
The underlying connection should be closed (if owned) if Connect() fails to return a STAN connection.
Hi experts,
I have successfully run the Nats-Streaming Go clients to publish and subscribe and consume the message from a nats-streaming server.
Would appreciate if someone can help me on how I pub and sub with ack and the ack results can be called back in the client.
Another related question: If the message is delivered to subscriber successfully with an acr, will Nats Streaming Server automatically delete the message from the store? If no, how can we implement that? I know there is a max message in store for each channel, but the delivered messages will take up unnecessary storage.
Thank u in advance
Steven Tan
ps: sorry I accidentally posted the message in nats
I think at least a simple stan-pub and stan-sub are required for the preview.
TBD
-Messages may be redelivered only once
-Panic in redelivery for regular subs when there are messages that have not yet expired
-Race conditions when reseting the ack timer
for over 5 hours I was trying to figure out why I was getting stan: invalid connection request only to find out after reading the streaming server code that clientId can only be alphanumeric + '_' + '-'.
many goroutines, one client, publish message cocurrently.
got two kinds of error:
write tcp 127.0.0.1:48714->127.0.0.1:4222: write: connection reset by peer
stan: publish ack timeout
https://github.com/nats-io/stan/blob/master/stan_test.go#L1465-L1468
This test fails sporadically, perhaps 25% of the time, in Travis CI. Testing for exactly 1 or exactly 2 messages on sub2 seems flawed IMO. The algorithm cannot guarantee that outcome under all circumstances (as testing in Travis proves). Either the server algorithm is broken or the requirement we're testing is ill-defined. Let's fix one or the other so this test is more reliable.
(First discussed in #10)
Seeing this a lot in stan_test.go (e.g. here)
if err != nil {
t.Fatalf("Expected non-nil error on Subscribe, got %v\n", err)
}
I'm pretty sure this says the opposite of what is intended.
A durable (including durable queue subscriber) would be removed from the server - so delivery to this subscriber would stop - without removing the durable interest, that is, durable subscription can be resumed.
A summary:
Unsubscribe() removes the durable subscription. A restart with same durable name is a new one and can receive old messages.Unsubscribe() removes the durable queue group.Close() stops delivery to this subscriber but does not remove the durable subscription (the durable queue group is not removed by the last member calling Close()).Close() when connecting to a server that does not offer this feature causes the API to return the error ErrNoServerSupport.Close() is equivalent to Unsubscribe(), so no error is returned even if connecting to an older server.In TestPubMultiQueueSubWithSlowSubscriber:
https://github.com/nats-io/stan/blob/master/stan_test.go#L1136-L1218
...the assumption that s2 will get exactly 1 or 2 messages due to the artificial 500ms delay seems a little magical and/or tied to timing characteristics of a specific execution environment. Can we generalize this test somehow, or better articulate what it's meant to prove, and how?
See here and here in server.go.
As a user, if my SubscriptionRequest specifies a time 100 seconds in the past, but the earliest stored message was 80 seconds in the past, I get stan: invalid start time. IMO that's broken, conceptually.
Think of how you'd use a "since" date when qualifying Google search results (i.e. show me hits since this date). If I entered 1/1/2016, but the first result was from 1/3/2016, I'd expect to get everything starting from 1/3/2016, and not an error indicating that my "since" date was wrong. The same applies here: if my start time is before the earliest message, just start with the earliest message!
It's tempting to say "well, just use StartPosition.First instead", but I as a user actually require data since exactly (at most) 100 seconds ago, and I have no idea when "First" will start (3 days, 2 hours, or 5 seconds).
I propose that if start time (or sequence) is earlier than the first message, that we start with the first message, and likewise that if the start time (or sequence) is later than the last message, we set the start time/sequence to 1ns or 1 seqno after the last message (i.e. default to StartPosition.NewOnly).
WARNING: DATA RACE
Write by goroutine 516:
github.com/nats-io/stan.(*conn).PublishAsyncWithReply()
/home/travis/gopath/src/github.com/nats-io/stan/stan.go:354 +0x935
github.com/nats-io/stan.(*conn).PublishWithReply()
/home/travis/gopath/src/github.com/nats-io/stan/stan.go:313 +0x13f
github.com/nats-io/stan.(*conn).Publish()
/home/travis/gopath/src/github.com/nats-io/stan/stan.go:297 +0x8d
github.com/nats-io/stan.TestPubMultiQueueSub()
/home/travis/gopath/src/github.com/nats-io/stan/stan_test.go:1410 +0xbb9
testing.tRunner()
/tmp/workdir/go/src/testing/testing.go:456 +0xdc
Previous read by goroutine 541:
github.com/nats-io/stan.(*conn).removeAck()
/home/travis/gopath/src/github.com/nats-io/stan/stan.go:374 +0x16b
github.com/nats-io/stan.(*conn).processAck()
/home/travis/gopath/src/github.com/nats-io/stan/stan.go:283 +0x171
github.com/nats-io/stan.(*conn).(github.com/nats-io/stan.processAck)-fm()
/home/travis/gopath/src/github.com/nats-io/stan/stan.go:200 +0x37
github.com/nats-io/nats.(*Conn).waitForMsgs()
/home/travis/gopath/src/github.com/nats-io/nats/nats.go:1355 +0x3aa
Goroutine 516 (running) created at:
testing.RunTests()
/tmp/workdir/go/src/testing/testing.go:561 +0xaa3
testing.(*M).Run()
/tmp/workdir/go/src/testing/testing.go:494 +0xe4
main.main()
github.com/nats-io/stan/_test/_testmain.go:146 +0x20f
Goroutine 541 (running) created at:
github.com/nats-io/nats.(*Conn).subscribe()
/home/travis/gopath/src/github.com/nats-io/nats/nats.go:1813 +0x504
github.com/nats-io/nats.(*Conn).Subscribe()
/home/travis/gopath/src/github.com/nats-io/nats/nats.go:1730 +0x7a
github.com/nats-io/stan.Connect()
/home/travis/gopath/src/github.com/nats-io/stan/stan.go:200 +0x1161
github.com/nats-io/stan.NewDefaultConnection()
/home/travis/gopath/src/github.com/nats-io/stan/stan_test.go:98 +0x92
github.com/nats-io/stan.TestPubMultiQueueSub()
/home/travis/gopath/src/github.com/nats-io/stan/stan_test.go:1359 +0xda
testing.tRunner()
/tmp/workdir/go/src/testing/testing.go:456 +0xdc
An option builder is missing. Also, when closing the STAN connection, the NATS connection should not be closed.
Hi, i am trying to connect go stan client to remote stan server and server tell me something like that
" 2016/07/16 21:48:31 Can't connect: nats: no servers available for connection.
Make sure a NATS Streaming Server is running at: nats://10.0.1.60:4222
"
steps what i am do:
2 start server with command:
"./nats-streaming-server -c seed.conf"
who tell me
"
[6763] 2016/07/16 22:52:05.256046 [INF] Starting nats-streaming-server[test-cluster] version 0.2.0
[6763] 2016/07/16 22:52:05.256521 [INF] Starting nats-server version 0.9.0.beta
[6763] 2016/07/16 22:52:05.256544 [INF] Starting http monitor on :8222
[6763] 2016/07/16 22:52:05.256643 [INF] Listening for client connections on 0.0.0.0:4222
"
3. I want to send message to server from other computer whith standart instruction on site
go run stan-pub.go -c "nats://10.0.1.60:4222" foo "msg one"
and take a message :
Make sure a NATS Streaming Server is running at: nats://10.0.1.60:4222
what am i doing wrong?
==================
WARNING: DATA RACE
Write by goroutine 8:
github.com/nats-io/stan.(*conn).Close()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan.go:239 +0x1c1
runtime.call32()
(...)
Previous read by goroutine 68:
github.com/nats-io/stan.(*conn).processHeartBeat()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan.go:270 +0x3a
github.com/nats-io/stan.(*conn).(github.com/nats-io/stan.processHeartBeat)-fm()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan.go:161 +0x37
github.com/nats-io/nats.(*Conn).waitForMsgs()
/Users/ivan/dev/go/src/github.com/nats-io/nats/nats.go:1355 +0x3aa
==================
The examples need to be more robust in detecting missing parameters and reporting this more accurately to provide a better user experience.
e.g.
go run stan-sub.go test-cluster foo
Can't connect: stan: invalid connection request
exit status 1
is output from missing the required -id parameter.
Although we will allow passing in a NATS connection, ideally we will still allow the user to create a STAN connection from scratch. This requires passing in or otherwise allowing configuring the required NATS options e.g. (importantly) TLS and various connect/reconnect timeouts and options.
#27 solves this in the short term, but API simplicity is key, so we should still allow creating a STAN connection from scratch with no pre-existing NATS conn.
Possible approaches:
==================
WARNING: DATA RACE
Write by goroutine 170:
github.com/nats-io/stan.(*conn).Close()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan.go:204 +0x1b3
github.com/nats-io/stan.TestUnsubscribeWhileConnClosing.func1()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan_test.go:624 +0x56
Previous read by goroutine 127:
github.com/nats-io/stan.(*subscription).Unsubscribe()
/Users/ivan/dev/go/src/github.com/nats-io/stan/sub.go:260 +0x47f
github.com/nats-io/stan.TestUnsubscribeWhileConnClosing()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan_test.go:629 +0x519
testing.tRunner()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/testing/testing.go:456 +0xdc
Goroutine 170 (running) created at:
github.com/nats-io/stan.TestUnsubscribeWhileConnClosing()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan_test.go:626 +0x4ff
testing.tRunner()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/testing/testing.go:456 +0xdc
Goroutine 127 (running) created at:
testing.RunTests()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/testing/testing.go:561 +0xaa3
testing.(*M).Run()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/testing/testing.go:494 +0xe4
main.main()
github.com/nats-io/stan/_test/_testmain.go:116 +0x20f
==================
Normal NATS implements request that automatically creates a inbox for a reply and blocks until a server responds. I might be completely off here as I just see NATS streaming as a message bus+persistence. Is there a fundamental reason this neat feature is missing? It would be very handy in my use case(HTTP request uploads a video file, it's pushed into NATS where a number of workers will asynchronously pick up segments of the file and start processing at different points, thus allowing distributed processing of many very very large files).
This is more of a question of why would I not want to do this? If it's just a incomplete feature I can port it and provide a PR.
==================
WARNING: DATA RACE
Write by goroutine 30:
github.com/nats-io/go-stan.(*conn).Close()
/Users/ivan/dev/go/src/github.com/nats-io/go-stan/stan.go:239 +0x1c1
runtime.call32()
/usr/local/go/src/runtime/asm_amd64.s:472 +0x3d
testing.(*common).Fatal()
/usr/local/go/src/testing/testing.go:383 +0x7c
(...)
Previous read by goroutine 27:
github.com/nats-io/go-stan.(*Msg).Ack()
/Users/ivan/dev/go/src/github.com/nats-io/go-stan/sub.go:331 +0x34b
(...)
github.com/nats-io/go-stan.(*conn).processMsg()
/Users/ivan/dev/go/src/github.com/nats-io/go-stan/stan.go:435 +0x456
github.com/nats-io/go-stan.(*conn).(github.com/nats-io/go-stan.processMsg)-fm()
/Users/ivan/dev/go/src/github.com/nats-io/go-stan/sub.go:196 +0x37
github.com/nats-io/nats.(*Conn).waitForMsgs()
/Users/ivan/dev/go/src/github.com/nats-io/nats/nats.go:1355 +0x3aa
====================
Looking at the code, it seems that for a PublishAsync call, if the client side times-out, the AckHandler would be invoked with a timeout error, even though a PubAck was received from the server and reported back to the AckHandler.
For the synchronous Publish() call, it may result in a "leak" of timer closure function since processAckTimeout() will be blocked in a chan send, or worse, block the connection ability to process further acks since processAck() would be blocked trying to send result to the channel.
The client and server code need to be in separate repositories.
The usage for stan-bench (https://github.com/nats-io/go-nats-streaming/blob/master/examples/stan-bench.go) is incorrect since it currently refers to "nats-bench" when it should be referring to "stan-bench". Since the usage for stan-bench has some different options from the nats-bench usage, I suspect that this is the only issue with the usage output. But someone who knows the code better should check.
Calling Close() on an already closed connection should not produce an error. IMO the only case in which it should return an error is if the Close Request fails, and therefore the user code may need/want to do something to make sure the clientID is released properly, or log the error.
We need to provide a mechanism for users to install async error and connection callbacks, or to preserve/honor already-registered callbacks when passing a NATS connection into a STAN connection (see #27).
One approach we have discussed is to have STAN install its own connection handlers, and to invoke any callbacks the user may have already registered on the NATS connection from the STAN handlers.
This can also be applied if we allow STAN to install connection handlers via the client API, i.e. if the user invokes sc.setDisconnectedCallback(someCB), we could invoke this from within our own STAN-installed callbacks.
==================
WARNING: DATA RACE
Read by goroutine 591:
github.com/nats-io/stan.TestNoDuplicatesOnSubscriberStart.func1()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan_test.go:1728 +0x61
github.com/nats-io/stan.(*conn).processMsg()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan.go:426 +0x458
github.com/nats-io/stan.(*conn).(github.com/nats-io/stan.processMsg)-fm()
/Users/ivan/dev/go/src/github.com/nats-io/stan/sub.go:196 +0x37
github.com/nats-io/nats.(*Conn).waitForMsgs()
/Users/ivan/dev/go/src/github.com/nats-io/nats/nats.go:1355 +0x3aa
Previous write by goroutine 590:
sync/atomic.AddInt32()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/runtime/race_amd64.s:255 +0xb
github.com/nats-io/stan.TestNoDuplicatesOnSubscriberStart.func2()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan_test.go:1739 +0xaf
Goroutine 591 (running) created at:
github.com/nats-io/nats.(*Conn).subscribe()
/Users/ivan/dev/go/src/github.com/nats-io/nats/nats.go:1813 +0x504
github.com/nats-io/nats.(*Conn).Subscribe()
/Users/ivan/dev/go/src/github.com/nats-io/nats/nats.go:1730 +0x7a
github.com/nats-io/stan.(*conn).subscribe()
/Users/ivan/dev/go/src/github.com/nats-io/stan/sub.go:196 +0x605
github.com/nats-io/stan.(*conn).Subscribe()
/Users/ivan/dev/go/src/github.com/nats-io/stan/sub.go:164 +0xbe
github.com/nats-io/stan.TestNoDuplicatesOnSubscriberStart()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan_test.go:1753 +0x663
testing.tRunner()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/testing/testing.go:456 +0xdc
Goroutine 590 (running) created at:
github.com/nats-io/stan.TestNoDuplicatesOnSubscriberStart()
/Users/ivan/dev/go/src/github.com/nats-io/stan/stan_test.go:1747 +0x57c
testing.tRunner()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/testing/testing.go:456 +0xdc
==================
Is the separation of nats-streaming-server / gnatsd and the client libraries only temporary or will it persist in the future as well?
I am wondering if internally subscription callback work on some worker pool kind of architecture. If yes does it impact anyway when it comes to durable subscriptions? If not is it up to calling code to spawn message consumption in a separate go routine?
Ideally protocol.proto should have no external cross-language dependencies. Right now, it imports gogoprotobuf, which requires that you have a go environment installed on your build system and gogoprotobuf installed. For a java or C# client, this doesn't make sense. Protobuf allows for language-specific options (e.g. java_package, go_package, etc), but apparently not language-specific imports.
If possible, we should find a way to isolate the Go-specific parts of the .proto file and put them in a separate .proto.
The goal is to have a .proto file that does not depend on go, and does not require editing in order to use in other non-go projects.
EDIT: we aren't the first ones to deal with this. The folks at cockroachdb solved it by putting their proto file in a separate repo along with a Makefile and scripts to produce clean proto files: https://github.com/cockroachdb/cockroach-proto/
Barring a better idea, we could follow this approach.
Hello,
I'm working on a project that was using the plain ol' go-nats package, but I wanted some of the streaming functionality provided by this package so I'm in the process of switching it around.
I'm running into the error stan: connect request timeout and I can't seem to figure out why this is occurring. I'm setting a connection to the stan.Conn using the Option helper like so:
// nConn is assigned to a successfully connected *nats.Conn struct
stanConn, err := stan.Connect("consumer", "consumer",
stan.NatsConn(nConn),
stan.ConnectWait(time.Second*10),
)
However this is giving the error listed in the title.
I've isolated it to this line in the go-nats package: https://github.com/nats-io/go-nats/blob/master/nats.go#L2085
Any thoughts on what might be causing this? I was using the go-nats package just fine, publishing and subscribing messages with no hiccups.
As far as I can see with my limited go skills, the stan.Connect() just reraises errors from its underlying call, instead of reinterpreting them according to its context.
It would be nice if it could give more interesting error messages to the users, e.g. if it receives a INFO block from the server, it can evaluate things like server version instead of just raising a timeout error. Or if it can't read it, it can raise an error like got INFO block but can't read it: <info output printed>.
This can save hours to users trying to debug things, since for instance on a timeout error one first expects that there's a network or DNS problem, and not that server and client just have different versions and therefore can't talk to each other.
Server-to-Client heart beats need to be configurable:
Something along the lines of:
We should discuss if the server sends the interval in the connect response and the clients behave accordingly, or we require the client to set this explicitly and independently. IMO sending these to the client will reduce support costs and make STAN simpler for users.
When a test starts a server and immediately after calls Connect(), there is a risk of getting a timeout.
We I restart the server the pub and sub stop to send and receive data. I have try to handler close connection but without success.
Hello
in https://github.com/nats-io/go-nats
I can send a response to client after receive a message and get this data
var response string
err := c.Request("help", "help me", &response, 10*time.Millisecond) ...How i can send to client a response here and get a data on the client side? I can't find.
Thank you
We need a file store module.
Our README needs a level of detail similar to the gnatsd/nats README.
-When queue group name is specified (-qgroup), a durable is actually created.
-Durable are automatically unsubscribed (deleted) on exit.
It would be nice if the STAN conn exposed a way to get the wrapped NATS conn. For example, if I have a STAN conn, I want to check if it's connected to NATS. Either STAN would need to have a Status() method which calls through to the NATS conn or we just allow you to get the NATS conn itself.
I see the potential dangers with this (e.g. closing the underlying NATS conn would be quite problematic), but if you are passing in your own NATS conn, this is already a possibility. And if STAN is creating the NATS conn for you, there's currently no way to check the NATS status.
In my application I've a client that is publishing to a queue group as per following code.
NatsConn.Publish("NotificationQueue", msgByte)
NatsConn -- global connection to Nats Streaming.
Receiver is initialized during bootstrap with function like this:
func InitSubscribers() {
_, err := NatsConn.QueueSubscribe("NotificationQueue", "NotificationQueue", NotificationListener, stan.DurableName("DurableStore"))
}
The issue I am facing is that subscription delivery to listeners is not working and I am seeing following errors
[DBG] STREAM: [Client:] Redelivering on ack expiration, subject=NotificationQueue, inbox=_INBOX.YOWGP5dxClqIzeZ4uNhHn1
as well as
[DBG] STREAM: [Client:service001] Timed out on heartbeats
[DBG] STREAM: [Client:service001] Closed (Inbox=_INBOX.Uz0R99NZTSe467Ox6XIJTw)
Just wanted to check if there is some configuration that I may be missing.
TestBasicPubSubFlowControl
https://github.com/nats-io/stan/blob/master/stan_test.go#L325-L356
This test has 3 success criteria:
It doesn't appear to prove anything regarding flow control, and doesn't appear to prove anything more than TestBasicPubSub does. Removing the MaxInFlight setting wouldn't change the outcome of the test. Proposals:
Requires dependency (import) updates and related travis and coveralls changes.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.