Wez Furlong
591e9f5380
Under high concurrency, a backlog of store operations can build up, especially if rocksdb isn't tuned for the workload. In order to work together with the data_processing_timeout of the smtp server, we'd like to be able to cancel store operations that are past the deadline, but the spool operations are not guaranteed to be cancel safe because both the rocksdb and the local disk implementations can ultimately call into spawn_blocking to perform the critical portion of the work, and that is not cancel safe. This means that we cannot simply apply timeout_at to the store operation: while it may appear to the caller to have been cancelled at the appropriate time, the actual work storing the spool may be in progress and continue to store the message to the spool, which could lead to us thinking that we are accountable for the message when we next restart, even though we're presumably about to tell the sender that we did not take the message. To deal with this situation more safely, we pass the deadline through to the underlying operation and have it internally decide whether it should continue. In practice, this means that the rocksdb store operation will apply timeout_at to the semaphore operation it does if `limit_concurrent_stores` has been configured fr that spool. Otherwise the deadline is ignored. The implementation of this is imperfect in a number of ways. A more robust solution would be to employ something like <https://docs.rs/cancel-safe-futures/0.1.5/cancel_safe_futures/coop_cancel/index.html>, but that is a more invasive change and one that is a bit difficult to wrangle across the spool trait definition in its current form. If `limit_concurrent_stores` is not in use, this commit doesn't change the behavior of the spool store operation.
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.