Breadcrumbs

Long-Running Synchronous Calls to a Partition

Summary: Why a synchronous pfx-api:execute call can hang or fail when the executed logic runs long, how the behavior differs by IM version, and what to do about it.

The Problem

A synchronous call from Integration Manager to a partition (typically pfx-api:execute?formulaName=...) is a single blocking HTTP POST. While the partition executes the logic, no bytes flow on the connection — from the network's point of view, the connection is idle. On AWS-hosted clusters, the network infrastructure (AWS NAT gateway) silently drops idle connections after approximately 350 seconds, without notifying the client. The partition finishes the logic successfully and sends the response into a dead connection — the response is lost. What happens next on the IM side depends on the IM version.

Behavior by IM Version

IM version

pricefx-client

Read timeout

Socket timeout + TCP keepalive

Result when the connection is dropped

4.10.2 and older

2.17.1 and older

None (infinite)

None

The IM thread hangs forever. The interface stays locked in Processing indefinitely (days), with no error in the log. Only an IM pod restart releases the thread.

4.10.3 – 5.1.x

2.17.2 / 3.0.x (PFIMCORE-1819)

1 hour (default)

None

The hang is capped at 1 hour — the exchange then fails with a timeout error and the interface unlocks. However, every synchronous call whose logic runs longer than the ~350 s idle window still fails; the failure is just visible instead of silent.

5.2.0 and newer

3.2.0 and newer (PFIMCORE-1935)

1 hour (default)

Both (keepalive enabled by default)

TCP keepalive keeps the connection alive through the NAT by resetting its idle counter, so a long-running synchronous call receives its response normally (up to the read timeout). The failure mode is effectively eliminated.

7.x (current)

bundled in IM

1 hour, configurable

Both, configurable

Same as 5.2.0+, fully configurable via properties: integration.pfx.read-timeout, integration.pfx.socket-timeout, integration.pfx.socket-keep-alive (default true), and integration.pfx.connect-timeout (default 6 s).

Typical Symptoms

  • The logic completes successfully on the partition, yet the IM route never returns and the interface stays locked in Processing.

  • No exception and no timeout message appears in the IM log (on versions ≤ 4.10.2).

  • The issue is intermittent — it only triggers when the logic runtime exceeds the network idle-drop threshold, which is data-volume dependent.

  • A thread dump during the hang shows a Camel consumer thread parked in a socket read (for example SessionInputBufferImpl.fillBuffer).

What You Can Do

On IM Versions Older Than 5.2.0

  1. Upgrade IM — at minimum to 5.2.0 (which contains the PFIMCORE-1935 socket-timeout and keepalive fix), ideally to the current 7.x line. On versions ≤ 4.10.2 nothing can be configured; upgrading is the only remediation.

  2. Until the upgrade, the only workaround when an interface gets stuck is an IM pod restart to release the blocked thread.

On All Versions — Redesign the Integration Pattern (Recommended Even After Upgrading)

  1. Do not run long-running logic synchronously. Rewrite the post action so the logic runs as a background job on the partition — for example, convert it to a CFS or scheduled job triggered via pfx-api:calculate, or have the logic itself dispatch the heavy work as a job. The HTTP call then returns immediately, no connection stays idle, so the NAT drop cannot occur — and the interface lock time no longer depends on the logic runtime.

  2. If further IM steps must run after the logic finishes, add a continuation as a separate event-triggered route reacting to the completion event (for example CALCULATION_COMPLETED_CFS, or a custom event emitted by the logic). If nothing needs to react to completion, fire-and-forget is sufficient.

  3. Note that pfx-api:execute has no async option in any IM version (async exists only for delete and loaddataFile; extending it is tracked as PFIMCORE-813), so the background-job rewrite is the recommended approach.

On IM 5.2.0+ / 7.x — Configuration Tuning

  1. If a legitimate synchronous call runs longer than 1 hour, increase integration.pfx.read-timeout and integration.pfx.socket-timeout (milliseconds).

  2. Do not disable integration.pfx.socket-keep-alive — it is exactly the protection against the NAT idle drop.

  3. Avoid integration.pfx.read-timeout=0, which means an infinite wait.

Key Takeaway

Upgrading IM removes the infinite hang, but it does not by itself make this integration pattern reliable — a long synchronous call still blocks an IM thread for its entire duration and keeps the interface locked. The real fix is running long logic as a background job on the partition.