Demo
Demo

Knowledge base

PMTA knowledge base›Block <acct-file>›Directive§ 3.3.11.26

http-webhook-max-connections

<acct-file>

How many threads send batches to the receiver at once
in the configuration this is a linehttp-webhook-max-connections 1inside the block <acct-file>
One thread or several

By default one thread handles sending, and batches go out one after another. The line lets you raise their number — the ceiling is 50.

This is rarely needed and only under one condition: batches must appear faster than one thread manages to send them. With a one-minute interval this means sending one batch takes more than a minute — that is, the receiver is slow or the batch is huge.

Record order is not guaranteed with several threads. Batches go out in parallel, and the receiver may get them in a different order than they were assembled in. For accounting this usually does not matter — the records have their own timestamps — but a receiver that relies on order will break.

Compression is worth trying first. http-webhook-transfer-encoding reduces the transferred volume, and that is often enough instead of parallelizing.

The main trap is raising the number of threads against a slow receiver. If it is slow because of load, ten threads will make things ten times worse for it, retries will become more frequent, and everything will get slower. The problem has to be dealt with on the receiver’s side.
What the Hub does. It does not write it — one thread remains. With a one-minute interval and a 1 MB batch ceiling, one is enough: our receiver answers right away, and parsing runs in the background.

The line will come in handy if the fleet’s stream grows so much that minute batches stop fitting into a minute.

Recommended values

Raise it only for a measured reason:

Value When
1 (default) almost always
2–5 batches do not manage to go out within the interval
up to 50 a very large stream and a fast receiver

Before that, compression is worth trying — it is cheaper for both sides.

The 1 default and the ceiling of 50 come from the manual (§ 3.3.11.26). The note about batch order and the advice to try compression first are ours.
Example configuration
# raise it only when batches do not fit into the interval
<acct-file /var/log/pmta/webhook.json>
    http-webhook-url https://hub.example.com/api/telemetry/pmta/7
    http-webhook-max-interval 1m
    http-webhook-max-connections 4</acct-file>
The sign it is time: intermediate files pile up while the receiver is healthy and answers 2xx.
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▶

Raising the number of threads without checking the receiver's responses

our experience

What it costsPiling files more often mean the receiver is refusing than a shortage of threads. Parallelizing in that case only multiplies retries.
How to spot itFiles pile up, and the engine’s log shows sending errors.
How to do it rightFirst look at the responses — http-webhook-log-verbose will show them — and fix the receiver.

Expecting batch order to be preserved

our experience

What it costsWith several threads batches go out in parallel and arrive in arbitrary order. A receiver that relies on order will start losing or mixing up records.
How to spot itThe receiver complains about records “from the future” or gaps.
How to do it rightRely on the timestamps in the records themselves or keep one thread.
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
http-webhook-max-connections <integer>
Values
an integer from 1 to 50
Default
1 § 3.3.11.26
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<acct-file>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside its <acct-file> and applies only to sending its batches. Each accounting stream has its own number of sending threads.
⇄

Related directives

2 relations

Works together with

http-webhook-max-interval<acct-file>Threads are needed when batches come more often than one thread manages to send them. inference

Applies to

http-webhook-url<acct-file>How many threads send batches to that address at once. § 3.3.11.26

How to check on the node
The sign of a shortage is intermediate files piling up while the receiver is healthy:
ls -la /var/log/pmta/*.json | wc -l
A growing number with 2xx responses means sending cannot keep up. If the responses are not 2xx, the problem is not the threads but the receiver.
◇

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.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇Five ways for a queue to hand off a messageA queue does not have to use SMTP: it can write to a file, run a program, call over HTTP or discard.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Collect telemetry
Neighboring settings of the block <acct-file>:http-webhook-urlhttp-webhook-extra-headershttp-webhook-max-intervalhttp-webhook-connect-timeouthttp-webhook-ca-fileAll 26 directives of the block →