Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.12

allow-priority-interruption

<domain>

Whether this queue's connections may be interrupted for a higher-priority one
in the configuration this is a lineallow-priority-interruption yesinside the block <domain>
A shield for a queue that must not be touched

The default is yes. The line decides whether connections may be taken from this queue in favor of a queue with a higher priority.

With the value no the queue becomes untouchable. The priority mechanism does not act on it: however high a neighbor stands, its connections stay with it.

This is not a priority but an exception to the priority rule. The number is set by queue-priority, and this line decides whether the interruption rule applies to the queue at all.

The main trap is that the shield can be given to everyone. The line looks like harmless protection of one queue, but the priority rule works only when there is someone to take from. By putting the ban in the general receivers block, you turn priorities off entirely — while the numbers stay in the configuration and look effective.

The second half: an untouchable queue to a slow receiver holds connections for a long time. If it is also the busiest one, the others get nothing — and there is no sign of this except the neighbors’ growing queues.

What the Hub does. It does not write it — the vendor yes stays, that is, any queue may be interrupted.

The Hub does not set priorities either: all queues are equal, and the engine has no reason to take connections from one for another — the rule fires only when priorities differ.

Recommended values

What to set. The ban is set pointwise and for a reason:

Value When
yes (default) an ordinary queue: let the general rule work
no a destination to which dropping a connection is costly — the receiver counts a disconnect as an error or takes long to reconnect

The second is worth checking by the receiver’s log, not by feel: most receivers do not care about a dropped connection.

The yes default and the purpose “do not allow interruption by higher-priority queues” come from the manual, § 3.3.10.12. The analysis of the ban in the general block is ours.
Example configuration
# a receiver for which a dropped connection is costly
<domain slow-receiver.example>
    allow-priority-interruption no</domain>
This queue’s connections will not be taken away at any neighbor priority. Priority numbers simply do not act on it.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Putting the ban in the general receivers block

our experience

What it costsThe priority mechanism is turned off entirely: there is nobody to take connections from. The priority numbers stay in the configuration and look effective.
How to spot itPriorities are set, the order in which queues are served does not change even under load.
How to do it rightPut the ban only on the queues that really need it.

Shielding a busy queue to a slow receiver

§ 3.3.10.12

What it costsAn untouchable queue holds connections for a long time, and the others get nothing. There is no sign of this except the neighbors’ growing queues.
How to spot itOne queue takes almost all connections, the others grow.
How to do it rightLift the ban and limit this queue with connection limits instead of protecting it from interruption.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
allow-priority-interruption <boolean>
Values
yes | no | true | false
Default
yes § 3.3.10.12
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and obeys the merging of receiver blocks: a narrower block overrides a wider one. A ban in the * block goes to all receivers at once — and turns the priority mechanism off entirely, leaving the numbers themselves in the configuration.
⇄

Related directives

1 relation

Depends on

queue-priority<domain>The priority is set by a number, and this line decides whether the interruption rule applies to the queue at all. § 3.3.10.12

How to check on the node
The line is read together with the priorities: neither explains the behavior on its own:
grep -n 'allow-priority-interruption\|queue-priority' /etc/pmta/config /etc/pmta/virtualhost.txt
pmta show queues --connected=yes --maxitems=20
If the ban is in the general block, priorities act for nobody. Check it under load: without a shortage of connections there is nothing to interrupt anyway.
◇

What else to read

3 articles

◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇What makes a virtual machine riskyRunning on a virtual machine is possible, but the manual does not recommend it without sufficient hardware and properly tuned hypervisor settings: under load the node may stop responding.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Untangle a stuck queue
Neighboring settings of the block <domain>:queue-priorityallow-priority-interruption-during-transferdelivery-prioritydisable-acct-recordsdkim-signAll 135 directives of the block →