21.2 | Kurrent Docs
Skip to main content

21.2

EventStoreDB 21.2

  • Released: 25 February 2021
  • Supported until: June 2021

21.2.0

In this release

Gossip on single node

With the latest release, all nodes have gossip enabled by default. You can connect using gossip seeds regardless of whether you have a cluster or not.

Please note that the GossipOnSingleNode option has been deprecated in this version and will be removed in version 21.10.0.

Heartbeat timeout improvements

In a scenario where one side of a connection to EventStoreDB is sending a lot of data and the other side is idle, a false-positive heartbeat timeout can occur for the following reasons:

  • The heartbeat request may need to wait behind a lot of other data on the send queue on the sender's side or on the receive queue on the receiver's side before it can be processed.
  • The receiver does not schedule any heartbeat request to the sender as it assumes that the connection is alive.
  • The sender's heartbeat request can eventually take more time than the heartbeat timeout to reach the receiver and be processed causing a false-positive heartbeat timeout to occur.

In this release, we have extended the heartbeat logic by proactively scheduling a heartbeat request from the receiver to the sender to prevent the heartbeat timeout. This should lower the number of incorrect heartbeat timeouts that occur on busy clusters.

KeepAlives for gRPC

The server now supports gRPC keep alives, and has been configured to send a KeepAlive message over gRPC connections every 10 seconds by default. This means that gRPC clients will be able to discover if their connection has been dropped.

The interval and timeout for KeepAlives on the server can be configured with the KeepAliveInterval and KeepAliveTimeout settings. Please note that these may need to be configured on your gRPC client as well, please check your client’s release notes for more information.

Persistent subscriptions

The parked message count is now available on the stats of a persistent subscription. This allows you to check the number of parked messages without having to read the parked stream itself.

Content Type validation for projections

We want to make sure that projections are predictable. To support coming changes, we have added content type validation for projections. This means the following:

  1. If the event is a json event, then it must have valid non-null json data.
  2. If the event is not a json event, then it may have null data.
  3. Null metadata is accepted in any scenario.

Events that don’t meet these requirements will be filtered out without erroring the projection.

This change only takes effect either when a projection is created on v21.2.0, or if a projection is stopped and started again. Projections that were created before the upgrade will not enforce content validation.

Read index cache capacity

We've introduced a new option to allow customizing the Read Index cache capacity. Event Store caches the metadata for streams that have been read recently to improve read and write performance.

While the default capacity of 100,000 should be enough for most situations, there are cases where it can be beneficial to increase the cache capacity. For example, if you’re going to be performing a lot of reads and writes to the same 200,000 streams for a period of time.

We’ve added the StreamInfoCacheCapacity option to allow tuning this cache. Please be aware that increasing this number will cause EventStoreDB to use more memory.