- [X] Link to issue, e.g. `Resolves #4141`
- [X] Tests added
- [X] Branch rebased on top of current dev
- [X] Changes squashed to a single commit (described
[here](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
- [x] Build is green in Travis CI
- [X] You have certified that the contribution is your original work and
that you license the work to the project under the [Apache 2
license](https://github.com/nats-io/nats-server/blob/main/LICENSE)
Resolves#4141
### Changes proposed in this pull request:
Adds a check that the stream name of a stream source is valid and
associated new error if it isn't.
Currently `UpdateKnownPeers` doesn't send a peer state when a single
peer add operation is taking place, but it seems like this can
potentially race when there are lots of changes to the replica count
happening in rapid succession. Sending the peer state in all cases seems
to fix this issue and, so far in my testing, fixes the failground stream
update replicas test.
Signed-off-by: Neil Twigg <neil@nats.io>
When consumers were R1 and the same name was reused, server restarts
could try to cleanup old ones and effect the new ones. These changes
allow consumer name reuse more effectively during server restarts.
Signed-off-by: Derek Collison <derek@nats.io>
- [ ] Link to issue, e.g. `Resolves #NNN`
- [ ] Documentation added (if applicable)
- [ ] Tests added
- [ ] Branch rebased on top of current main (`git pull --rebase origin
main`)
- [ ] Changes squashed to a single commit (described
[here](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
- [x] Build is green in Travis CI
- [x] You have certified that the contribution is your original work and
that you license the work to the project under the [Apache 2
license](https://github.com/nats-io/nats-server/blob/main/LICENSE)
Resolves panics in the code.
### Changes proposed in this pull request:
- This PR fixes some of the panics in the code
PR https://github.com/nats-io/nats-server/pull/4212 fixed the issue I
reported in https://github.com/nats-io/nats-server/issues/4196.
However, I believe there might be a bug when both `sequence` and `keep`
are set during recovery.
In the `PurgeEx` the following check is done (for both `filestore.go`
and `memstore.go`):
```go
if sequence > 1 && keep > 0 {
return 0, ErrPurgeArgMismatch
}
```
The `TestJetStreamClusterPurgeExReplayAfterRestart` also triggers this
case, meaning that during the test this error is returned but it
succeeds because the purge was already performed. Is this intended
behaviour?
To elaborate a bit more, I believe the following happens:
- when running the purge normally it will properly run the `keep` (since
it's not combined with `sequence` yet)
- when replaying the purge though, the `sequence` is added to the
`keep`, which errors out in the above if
Which means that during normal operation all will be well, but purges
with `keep` will be ignored upon replaying.
I'm proposing to remove the `sequence > 1 && keep > 0` check and
subsequent error. Which, for reference, was introduced in
https://github.com/nats-io/nats-server/pull/3121.
Hoping this ensures that during recovery, purges that haven't executed
yet will still be executed.
An alternative approach, which wouldn't remove the error: not allow
combining `sequence` and `keep` normally and only allowing it during
recovery. Which would preserve the current behaviour, and correctly
apply `sequence+keep` during recovery still. However, not sure if it's
possible to know if we're in "recovery mode" from within `PurgeEx`.
Resolves https://github.com/nats-io/nats-server/issues/4196
This is an extension to the excellent work by @MauriceVanVeen and his
original PR #4197 to fully resolve for all use cases.
Signed-off-by: Derek Collison <derek@nats.io>
Resolves#4196
When a server was killed on restart before an encrypted stream was
recovered the keyfile was removed and could cause the stream to not be
recoverable.
We only needed to delete the key file when converting ciphers and right
before we add the stream itself.
Signed-off-by: Derek Collison <derek@nats.io>
Resolves#4195
When we were optimizing for single cluster and large numbers of
leafnodes we inadvertently broke a daisy chained scenario where a server
was a spoke and a hub within a single hub server.
So interest on D would not propagate properly to server A as a
publisher.
```
B
/ \
A C -- D (SUB)
|
PUB
```
This records the server time when info for streams and consumers are
created so that tools such as the nats cli can calculate time deltas for
last ack, last delivered and so forth in the context of the server
clock.
This will help aleviate problems with client devices experiencing clock
jitter that can show up in user interfaces as negative seconds since
last ack etc
- [X] Tests added
- [X] Branch rebased on top of current main (`git pull --rebase origin
main`)
- [X] Changes squashed to a single commit (described
[here](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
- [ ] Build is green in Travis CI
- [X] You have certified that the contribution is your original work and
that you license the work to the project under the [Apache 2
license](https://github.com/nats-io/nats-server/blob/main/LICENSE)
### Changes proposed in this pull request:
1: Improves error reporting for weighted mappings:
As it was, any error in a weighted mapping would return a very
unhelpfull error message.
e.g. `nats-server: mappingtest.cfg:38:39: interface conversion:
interface {} is []interface {}, not string`
This was because the line `err := &configErr{tk, fmt.Sprintf("Error
adding mapping for %q to %q : %v", subj, v.(string), err)}` would panic
on the `v.(string)` since in weighted mapping that interface{} is
actually a map[string]interface{} (since there's can be more than one
mapping in weighted mappings).
Now returns the actual error:
e.g. `nats-server: mappingtest.cfg:40:3: Error adding mapping for "bla"
: invalid mapping destination: wildcard index out of range in
{{wildcard(1)}}`
2: improves subject transform checking and catches if the destination is
using a mapping function and there are no partial wildcards in the
source.
By publishing retained messages on their own subject, we can apply max
messages per subject limits to them. Also include the domain name in the
subject to make consistent with the other MQTT streams.
Signed-off-by: Neil Twigg <neil@nats.io>
I was running a manual test moving from dev to this branch and
noticed that the consumer would receive only 1 message of the 10
messages sent as retained. So I modified the test to verify that
we receive them all and we did not.
The reason was that after the transfer we need to refresh the state
of the stream (stream info) since we attempt to load all messages
based on the state's sequences.
I have also modified a bit the code to update the MaxMsgsPer once
all messages have been transferred.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
While adding more complex test scenarios, some issues in
multiple-filters approach surfaced.
This PR adds those tests and addresses the issues.
Signed-off-by: Tomasz Pietrek <tomasz@nats.io>
