Sometimes when scaling down a stream, a raft node could continue
forwarding proposals after already being closed, in the debug logs this
can be confirmed by many entries logging 'Direct proposal ignored, not
leader (state: CLOSED)'.
### Changes proposed in this pull request:
NATS Server 2.9 has `logfile_size_limit` option which allows the
operator to set an optional byte limit on the NATS Server log file which
when met causes a "rotation" such that the current log file is renamed
(original file name appended with a time stamp to nanosecond accuracy)
and a new log file is instantiated.
This PR is a new `logfile_max_num` companion option (alias
`log_max_num`) which allows the operator to designate that the server
should prune the **total number of log files** -- the currently active
log file plus backups -- to the maximum setting.
A max value of `0` (the implicit default) or a negative number has
meaning of unlimited log files (no maximum) as this is an opt-in
feature.
A max value of `1` is effectively a truncate-only logging pattern as any
backup made at rotation will subsequently be purged.
A max value of `2` will maintain the active log file plus the latest
backup. And so on...
> The currently active log file is never purged. Only backups are
purged.
When enabled, backup log deletion is evaluated inline after each
successful rotation event. To be considered for log deletion, backup log
files MUST adhere to the file naming format used in log rotation as well
as agree with the current `logfile` name and location. Any other files
or sub-directories in the log directory will be ignored. E.g. if an
operator makes a manual copy of the log file to `logfile.bak` that file
will not be evaluated as a backup.
### Typical use case:
This feature is useful in a constrained hosting environment for NATS
Server, for example an embedded, edge-compute, or IoT device scenario,
in which _more featureful_ platform or operating system log management
features do not exist or the complexity is not required.
We fixed a few bugs in tombstone handling, and formalized support for
holes in the underlying buffers. Due to customer data from the field we
also now use holes during compaction.
Signed-off-by: Derek Collison <derek@nats.io>
Make sure the client handshake flag is set when TLS handshake is made as
part of WebSocket connection/upgrade (notionally HTTPS) rather than as
part of the NATS protocol TLS initiation chain. AuthCallout tests the
flag when building the data for the AuthCallout service request.
Added AuthCallout unit test for NATS WS client auth that requires the
TLS data.
Repeated calls to `scheduleSetSourceConsumerRetry` could end up creating
multiple timers for the same source, which would eventually schedule
even more timers, which would result in runaway CPU usage. This PR
instead bounds to one timer per source per stream.
Signed-off-by: Neil Twigg <neil@nats.io>
This adds a new `waitForAccount` test helper that ensures that an
account exists across the cluster, and updates
`TestJetStreamClusterAccountPurge` to use it after submitting new JWTs.
This should prevent `require no error, but got: nats: JetStream not
enabled for account` errors.
Signed-off-by: Neil Twigg <neil@nats.io>
This unprotected access allowed the cache to most likely be flushed and
after a subsequent writeMsgRecord would have the offset > slot value
which can't happen if lock is held due to us loading cache properly at
beginning of the function.
Signed-off-by: Derek Collison <derek@nats.io>
Resolves#4529
