This option is not available in the config, and is only accessable to
embeded servers where when using custom loggers can look pretty terrible
- [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))
- [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)
### Changes proposed in this pull request:
- Add ability to disable the jetstream ascii art banner on embeded
servers as when using custom logging skews the ascii art.
```
INFO[2023-06-20T21:00:54-07:00] Starting JetStream
INFO[2023-06-20T21:00:54-07:00] _ ___ _____ ___ _____ ___ ___ _ __ __
INFO[2023-06-20T21:00:54-07:00] _ | | __|_ _/ __|_ _| _ \ __| /_\ | \/ |
INFO[2023-06-20T21:00:54-07:00] | || | _| | | \__ \ | | | / _| / _ \| |\/| |
INFO[2023-06-20T21:00:54-07:00] \__/|___| |_| |___/ |_| |_|_\___/_/ \_\_| |_|
INFO[2023-06-20T21:00:54-07:00]
INFO[2023-06-20T21:00:54-07:00] https://docs.nats.io/jetstream
INFO[2023-06-20T21:00:54-07:00]
```
Previously, the server would reject a second remote leafnode connection
from the same server if it was binding to the same account on the hub
even if the remote was using different local accounts.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Previously, the server would reject a second remote leafnode connection
from the same server if it was binding to the same account on the hub
even if the remote was using different local accounts.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
This allows the CPU and goroutine profiles to be annotated with
information that allows us to break down load based on accounts, streams
and consumers. We could probably add more labels elsewhere for other
purposes too. It makes it easier to spot whether there are certain
assets that are responsible for heavy CPU usage, i.e. snapshotting
certain stream states.
Signed-off-by: Neil Twigg <neil@nats.io>
This fixes#4252 by ensuring that `tls_available`, `tls_required`, `host` and `port`
are populated based on the WebSocket listener rather than standard listeners.
Signed-off-by: Neil Twigg <neil@nats.io>
This fixes#4252 by ensuring that `tls_available`, `tls_required`,
`host` and `port` are populated based on the WebSocket listener rather
than standard listeners.
Signed-off-by: Neil Twigg <neil@nats.io>
This fixes#4252 by ensuring that `tls_available`, `tls_required`, `host` and `port`
are populated based on the WebSocket listener rather than standard listeners.
Signed-off-by: Neil Twigg <neil@nats.io>
This unit test is modelled around issue #4247 and proves that the
`MaxMsgs` and `MaxMsgsPer` limits are correctly enforced together with
`DiscardNew` and `DiscardNewPer`.
Signed-off-by: Neil Twigg <neil@nats.io>
This test has multiple leafnode connections to different accounts and to
a shared account to make sure behavior is correct.
Signed-off-by: Derek Collison <derek@nats.io>
This test has multiple leafnode connections to different accounts and to a shared account to make sure behavior is correct.
Signed-off-by: Derek Collison <derek@nats.io>
When creating replicated mirrors where the source stream had a very
large starting sequence number, the server would use excessive CPU and
Memory.
This is due to the mirroring functionality trying to skip messages when
it detects a gap. In a replicated stream this puts excessive stress on
the raft system.
This step is not needed at all if the mirror stream has no messages, we
can simply jump ahead.
Signed-off-by: Derek Collison <derek@nats.io>
This is due to the mirroring functionality trying to skip messages when it detects a gap. In a replicated stream this puts excessive stress on the raft system.
This step is not needed at all if the mirror stream has no messages, we can simply jump ahead.
Signed-off-by: Derek Collison <derek@nats.io>
Cert Store (aka wincert) feature wasn't properly handling TLS 1.2
handshake with TLS 1.2 clients that do not support RSA signature with
PSS padding.
With this update, Cert Store will perform either PKCS#1 v1.5 or PSS
padding for RSA signature depending on what type is negotiated by the
TLS 1.2 client.
Issue surfaces with the NATS .NET v1 client which supports TLS 1.2 only
(.NET 4.6.2 dependency) only when the client application was hosted on
Windows 10 Enterprise LTSC 2019 (equivalent also to Windows 10 1809 and
Windows Server 2019). If the same client was executed on a more modern
Windows 10 release, RSA signature with PSS padding was negotiated and
succeeded normally.
The Go NATS client as well as any client operating at TLS 1.3 level
would not exhibit the issue as TLS 1.3 requires PSS.
Fix tested good on Windows 10 Enterprise LTSC 2019 host and in confirmed
fixed in user's Windows environment where the issue was originally
detected.
The `.` character will be transformed to `//` in NATS subject. For
instance an MQTT message published on `spBv1.0/plant1` would be received
by a NATS subscriber as `spBv1//0.plant1`.
Conversely, a NATS message published on `spBv1//0.plant1` would be
received by an MQTT subscriber as `spBv1.0/plant1`.
Resolves#1879Resolves#3482
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
The `.` character will be transformed to `//` in NATS subject. For
instance an MQTT message published on `spBv1.0/plant1` would
be received by a NATS subscriber as `spBv1//0.plant1`.
Conversely, a NATS message published on `spBv1//0.plant1` would
be received by an MQTT subscriber as `spBv1.0/plant1`.
Resolves#1879Resolves#3482
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
This PR separates out the small amount of necessary metadata for
retained messages (stream sequence, floor) from the message itself,
instead accessing the messages themselves with KV-like access patterns.
This should save quite a bit of memory where there are lots of retained
messages since we only now need to hold a small amount of metadata
instead of the entire messages.
Signed-off-by: Neil Twigg <neil@nats.io>
