Wez Furlong
5e1ae20497
This really is adding batching support to custom lua delivery protocol handlers, but the main use case for these today is to implement log hooks. The way that it works is that you can specify a `batch_size` as part of setting up the lua protocol handler. Then, when it is time to send messages, if the batch_size is the default of 1, the lua delivery logic will invoke the `send` method on the connection object returned from the constructor. This is the same as the behavior from before this commit. However, if the batch_size is greater than 1, then the lua delivery logic will instead attempt to collect up to batch_size messages that are immediately available from the ready queue, and then pass those to a new `send_batch` method. The send_batch method accepts an array of messages; that array will always have at least one message, and up to batch_size messages, depending on the throughput and queue size. If the send_batch method's return value applies equally to all messages in the batch, so if it indicates that something failed, that disposition will apply to all messages. One of the reasons that I'd avoided implementing batching thus far was that it makes it awkward to resolve persistent/recurring issues that are due to a single message in that batch. If the batch is always retried together then there is a good chance that it will always fail together. There's no explicit mitigation for that issue here, but it may be probablistically mitigated by the jitter that is applied to messages that transiently fail. If a batch transiently fails, each message in that batch will be subject to its own random jitter which should cause an offending message to be retried with a different subset of messages next time around. The integration test included here demonstrates the batching working with an http log hook implementation.
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.