Demo
Demo

Knowledge base

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

http-webhook-io-timeout

<acct-file>

How long to wait for the receiver's reply during an exchange
in the configuration this is a linehttp-webhook-io-timeout 5sinside the block <acct-file>
Patience in the conversation with the receiver

The line limits any exchange operation after the connection is established: sending the body, waiting for the reply. The default is 5s.

This is the threshold a slow receiver trips on. Connecting is instant, but the reply takes long because the receiving side parses the batch synchronously. Five seconds to parse a megabyte batch is not much.

The right cure is on the receiver’s side. It should reply at once and parse in the background: the engine considers a batch delivered only on a 2xx reply and holds the connection all that time.

The first half of the pair is http-webhook-connect-timeout: it limits connecting, this one — the conversation.

The main trap is raising the threshold instead of speeding up the reply. A slow receiver with a large threshold holds the node’s connections longer, and under load this runs into the number of sending threads. The batch still goes out with a delay.
What the Hub does. It does not write it — the default is enough, and that follows from how the receiver is built: TelemetryController checks the token, puts the body in the cache, queues a job and replies. Parsing the batch happens as a separate job.

The comment on the receiver states it plainly: the engine considers a batch delivered only on a 2xx, and slow analytics would slow down someone else’s mail server.

Recommended values

The threshold is raised only when the receiver belongs to someone else and is slow:

Value When
5s (default) the receiver replies at once, parses in the background
up to 60s the receiver belongs to someone else, parses synchronously, cannot be rewritten

Your own receiver should be fixed, not worked around with a threshold.

The 5s default and the fact that the threshold concerns any exchange operation come from the manual (§ 3.3.11.25). The rule “reply at once, parse in the background” is ours, and it is also written into the Hub’s receiver.
Example configuration
# someone else's receiver parses the batch synchronously and does not make it in time
<acct-file /var/log/pmta/webhook.json>
    http-webhook-url https://partner.example.com/ingest
    http-webhook-io-timeout 30s</acct-file>
For your own receiver such a line is a sign that it is worth rewriting: accept, reply, parse in the background.
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 ends1 mistake▶

Parsing the batch synchronously and raising the threshold

our experience

What it costsThe node’s connections are held for the whole parsing time. Under load this runs into the number of sending threads, and the pile-up starts again, only later.
How to spot itThe threshold has already been raised twice, and each time it helped only briefly.
How to do it rightRewrite the receiver: accept, reply 2xx, parse in the background.
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-io-timeout <time-interval>
Values
a time interval
Default
5s § 3.3.11.25
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
No inheritance: the line lives inside its own <acct-file>. Different accounting streams may go to different receivers with different tolerance.
⇄

Related directives

1 relation

Applies to

http-webhook-url<acct-file>Limits the wait during exchange with that address. § 3.3.11.25

Referenced from

http-webhook-connect-timeout<acct-file>One limits getting through to the receiver, the other — every exchange after that. § 3.3.11.25

How to check on the node
We measure the receiver’s full reply time for a batch similar in size to a real one:
curl -s -o /dev/null -w 'total=%{time_total}\n' -X POST --data-binary @batch.json URL
time_total noticeably below the threshold — there is headroom. Close to the threshold — the receiver parses synchronously, and it is better to fix it.
◇

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-max-intervalhttp-webhook-extra-headershttp-webhook-max-connectionshttp-webhook-ca-fileAll 26 directives of the block →