mirror of
https://github.com/gogrlx/nats-server.git
synced 2026-04-14 10:10:42 -07:00
22514a033f
### 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.
Tests
Tests that run on Travis have been split into jobs that run in their own VM in parallel. This reduces the overall running time but also is allowing recycling of a job when we get a flapper as opposed to have to recycle the whole test suite.
JetStream Tests
For JetStream tests, we need to observe a naming convention so that no tests are omitted when running on Travis.
The script runTestsOnTravis.sh will run a given job based on the definition found in ".travis.yml".
As for the naming convention:
- All JetStream tests name should start with
TestJetStream - Cluster tests should go into
jetstream_cluster_test.goand start withTestJetStreamCluster - Super-cluster tests should go into
jetstream_super_cluster_test.goand start withTestJetStreamSuperCluster
Not following this convention means that some tests may not be executed on Travis.