What's New!
The NATS.io team is always working to bring you features to improve your NATS experience. Below you will find feature summaries for new implementations to NATS. Check back often for release highlights and updates.
Please check out the announcement post on the blog and the detailed release notes in the server repo.
Support for a
min_version in the leafnodes{} that would reject servers with a lower version. Note that this would work only for servers that are v2.8.0 and above.- Server version in monitoring landing page.
- Logging to
/healthzendpoint when failure occurs. - MQTT and Websocket blocks in the
/varzendpoint.
- Consumer check added to
healthzendpoint. - Max stream bytes checks.
- Ability to limit a consumer's
MaxAckPendingvalue. - Allow streams and consumers to migrate between clusters. This feature is considered "beta".
- New
unique_tagoption injetstream{}configuration block to prevent placing a stream in the same availability zone twice. - Stream
Alternatesfield inStreamInforesponse. They provide a priority list of mirrors and the source in relation to where the request originated. - Deterministic subject tokens to partition mapping.
For full release information, see links below;
Ability to configure account limits (
max_connections, max_subscriptions, max_payload, max_leafnodes) in server configuration file.- Overflow placement for streams. A stream can now be placed in the closest cluster from the origin request if it can be placed there.
- Support for ephemeral Pull consumers (client libraries will need to be updated to allow those).
- New consumer configuration options
- For Pull Consumers:
MaxRequestBatchto limit the batch size any client can requestMaxRequestExpiresto limit the expiration any client can request - For ephemeral consumers:
InactiveThresholdduration that instructs the server to cleanup ephemeral consumers that are inactive for that long.
- Ability to configure
max_file_storeandmax_memory_storein thejetstream{}block as strings with the following suffixesK,M,GandT, for instance:max_file_store: "256M". - Support for the JWT field
MaxBytesRequired, which defines a per-account maximum bytes for assets.
Support for websocket protocol. MQTT clients must connect to the opened websocket port and add
/mqtt to the URL path.Ability to rate-limit the clients connections by adding the
connection_rate_limit: <number of connections per seconds> in the tls{} top-level block.For full release information, see links below;
- JetStream's reserved memory and memory used from accounts with reservations in
/jszand/varzendpoints - Hardened systemd service
For full release information, see links below;
MQTTClientin the/connzconnections report and system events CONNECT and DISCONNECT. Ability to select onmqtt_client.
- Sessions are now all stored inside a single stream, as opposed to individual streams, reducing resources usage.
- Due to the aforementioned improvement described above, when an MQTT client connects for the first time after an upgrade to this server version, the server will migrate all individual
$MQTT_sess_<xxxx>streams to a new$MQTT_sessstream for the user's account.
For full release information, see links below;
With the latest release of the NATS server, we have fixed bugs around queue subscriptions and have restricted undesired behavior that could be confusing or introduce data loss by unintended/undefined behavior of client applications. If you are using queue subscriptions on a JetStream Push Consumer or have created multiple push subscriptions on the same consumer, you may be affected and need to upgrade your client version along with the server version. We’ve detailed the behavior with different client versions below.
With a NATS Server prior to v2.4.0 and client libraries prior to these versions: NATS C client v3.1.0, Go client v1.12.0, Java client 2.12.0-SNAPSHOT, NATS.js v2.2.0, NATS.ws v1.3.0, NATS.deno v1.2.0, NATS .NET 0.14.0-pre2:
- It was possible to create multiple non-queue subscription instances for the same JetStream durable consumer. This is not correct since each instance will receive the same copy of a message and acknowledgment is therefore meaningless since the first instance to acknowledge the message will prevent other instances to control if/when a message should be acknowledged.
- Similar to the first issue, it was possible to create many different queue groups for one single JetStream consumer.
- For queue subscriptions, if no consumer nor durable name was provided, the libraries would create ephemeral JetStream consumers, which meant that each member of the same group would receive the same message as the other members, which was not the expected behavior. Users assumed that 2 members subscribing to “foo” with the queue group named “bar” would load-balance the consumption of messages from the stream/consumer.
- It was possible to create a queue subscription on a JetStream consumer configured with heartbeat and/or flow control. This does not make sense because by definition, queue members would receive some (randomly distributed) messages, so the library would think that heartbeats are missed, and flow control would also be disrupted.
If above client libraries are not updated to the latest but the NATS Server is upgraded to v2.4.0:
- It is still possible to create multiple non-queue subscription instances for the same JetStream durable consumer. Since the check is performed by the library (with the help of a new field called
PushBoundin the consumer information object set by the server), this misbehavior is still possible. - Queue subscriptions will not receive any message. This is because the server now has a new field
DeliverGroupin the consumer configuration, which won’t be set for existing JetStream consumers and by the older libraries, and detects interest (and starts delivering) only when a subscription on the deliver subject for a queue subscription matching the “deliver group” name is found. Since the JetStream consumer is thought to be a non-deliver-group consumer, the opposite happens: the server detects a core NATS queue subscription on the “deliver subject”, therefore does not trigger delivery on the JetStream consumer’s “deliver subject”.
The 2 other issues are still present because those checks are done in the updated libraries.
If the above client libraries are updated to the latest version, but the NATS Server is still to version prior to v2.4.0 (that is, up to v2.3.4):
- It is still possible to create multiple non-queue subscription instances for the same JetStream durable consumer. This is because the JetStream consumer’s information retrieved by the library will not have the
PushBoundboolean set by the server, therefore will not be able to alert the user that they are trying to create multiple subscription instances for the same JetStream consumer. - Queue subscriptions will fail because the consumer information returned will not contain the
DeliverGroupfield. The error will be likely to the effect that the user tries to create a queue subscription to a non-queue JetStream consumer. Note that if the application creates a queue subscription for a non-yet created JetStream consumer, then this call will succeed, however, adding new members or restarting the application with the now existing JetStream consumer will fail. - Creating queue subscriptions without a named consumer/durable will now result in the library using the queue name as the durable name.
- Trying to create a queue subscription with a consumer configuration that has heartbeat and/or flow control will now return an error message.
For completeness, using the latest client libraries and NATS Server v2.4.0:
- Trying to start multiple non-queue subscriptions instances for the same JetStream consumer will now return an error to the effect that the user is trying to create a “duplicate subscription”. That is, there is already an active subscription on that JetStream consumer. It is now only possible to create a queue group for a JetStream consumer created for that group. The
DeliverGroupfield will be set by the library or need to be provided when creating the consumer externally. - Trying to create a queue subscription without a durable nor consumer name results in the library creating/using the queue group as the JetStream consumer’s durable name.
- Trying to create a queue subscription with a consumer configuration that has heartbeat and/or flow control will now return an error message.
Note that if the server v2.4.0 recovers existing JetStream consumers that were created prior to v2.4.0 (and with older libraries), none of them will have a
DeliverGroup, so none of them can be used for queue subscriptions. They will have to be recreated.- Domain to the content of a
PubAckprotocol PushBoundboolean inConsumerInfoto indicate that a push consumer is already bound to an active subscriptionDeliverGroupstring inConsumerConfigto specify which deliver group (or queue group name) the consumer is created for- Warning log statement in situations where catchup for a stream resulted in an error
- The ability for normal accounts to access scoped
connzinformation
- Operator option
resolver_pinned_accountsto ensure users are signed by certain accounts
For full release information, see links below;
- Richer API errors. JetStream errors now contain an ErrCode that uniquely describes the error.
- Ability to send more advanced Stream purge requests that can purge all messages for a specific subject
- Stream can now be configured with a per-subject message limit
- Encryption of JetStream data at rest
For full release information, see links below;
Monitoring endpoints as listed in the table below are accessible as system services using the following subject pattern:
$SYS.REQ.SERVER.<id>.<endpoint-name>(request server monitoring endpoint corresponding to endpoint name.)$SYS.REQ.SERVER.PING.<endpoint-name>(from all server request server monitoring endpoint corresponding to endpoint name - will return multiple messages)
Configuration of
no_auth_user allows you to refer to a configured user/account when no credentials are provided.For full release information, see links below;
This release adds the ability to specify TLS configuration for the account resolver.
resolver_tls {
cert_file: ...
key_file: ...
ca_file: ...
}
We've added the option to include subscription details in monitoring endpoints
/routez and /connz. For instance /connz?subs=detail will now return not only the subjects of the subscription, but the queue name (if applicable) and some other details.NATS introduces
logfile_size_limit allowing auto-rotation of log files when the size is greater than the configured limit set in logfile_size_limit as a number of bytes. You can provide the size with units, such as MB, GB, etc. The backup files will have the same name as the original log file with the suffix .yyyy.mm.dd.hh.mm.ss.micros. For more information see Configuring Logging in the NATS Server Configuration section.Queue Permissions allow you to express authorization for queue groups. As queue groups are integral to implementing horizontally scalable microservices, control of who is allowed to join a specific queue group is important to the overall security model. Original PR - https://github.com/nats-io/nats-server/pull/1143
As services and service mesh functionality has become prominent, we have been looking at ways to make running scalable services on NATS.io a great experience. One area we have been looking at is observability. With publish/subscribe systems, everything is inherently observable, however we realized it was not as simple as it could be. We wanted the ability to transparently add service latency tracking to any given service with no changes to the application. We also realized that global systems, such as those NATS.io can support, needed something more than a single metric. The solution was to allow any sampling rate to be attached to an exported service, with a delivery subject for all collected metrics. We collect metrics that show the requestor’s view of latency, the responder’s view of latency and the NATS subsystem itself, even when requestor and responder are in different parts of the world and connected to different servers in a NATS supercluster.
For services, the authorization for responding to requests usually included wildcards for _INBOX.> and possibly $GR.> with a supercluster for sending responses. What we really wanted was the ability to allow a service responder to only respond to the reply subject it was sent.
Exported Services were originally tied to a single response. We added the type for the service response and now support singletons (default), streams and chunked. Stream responses represent multiple response messages, chunked represents a single response that may have to be broken up into multiple messages.
Last modified 2mo ago