This is a reasonably significant upgrade, as it allows for
async functions to be Send, which could unlock more efficiencies
in our overall scheduling.
This commit is just the basic changes required to get the updated
mlua version compiling, it doesn't change anything else.
I recently noted that an issue relating to failing redis auth
was not being surfaced in the diagnostic log.
It was being logged at debug level so wasn't visible by default.
This commit does two things to improve this:
* Surface that error at error level, but keeps "regular" over-limit
events at debug level
* Explicitly pings the configured redis server on startup, so that
connectivity can be validated at `--validate` time and not be
an issue that is deferred until after the service is up and running.
Per commentary in b1330171be, move
away from mobc and standardize on deadpool.
This means that a couple of the newly added pool parameters
are no longer present, but nobody has had a chance to embrace
those yet anyway.
Make a note in the changelog about the recent changes: I fixed a bug
that no one had noticed before, which was that the username/password
parameters for single node redis were ignored. This was fixed by
52ca4d8be0
Tests are failing on rocky8 because its redis-cli doesn't
understand the --cluster-yes option.
Let's just skip running the tests there; the client
coverage is sufficient on the other more modern platforms.
Remove the r2d2 dep (which is synchronous only) and replace with
mobc which is a bit easier to use, async, and seems more developed.
Update the interface to expose more of mobc's connection pool
options.
Add explicit redis cluster integration tests.
NOTE: macos is NOT a platform supported for production use!
This commit just enables basic build and test to facilitate
offline work when I'm travelling with a mac laptop.
There are important systems functions that are not implemented
in the macOS build.
To support distributed connection limits, adjust the way that
connection limits are handled.
Previously, we'd do a simple in-memory comparison with the limit to
guide whether we had reached the limit.
In a distributed/clustered scenario we need a shared understanding
of the state of the connections, so we're moving to a lease-based
model.
Each connection is associated with a UUID.
Each egress path maintains a set of connections and their UUIDs.
When attempting to make a new connection, we can only proceed if the
number of connections associated with an egress path is below the limit.
When a connection is closed, its UUID is removed from the associated
set.
To handle crashes, kills and netsplits, the path -> uuid association is
also accompanied by an expiration time beyond which it can be assumed
that the lease is no longer valid. We compute that time based on the
worst case timeout value for a single message send on the given pathway.
Each time a connection is ready to obtain a new message, it will try
to extend its lease by that same duration.
This commit introduces these concepts and models them using an in-memory
store for the single node case, and using redis for the cluster case.
When your policy enables `kumo.configure_redis_throttles`, that same
redis configuration is used to back to the connection limiting
functionality.
refs: https://github.com/KumoCorp/kumomta/issues/41
Wez Furlong
Dirkjan Ochtman