STAN NATS Streaming Server
WARNING Deprecation Notice
The NATS Streaming Server is being deprecated. Critical bug fixes and security fixes will be applied until June of 2023. NATS-enabled applications requiring persistence should use JetStream.
Refer to the release notes for granular details.
Version
0.25.0Version
0.24.0Version
0.23.0Version
0.22.0Version
0.21.0Version
0.20.0Version
0.19.0Version
0.18.0Version
0.17.0Version
0.16.0Version
0.15.0Version
0.14.0Version
0.12.0Version
0.11.0Version
0.10.0Version
0.9.0Version
0.8.0-betaVersion
0.6.0Version
0.5.0Version
0.4.0
Version 0.25.0
0.25.0This release has the following changes:
Channel names are now treated as case-insensitive, but requires clients to use the same case as it was originally defined
FileStore now supported a
RecordSizeLimitLeadershp-acquired actions could get stuck due to an insufficiently-sized notification channel causing the cluster unavailable to clients
Version 0.24.0
0.24.0The vendor directory has been removed in favor of native go mod support.
Version 0.23.0
0.23.0In cluster mode, redelivery of a message can now be performed to any member of a group rather than strictly the member it was originally delivered to.
Version 0.22.0
0.22.0This release exposes the HTTP handler in embedded mode and fixes a possible panic on shutdown in cluster mode.
Version 0.21.0
0.21.0This release adds the subscription count to the monitoring endpoint. In addition, clustering performance and contention has been improved.
See deprecation notice.
Version 0.20.0
0.20.0This release adds support for the replace_durable configuration option. If enabled, when a connection sends a subscription request for a durable that is detected as a duplicate, the server will replace the old one with the new one.
In addition, a bulk_insert_limit option within the sql { } block can be defined to control the transaction size.
Version 0.19.0
0.19.0This release adds:
NKey authentication support
Authentication fields in the streaming config block
The ability to add and remove nodes at runtime in clustered mode
Version 0.18.0
0.18.0This release adds a streaming/isFTActive endpoint to determine if FT mode is active or not as well as a handful of fixes.
Version 0.17.0
0.17.0This release adds:
additional details to the monitoring endpoint
server_nameandskip_verifyconfiguration parameterssupport for redelivery count on messages
Version 0.16.0
0.16.0This release adds support for the RISC-V platform, adds a few optimizations to the store backends, and introduces official Debian and RPM packages.
Version 0.15.0
0.15.0This release embeds NATS v2.0.0 which is a new major version of the server including the wire protocol.
Backwards compatibility note
Note that the Streaming server itself is backward compatible with previous releases, however, v0.15.0 now embeds a NATS Server 2.0, which means that if you run with the embedded NATS server and want to route it to your existing v0.14.3- servers, it will fail due to NATS Server routing protocol change. You can however use v0.15.0 and connect it to existing NATS cluster and therefore have a mix of v0.15.0 and v0.14.3- streaming servers.
Version 0.14.0
0.14.0This release adds support for custom NATS client options in the the server configuration.
In addition, a variety of fixes and improvements were made to clustering.
Version 0.12.0
0.12.0This release adds encryption at rest for message payloads as well as open and max file descriptor counts were added to the streaming/serverz monitoring endpoint.
In addition, a variety of fixes on subscriptions and clustering were made.
Version 0.11.0
0.11.0This adds the ability to run STAN as a Windows service.
In addition, a variety of fixes were applied to the File and SQL store backends, including the potential of redelivery of acknowledged messages.
Version 0.10.0
0.10.0The server needs to persist more state for a client connection. Therefore, the Store interface has been changed:
Changed
AddClient(clientID, hbInbox string)toAddClient(info *spb.ClientInfo)
For SQL Stores, the Clients table has been altered to add a proto column.
You can update the SQL table manually or run the provided scripts that create the tables if they don't exists and alter the Clients table adding the new column. For instance, with MySQL, you would run something similar to:
The above assumes you are in the NATS Streaming Server directory, and the streaming database is called nss_db.
Otherwise, from the mysql CLI, you can run the command:
For Postgres, it would be:
If you run the server version with 0.10.0 a database that has not been updated, you would get the following error:
Version 0.9.0
0.9.0Additions to the Store interface to support deletion of channels.
Added
Store.GetChannelLimits()API to return the store limits for a given channel.Added
Store.DeleteChannel()API to delete a channel.
Protocol was added to support replication of deletion of a channel in the cluster.
Version 0.8.0-beta
0.8.0-betaThe Store interface has been slightly changed to accommodate the clustering feature.
Changed
MstStore.Store()API to accept a*pb.MsgProtoinstead of a byte array. This is because the server is now assigning the sequence number.The store implementation should ignore the call if the given sequence number is below or equal to what has been already stored.
Added
MsgStore.Empty()API to empty a given channel message store.
Version 0.6.0
0.6.0The Store interface has been heavily modified. Some of the responsibilities have been moved into the server resulting on deletion of some Store APIs and removal of UserData fields in Client and ChannelStore (renamed Channel) objects.
NOTE: Although the interface has changed, the file format of the FileStore implementation has not, which means that there is backward/forward compatibility between this and previous releases.
The Store interface was updated:
Added error
ErrAlreadyExiststhatCreateChannel()should return if channel already exists.RecoveredStatehas nowChannels(instead ofSubs) and is a map of*RecoveredChannelkeyed by channel name.RecoveredChannelhas a pointer to aChannel(formelyChannelStore) and an array of pointers toRecoveredSubscriptionobjects.RecoveredSubscriptionreplacesRecoveredSubState.Clientno longer stores aUserDatafield.Channel(formerlyChannelStore) no longer stores aUserDatafield.CreateChannel()no longer accepts auserData interface{}parameter. It returns a*Channeland anerror. If the channelalready exists, the error
ErrAlreadyExistsis returned.LookupChannel(),HasChannel(),GetChannels(),GetChannelsCount(),GetClient(),GetClients,GetClientsCount()andMsgsState()APIshave all been removed. The server keeps track of clients and channels and therefore does not need those APIs.
AddClient()is now simply returning a*Clientanderror. It no longer accepts auserData interface{}parameter.DeleteClient()now returns an error instead of returning the deleted*Client. This will allow the server toreport possible errors.
The SubStore interface was updated:
DeleteSub()has been modified to return an error. This allows the server to report possible errors during deletionof a subscription.
The MsgStore interface was updated:
Lookup(),FirstSequence(),LastSequence(),FirstAndLastSequence(),GetSequenceFromTimestamp(),FirstMsg()andLastMsg()have all been modified to return an error. This is so that implementations that may fail to lookup, get the first sequence, etc...
have a way to report the error to the caller.
Version 0.5.0
0.5.0The Store interface was updated. There are 2 news APIs:
GetChannels(): Returns a map of*ChannelStore, keyed by channel names.
The implementation needs to return a copy to make it safe for the caller to manipulate
the map without a risk of concurrent access.
GetChannelsCount(): Returns the number of channels currently stored.
Version 0.4.0
0.4.0The Store interface was updated. There are 2 news APIs:
Recover(): The recovery of persistent state was previously done in the constructor of the store implementation.
It is now separate and specified with this API. The server will first instantiate the store, in
which some initialization or checks can be made.
If no error is reported, the server will then proceed with calling Recover(), which will returned the recovered state.
GetExclusiveLock(): In Fault Tolerance mode, when a server is elected leader, it will attempt to get an exclusivelock to the shared storage before proceeding.
Check the Store interface for more information.