<img src="https://ad.ipredictive.com/d/track/event?upid=110231&amp;url=[url]&amp;cache_buster=[timestamp]&amp;ps= 1" height="1" width="1" style="display:none">
Post: releases, tech | Aug 10, 2022

Halon 5.9 with message prioritization

We’re excited to announce our quarterly Halon MTA release 5.9, codename “Priy”. This release has an extensive changelog of new features designed to directly benefit senders as well as mailbox providers. Our biggest priority (no pun intended) for this release was prioritization.

The first and most obvious feature that has been added is message priority. The Halon MTA has the capability of segmenting traffic into a virtually unlimited number of sub-queues to avoid different types of messages from blocking each other. However, prior to the latest release, it didn’t provide prioritization within those sub-queues. When sending messages with different classes (say marketing, transactional or notifications such as password resets), some messages may be more time-critical than others. This is where message prioritization comes into play. When queuing a message you can choose between high priority (1) and normal priority (0). Any messages with a higher priority will be delivered first. This allows you to have streams of different message classes in the same MTA, using the existing delivery policies.

Next, we have introduced thread priority. This is a fairly advanced feature, but the ability to change scheduling priority for internal threads may improve the performance if you’re pushing the limits of your instances. While the Linux kernel is generally doing a great job, there are cases where changing the “niceness” of a thread may improve the performance by a few percent. However, there is no silver bullet or general recommendation on how to configure it. Each setup is unique and luckily the default is often good.

Whilst talking about threads, you now have the ability to configure different script thread pools for all the different hooks. Previously, all script hooks shared the same script thread pool. Now, you are able to configure them however you like. This autonomy gives you more control and flexibility over how the system should behave in scenarios where an instance is heavily loaded and needs to prioritize between work.

In relation to performance threads, we have made several improvements to the halontop command line tool. We now display several metrics as meters/bars, providing you with a sense of how busy the system is without having to cross-check the configured max values.

This release has one of the longest list of changes in Halon MTA’s history, with many small and useful improvements in all parts of the system. See our changelog for more details.