Wez Furlong
2b1146aa91
There is a potential race between the timerwheel tick and bulk queue operations (flushing, bouncing). The logic in the tick case has some accommodations for this, but there is another outstanding that can result in racing to manage the metadata load state on a message. In the tick case, we load it if needed, then resolve the queue name, so that we can resolve the Queue handle. We need the queue handle to decide whether we are responsible for the message, or whether we might be racing with a concurrent action. In the race case, the other actor may have decided to release the message metadata, which will cause the queue name resolution to fail. While we could just shrug and silently ignore the error in that case, that makes me uneasy. What this commit does is adjust the v1 wheel entry so that we capture weak references to both the message and its containing queue. Then when we tick, we can simply upgrade both of those and reconcile without needing to manipulate any message metadata. These changes unfortunately result in re-duplication of some of the logic that I recently refactored to be shared with the v2 tick implementation. The v2 tick implementation has the same edge case around metadata, but cannot be easily adjusted to use the same pattern. So this commit sticks a comment in the code; nobody is using v2 AFAIK, and there have been reports of some wonky behavior with it. My recommendation at this time is to avoid using the v2 wheel and we can fix this all up for it later.
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.