When js-enabled is set to true, the condition was only checked if
the `getJetStream()` call returned `nil`. However, if it non-nil,
all remaining checks were executed, including assessing the health
of the assets (streams and consumers).
This change addresses two issues:
- Switch to use `js.isEnabled()` which will check whether the value
is nil OR `js.disabled = true` which can occur if the subsystem
is temporarily disabled (insufficient resources).
- Correctly exit the check after the assertion and before meta and
asset checks are performed.
In addition, the option has been renamed to `js-enabled-only` to align
with the `js-server-only` naming. The previous `js-enabled` name still
works, but is mapped to this new option. A warning is emitted noting
the previous option is deprecated.
Fix#3703
Signed-off-by: Byron Ruth <b@devel.io>
With the increase use of subject based limits not being able
to store due to limits exceeded happens frequently and makes
running the server in debug quite noisy, so we rate limit this
log line even in debug
Signed-off-by: R.I.Pienaar <rip@devco.net>
This was causing longer than necessary startup times
since by default they would have been using the same
temporary directory and the extra account lookups
due to a previous JS run using different accounts.
Signed-off-by: Waldemar Quevedo <wally@nats.io>
The bug was when a timestamp for the pending state was exactly -1 which could happen based on timing of the redlivered pending items which would set pending.Timestamp into the future potentially and the timing on the encodeConsumerState call.
Minor fixes to raft.
Signed-off-by: Derek Collison <derek@nats.io>
First issue was applications not getting any response.
However, there was also a more serious issue that would create multiple raft groups for each concurrent request.
The servers would only run one stream monitor loop, however they would update the state to the new raft group's name, so on server restart the stream would be using a different raft group then existing servers.
Signed-off-by: Derek Collison <derek@nats.io>
Lower minimum amount of data / number of operations so that benchmarks
can run in reasonable time.
Minimum amount of work should be controlled via `-benchtime` flag. But
due to these hardcoded limits, some tests were taking too long.
e.g. Running for 2 minutes even with `-benchtime` set to 1 second.
This ensures the logic that triggers user disconnections
share the same code paths and sets the same variables
Signed-off-by: R.I.Pienaar <rip@devco.net>
This is only added if set by a user or account expiration claim.
It is represented as a duration til expiration vs absolute time which would involve time zone and clock sync issues.
Signed-off-by: Derek Collison <derek@nats.io>
