-
I have been experimenting with Jetstream for use as an IoT data store. The idea is that leaf or hub nodes may come and go, but when things connect again, all the streams sync up. This example attempts to synchronize streams in two directions. https://github.com/simpleiot/nats-exp/blob/main/bi-directional-sync/main.go |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
added code that shuts down the leaf node, and the leaf stream is still available on the hub instance. Then I power the leaf back up, and publish 5 more messages. On the leaf node, I now see 10 messages (5 before and 5 after cycle leaf node). But on the hub node, I see 15 messages I the sourced stream from the leaf node -- the 2nd set of 5 gets published twice. How is this happening? To reproduce test:
|
Beta Was this translation helpful? Give feedback.
-
Just added code to push messages to hub while leaf is down, and when leaf reconnects, I don't see the messages on the sourced stream on the leaf node -- probably doing something wrong, but out of time today. |
Beta Was this translation helpful? Give feedback.
-
It looks like both the stream on the hub and the one on the LN, are listening to the same subjects. This means that even though the two streams are in different JS domains, as they are listening on the same Core NATS subject if the Core NATS messages on those subject(s) are allowed to flow between the hub and the LNs then both streams will store the message: that could explain duplicated messages. |
Beta Was this translation helpful? Give feedback.
-
I cleaned up this code and increased the timeout, now when I shutdown the leaf node and start it back up, the messages that were published on the hub while it was down sync after about 6s (I had the timeout set to 5 previously, so that appears to be why it did not work). This is very neat -- everything is now working as expected. One more step forward to a Jetstream store for SIOT. Log of current program:
|
Beta Was this translation helpful? Give feedback.
It looks like both the stream on the hub and the one on the LN, are listening to the same subjects. This means that even though the two streams are in different JS domains, as they are listening on the same Core NATS subject if the Core NATS messages on those subject(s) are allowed to flow between the hub and the LNs then both streams will store the message: that could explain duplicated messages.