Currently closing a pool, that has leased connections or currently creates connections fails. Such a close attempt brings the pool in an unrecoverable closing state and may lead to crashes. This patch changes the pool shutdown behavior to allow closing the pool even if the pool is not a predefined state.
`RedisConnection.Configuration.defaultPort` is currently unprotected shared mutable state. To ensure thread safety this patch adds an atomic to back this property. Since setting the `defaultPort` doesn't make much sense for adopters, we deprecate the setter. Lastly we mark `RedisConnection.Configuration` as `Sendable`.
Let's move files that are connected to ConnectionPool into the ConnectionPool folder. Also rename `ConnectionPoolErrors.swift` to `RedisConnectionPoolError.swift` to match the type that is defined within.
We want to be able to efficiently encode Redis commands that are sent to a server. This patch adds a new `RedisCommandEncoder` that allows us to efficiently create Redis commands without needing to go through RESP representations, that may require us to create Arrays. Further it introduces a `RESP3BlobStringEncodable` that must be implement to send blob strings using `RedisCommandEncoder`. This patch also adds implementations for `String` and `ByteBuffer` for the new `RESP3BlobStringEncodable` protocol.
In some circumstances users may have connection pools configured without
any SocketAddresses ready to go. This is particularly likely in service
discovery configurations. Right now, the effect of attempting to use
such a pool is two fold. First, we'll emit a bunch of error level logs
telling users we have no addresses. Second, we'll fall into the
exponential backoff phase of connection establishment.
The first property is annoying, but the second one is actively harmful.
If your construction is timed incorrectly, we'll have the awkward
problem of burning a bunch of CPU trying to create connections we know
we cannot, and then a lengthy delay after the addresses are actually
configured before we start trying to use them. That's the worst of all
worlds.
This patch adds logic to detect the attempt to create connections when
we don't have any configured addresses and delays them. This path should
improve performance and ergonomics when in this mode.
Authored-by: Cory Benfield <lukasa@apple.com>
Motivation:
`RedisKeyLifetime` already has "RedisKey" as a prefix so it naturally fits as a nested type.
Modifications:
- Change: `RedisKeyLifetime` to be nested in `RedisKey` and named `Lifetime`
- Rename: `RedisKeyLifetime.Lifetime` to `Duration`
- Deprecate: `RedisKeyLifetime` and the nested type `Lifetime`
Result:
The global namespace is a little less cluttered with the types falling naturally where they already are.
Motivation:
When `RedisConnection.allowSubscriptions` is set to `false`, the connection could still be in a subscription state
leaving further commands to fail slowly from a full roundtrip to Redis, rather than succeeding as expected.
This changes the implementation so that it triggers a full unsubscribe from patterns and channels when set to `false`.
Modifications:
- Change: `RedisConnection.allowSubscriptions` to call `unsubscribe()` and `punsubscribe()` when set to `false`
- Change: `RedisPubSubHandler` to prefix storage of all dictionary keys to avoid name clashes between pattern and channel subscriptions
Result:
Developers should now have more deterministic and unsurprising behavior with PubSub
in regards to subscription management and connection state.
Motivation:
The methods of unsubscribing from all channels / patterns were not working as expected as they need to be special-case handled.
Modifications:
- Change: `RedisPubSubHandler` to be special-case unsubscribe when no arguments are provided
Result:
Developers should now properly be able to unsubscribe from all channels / patterns with a single method call.
Motivation:
Some Redis commands are very connection specific that have impacts on future access that makes it difficult in the current
checkout-use-return cycle that `RedisConnectionPool` uses.
Developers need a way to borrow a specific connection, chain several commands together, and then return the connection to the pool.
Modifications:
- Add: `leaseConnection` method to `RedisConnectionPool` which provides a connection from the pool and returns it after a provided closure's ELF resolves
- Add: `allowSubscriptions` property to `RedisConnection` for controlling the ability to make PubSub subscriptions
- Add: `RedisClientError.pubsubNotAllowed` case for when `RedisConnection.allowSubscriptions` is set to `false` and a subscription was still attempted
Result:
Developers should now have an "escape hatch" with `RedisConnectionPool` to do limited exclusive chains of operations on a specific connection.
Motivation:
When trying to allow users to configure the connection retry timeout offset,
not having a value provided (deadline of `now`) caused all attempts to use the pool to fail.
Modifications:
- Change: RedisConnectionPool to always have a timeout offset defined
Result:
If users don't specify any value, then the default of 60 seconds will be used.
If users specify "nil" (or `.none`) as the timeout, then a minimum of 10 milliseconds will be used to avoid immediate timeouts
Otherwise, use the user's specified `TimeAmount` as the offset of the timeout
Motivation:
With RedisConnectionPool a timeout is provided to prevent infinite loops of
retrying connections, but right now it is hardcoded to 60 seconds.
Users of downstream projects such as Vapor are noticing a "regression" of sorts, as previously
EventLoopFutures would fail immediately if a connection was not made available.
Modifications:
- Add: `connectionRetryTimeout` parameter to `RedisConnectionPool` initializer that still defaults to 60 seconds
- Change: RedisConnectionPool to use the new parameter if available to offset a deadline from "now"
Result:
Users can now configure the connection pool to fail immediately if connections are not available.
Motivation:
To ship PubSub faster, it was merged to the master branch without a peer review. This commit is to address the critical points of feedback given in a post-commit review.
Modifications:
- Add: New RedisClientError case where a "race condition" of removing a pubsub handler and subscription can happen
- Add: New state to RedisPubSubHandler for when it has been removed from a ChannelPipeline
- Change: RedisPubSubHandler to require an `eventLoop` in its initializer
- Change: The subscribe and unsubscribe methods on RedisPubSubHandler to handle the EventLoop hopping to be thread-safe
Result:
PubSub should have a more robust and thread-safe implementation.
Motivation:
One of the great features of Redis is being able to subscribe and receive messages published to specific channels
as a way of acting as a message queue for processing jobs.
PubSub requires a specific understanding of the connection model that can only be implemented directly in this library.
Modifications:
- Add: `RedisPubSubHandler` to sit in front of `RedisCommandHandler` to manage subscription callbacks and Redis registration
- Add: `publish` and the `pubsub` commands
- Add: `addPubSubHandler` extension to `NIO.Channel`
- Add: Type-safe String wrapper of `RedisChannelName` for PubSub methods
- Add: `pubsubSubscriptionNotFound` error case
- Add: `isSubscribed` property to `RedisConnection`
- Add: `availableConnectionCount` and `leasedConnectionCount` properties to `RedisConnectionPool`
- Add: Metrics for PubSub
- Add: `makeNewPool` factory method to `RedisConnectionPoolIntegrationTestCase`
- Change: `RedisClient` to require methods for PubSub management, as they are intrinsicly tied to the client's connection model
- Change: Parsing of `PING` response for handling special case in PubSub mode
- Rename: `ActiveConnectionGauge` to `RedisMetrics.IncrementalGauge`
Result:
Developers will now be able to use Redis in PubSub mode with both connections and pools.
This resolves#6
Franz Busch
Fabian Fett
hamzahrmalik
Joannis Orlandos
Marius Seufzer
Marius Seufzer
Gwynne Raskind
Michael Stegeman
Nathan Harris