Wez Furlong
2bd7410ca6
This commit addresses a tricky interaction with lua's garbage collection and cancellation safety of async lua call handling. In Rust, when a future is cancelled it is simply not called any more, and any resources it owns will be released when it is dropped. In mlua's Rust bindings, async calls are futures that are wrapped up into state whose ownership is managed in the lua context stack, which in turn has managed via its own garbage collection process. In KumoMTA, we implement a pool of Lua contexts which we keep around for reuse. Our logic will return our LuaConfig object back to this pool automatically when it is dropped. In a situation where tokio timeouts or select! are used with a future that transitively contains a lua async call and that call is cancelled, that can leave async locks/semaphores owned in the un-collected objects in the lua stack. For async locks/semaphores that were in the locked state, this can leave them locked until the owning lua context is expired from the pool, either due to age, capacity or use count being hit. That's bad because it can block certain processing flows for 5 minutes (the default `kumo.set_max_lua_context_age`). What this commit does is switch away from automatically returning the LuaConfig to the pool on Drop. In that case the lua context is destroy on Drop, immediately allowing destructors to release any/all owned resources. We do still want to benefit from the pool, so the bulk of this commit is changing the consumers of load_config to explicitly call `config.put()` to put the object back into the pool, but only in the success case. This does penalize flows that grab a config and then `kumo.reject` as their final status. At the present time, the majority of kumomta deployments are very much focused on (relatively) trusted senders and an outbound use case, so this isn't a terrible situation for the time being.
KumoMTA
KumoMTA is an open-source Message Transfer Agent (MTA) designed for high-performance outbound email functionality, similar to commercial enterprise MTAs such as Momentum, PowerMTA, and Halon.
The KumoMTA project was founded by a group of email industry veterans with decades of experience building and managing high-performance On-Prem MTAs and is supported by a community of some of the largest senders in the world.
Because it is designed for high-performance sending environments, KumoMTA is for experienced email operations professionals who are accustomed to high-performance sending environments and familiar with DevOps practices.
Learn more in our FAQ and at https://kumomta.com/.
Documentation
You can learn more about KumoMTA from the Documentation.
Community
Real-time discussion is available on Our Discord.
Developers
If you are interested in contributing/extending KumoMTA, take a look at DEVELOPERS.md. The #devel channel on Our Discord is for contributors to discuss KumoMTA development.
Reporting Bugs
See How to Report Bugs.
Getting Help
See How to Get Help. For paid support see https://kumomta.com/support.
Getting Updates
You can subscribe to updates at https://kumomta.com/subscribe, we send updates periodically and will never sell nor share your information.
Talk to Us
We're available to talk about the project, book us at https://cal.com/team/kumomta/talk-with-kumomta.