## Motivation
RediStack 1.x is going to be supported at least until 2.x is released, which is a few months away.
Developers who are on later versions of Swift will adopt later versions of NIO and other libraries, and after we merged !183 we required NIO 2.42.x which has a minimum Swift version of 5.5
## Changes
This back ports the CI config from `master` into this branch, with updates to the README to reflect the changes
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
Motivation:
The original implementation of Logging was done in more haste than should have been, without proper attention given to the semantic requirements.
As the Swift ecosystem has matured a bit, lessons have been learned on handling metadata and passing of external context into internal subcomponents.
A mixture of the "protocol-based context passing" and "explicit context passing" patterns have been adopted.
Both patterns are more fully described in the Swift forum discussion: https://forums.swift.org/t/the-context-passing-problem/39162
Modifications:
- Add: `RedisLogging` namespace with references to static keys and labels that are used for Logging throughout the library
- Add: `Logger` static computed properties to access the Logger prototypes used in connection and connection pools
- Add: `RedisClientWithUserContext` protocol and `UserContextRedisClient` types to assist with wrapping client types for custom logger contexts
- Remove: `logger` property from `RedisClient` requirements
- Change: Many log statements to have higher or lower log levels for their appropriate context
- Change: `RedisConnection` and `RedisConnectionPool` to conform to `RedisClientWithUserContext`
- Change: `logging(to:)` protocol requirement to return a `RedisClient` existential
- Change: ConnectionPool to explicitly pass a logger instance around for pooling methods
Result:
Logging in RediStack will now have a stronger contract of where and how logs will be generated and which context will be used.
Fixes#79 and #74
Motivation:
Redis is written in C, so even though it has concepts of "types" such as SortedSet or List
its commands are all "free-floating" functions.
This can make it unfamiliar for those new to Redis to work within its systems and understand the relation of all of the commands.
RediStack can improve this by giving a way of having a consistent reference to a Redis type and all of its associated methods.
Modifications:
- Add: New library product called "RedisTypes"
- Add: First type to "RedisTypes", `RedisSet`
Result:
Newcomers to Redis will have an easier time getting familiar with the APIs and working with its types by having wrappers that
provide a familiar Swift Standard Library API tailored to Redis APIs.
Joannis Orlandos
Fabian Fett
Marius Seufzer
Nathan Harris
Marius Seufzer
Gwynne Raskind
Nathan Harris
Michael Stegeman