You may find interesting
Timeout connection requests when in a deadlock. - 2020-06-30 07:56:08
This patch was authored and released by @MrLotU.
Fixes a bug when requesting
n+1 connections from a connection pool with limit
n where each new connection waited on the previous one.
Previously, this would create a deadlock. Now, a timeout can be added to
EventLoopConnectionPool, that will return a failed future if the timeout is reached. Timeout defaults to 10 seconds but can be configured.
Fix bug related to swift change in error string conversion - 2020-06-04 21:38:41
This patch was authored and released by @MrLotU.
Due to a change in Swift, all
CustomStringConvertibleby virtue of implicit bridging with
NSError. The check for
CustomStringConvertibleconformance has been removed. This restores the previous behavior and makes the tests pass again.
New and better-behaved shutdown methods for `EventLoopGroupConnectionPool` - 2020-05-18 16:57:53
This patch was authored and released by @gwynne.
- Soft-deprecate (documentation only, no warnings from the compiler)
EventLoopGroupConnectionPool.shutdown()for being unnecessarily synchronous (among other things).
EventLoopGroupConnectionPool.shutdownGracefully(_:), modeled loosely after
EventLoopGroup.shutdownGracefully(queue:_:). Shutdown takes place asynchronously, and a callback is invoked on a "safe" Dispatch queue to notify of completion and any errors.
EventLoopGroupConnectionPool.syncShutdownGracefully(), modeled rather closely after
EventLoopGroup.syncShutdownGracefully(). Shutdown is synchronous from the point of view of calling code. As with any such method, it must not be invoked on any of the
EventLoops in the pool's
EventLoopGroup, otherwise deadlock will result. Any error that occurs is thrown.
- Clean up how
NIO.Lockis used; now both safer and spends less time with the lock held.
EventLoopGroupConnectionPool.withConnection(logger:on:_:)now check for an "pool was already shut down" condition and fail early.
EventLoopGroup.future(result:), a convenience method for using the corresponding version of
EventLoopPromise.completeWith(_:). Useful when working with both futures and
- All AsyncKIt unit tests now bootstrap logging and respect the
EventLoopFutureQueueunit tests now run 4 seconds faster.
- A round of CI improvements, including improvements to the code coverage reporting.
Care has been taken not to break any existing API, despite this resulting in the confusing but for-now unavoidable presence of three distinct methods for shutting down pools. Especial care in particular has been taken to ensure that code using the legacy
.shutdown() method will correctly and safely interoperate with code using the new
.syncShutdownGracefully() methods in all cases.
Conform EventLoopFutureQueue.ContinueError to CustomStringConvertible - 2020-04-07 13:00:50
This patch was authored and released by @calebkleveter.
EventLoopFutureQueue.ContinueError.previousError case will now be flattened when printed.
AsyncKit 1.0.0 - 2020-03-25 20:49:58
More information on Vapor 4 official release: https://forums.swift.org/t/vapor-4-official-release-begins/34802
Release Candidate 1 - 2020-02-28 17:06:03
Updates to Swift 5.2 and macOS 10.15 requirements.
Release candidates represent the final shift toward focusing on bug fixes and documentation. Breaking changes will only be accepted for critical issues. We expect a final release of this package shortly after Swift 5.2's release date.
Return correct future when appending empty sequence - 2020-02-24 22:48:11
Title says it all.
Finish fixing sequence append for ELFQueue - 2020-02-24 22:21:23
Previous PR (#54) did not fully fix the problem with appending sequences to
EventLoopFutureQueue. This PR covers the missing bits.
Fix sequence-append in EventLoopFutureQueue - 2020-02-24 20:50:57
The default behavior of appending to ELFQ is to run the next item on completion of the previous, but the APIs for appending sequences incorrectly assumed the next item is only run on successful completion of the previous.
Don't assert when a future in a queued sequence fails - 2020-02-11 21:13:37
Currently, if one of the futures appended by
EventLoopFutureQueue.append(each:generator:) fails, we fire an incorrect assertion instead of failing the chain correctly. This PR fixes the issue and adds unit tests.
AsyncKit 1.0.0-beta.2.2 - 2020-01-31 14:20:55
- Adds a
EventLoopthat takes in a throwing closure and produces a future with the closure's result.
- Adds a
.append(each:_:)method to the
EventLoopFutureQueuetype, which maps each element of the sequence passed in into a future result and then queues the future.
EventLoopFutureQueueis thread safe now.
AsyncKit 1.0.0-beta.2.1 - 2020-01-27 14:09:30
- Adds an
This type can be used to queue closures that emit
EventLoopFutures. This allows you to ensure that a given future will not be run until the previous ones complete, succeed, or fail, depending on the condition you set.
AsyncKit 1.0.0 Beta 2 - 2019-12-09 13:57:55
ConnectionPoolinto two components:
This change greatly reduces code complexity by breaking out the old
ConnectionPool's behavior into distinct components. It also increases usability, allowing developers to choose which functionality they want to use.
EventLoopGroupConnectionPool: Maintains one
EventLoop on the supplied
EventLoopGroup. Use this if you are in a global, thread-safe context. This is great for application's that use
wait(), classes that do EL-synchronization internally, or shared pools that want each event loop to have its own collection of pools. This class is thread-safe.
EventLoopConnectionPool: A pool of connections that is tied to a single event loop.
If you have an
EventLoopGroupConnectionPool, you can get an individual
EventLoop's pool by doing
groupPool.pool(for: eventLoop). This class is not thread-safe and must always be used from the associated
Loggers are now passable anywhere logging occurs.
Enabled test discovery on Linux (#46)
AsyncKit 1.0.0 Beta 1 - 2019-10-24 18:49:05
ConnectionPoolcan now be shared across an
ConnectionPoolis now based on an
EventLoopGroupand has a
ConnectionPoolEventLoopPreferenceenum for informing the pool which
EventLoopyou would like to be called back on.
ConnectionPoolcan still be used on a single
EventLoop, this change just expands its applicability to more use cases.
ConnectionPoolcan now prune old, closed connections when resource demand is low. (#41)
AsyncKit 1.0.0 Alpha 1 - 2019-06-06 16:30:14
More information on Vapor 4 alpha releases:
v0.1.0 - 2018-11-10 17:42:38
Adds standard operators to future types, so if you have for example, two
EventLoopFuture<Int>, you can add them together:
let future1 = eventLoop.future(1) let future2 = eventLoop.future(2) let future3 = future1 + future2
Here's a list of all the operators:
+ += - -= * *= % %= & &= / /= > >= < <= << <<= >> >>= ^ ^= | |= ~