Attendees
- Tom Doron
- Peter Adams
- Johannes Weiss
- Cory Benfield
- Kaitlin Mahar
- Logan
- Tanner
- Simon Pilkington
Discussion
Service Lifecycle
Tom has written a proposal for Swift Service Lifecycle to be added to the SSWG project list. See https://github.com/swift-server/sswg/blob/tomerd-patch-7/proposals/00XX-swift-service-lifecycle.md
Action: Peter to take the role of review manager.
Deployment Guides
The previously discussed deployment guides are not making progress at the rate which was hoped for.
Action: Tanner & Logon to resume work on Heroku and Digital Ocean guides.
Connection Pooling
Cory Benfield a member of the Apple Swift on Server team based in London had been invited to talk about connection pooling. He has recently been working on connection pooling for REDIS stack - Files · master · Nathan Harris / RediStack · GitLab
This is a complex subject with many trade offs but it is viewed that there are now enough examples in existence that identifying common patterns should be possible. There is also community appetite for this as many current authors don’t what the overhead of maintaining their own implementation.
Two camps are identified
- Those that can use a simple generic implementation eg Database drivers - this is the target for any work in this area.
- Those that are very protocol aware at multiple layers and/or have non-homogeneous connection types. Eg HTTP/x - these will always need a specialist implementation.
The REDIS design uses a lease and return model. Lease uses futures to allow potentially slow creation. The pool maintains a view on connection liveness. It supports a minimum number of connections and actions on over commit. Connection back off is exponential and establishment is done on a round robin basis. The list of allowed destinations is mutable to allow servers to be taken out of use - connections on removed servers will not be reissued when returned to the pool.
It was suggested that to generalise most features should be implemented as “Strategies” to allow users to override.
The threading model was discussed - should all connections live on one tread/event loop? Supporting cross event loop communication is viewed as hard but banning it is probably too restrictive. There was a suggestion that a basic connection pool could be implemented but then wrapped in a thread aware implementation. Alternatively some general helpers for crossing between channels could be provided. It was viewed as undesirable to push complexity towards either the user or library consumers. A pool per loop and a pool manager model was also discussed. The view was that starting simple by ignoring issues like threading would be a good idea - this will push the design towards being compositional too.
It was suggested that connections leased from the pool should be wrapped in a facade which will prevent any use after they have been returned - this behaviour leads to extremely complex bugs so should be prevented. This should also prevent other unacceptable operations - eg the user changing the channel pipeline for the connection, or closing it themselves.
There was discussion of how to handle servers which have maximum permitted load - this pushes the model towards sharing a pool between event loops in situations where you have a large number of loops.
Identified connection pool implementations are - REDIS, 2 in Vapor, mongo db (currently in C but requirements documented specifications/connection-monitoring-and-pooling.rst at master · mongodb/specifications · GitHub)
Back-off, max create rate, server pool health knowledge were highlighted as useful features.
The equivalent of deadlock - by asking for connections from the pool up to the limit in a single stack - was raised. This is viewed as user error but highlights the need for deadlines after which the connection lease request will fail. Failure reason (eg can’t make a connection vs pool at capacity) should be surfaced.
Logging and metrics were highlighted as important. Distributed tracing should also be supported on a per-request basis.
Connection affinity was suggested as being for the user to implement by not returning a connection to the pool while they still need it.
It's unclear if long lived connections should be considered as leased out of pool limits or separately accounted.
Action: Tanner to start a forum topic on this to gather more requirements, identify more prior art, and find community members willing to contribute to this effort. Tanner to post explanation on his pools.
Action: Cory to explain his pool in Tanner’s forum topic.
Action: Todd to find out more about RDS connection service.
Action: Kaitlin to work out if she can contribute resource to this effort.
Foundation Networking
The possibility of building foundation networking on NIO has been raised in the forums as a possible future target. This would have to include a private copy of NIO to avoid locking down the NIO API for everyone.
It was suggested that if this were to happen a prerequisite would be for Async-Http-Client to support everything URISession does. Web socket support and cookie support were also highlighted as lacking.
Action: Tom to see if the community has the appetite to do this work.