Releases · nats-io/nats-server

09 Sep 22:12

NATS-CI

v2.5.0

b3c19b9

Release v2.5.0

Changelog

Notice for JetStream Users

See important note if upgrading from a version prior to v2.4.0.

Notice for MQTT Users

See note in the Improved and Changed section.

Go Version

1.16.8: Both release executables and Docker images are built with this Go release.

Added

MQTT/Monitoring:
- MQTTClient in the /connz connections report and system events CONNECT and DISCONNECT. Ability to select on mqtt_client. Thanks to @carr123 and @imranrazakhan for the suggestions (#2507)

Improved

MQTT:
- Sessions are now all stored inside a single stream, as opposed to individual streams, reducing resources usage (#2501)

Changed

JetStream:
- Using Nats-Expected-Last-Subject-Sequence header with a value of 0 now means that the server will reject the store command if there were messages on this subject (#2506)
MQTT:
- Due to 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_sess stream for the user's account (#2501)

Fixed

JetStream:
- Possible deadlock due to lock inversion (#2479)
- Possible consumer stall. Thanks to @carr123 for the report (#2480)
- Don't send 408 status when pull request expires. This has no visible impact for users, but library implementers may want to be aware of it (#2482)
- During peer removal, try to remap any stream or consumer assets (#2493)
- Issues with remapping of stream and/or consumer assets during peer removal (#2493)
- Issue that could lead to perceived message loss (#2490)
- Message cleanup for interest stream and AckNone consumers in clustered mode (#2499)
- Suppress duplicates on JS deny all for system account (#2502)
- Consumers stopped receiving messages. Thanks to @anjmao, @izarraga and @tigrato for the report (#2505)
Handle SIGTERM on Windows platform (#2481)
Account resolver TLS connection may fail with x509: certificate signed by unknown authority errors. Thanks to @Ryner51, @ronaldslc for the report (#2483)

Complete Changes

v2.4.0...v2.5.0

Contributors

ronaldslc, Ryner51, and 5 other contributors

Assets 37

26 Aug 22:24

NATS-CI

v2.4.0

e49eb66

Release v2.4.0

Changelog

Notice for JetStream Users

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 than 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 heartbeat 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 PushBound in the consumer information object set by the server), this mis-behavior is still possible.
Queue subscriptions will not receive any message. This is because the server now has a new field DeliverGroup in 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 an 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 update 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 PushBound boolean 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 DeliverGroup field. 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 DeliverGroup field 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.