Peering jobs

Peer Manager sends data between spaces using peering jobs. This page explains how to read the peering jobs table on a connection's Overview page, the difference between concurrent and sequential jobs, what each job status means, and how to filter the table to focus on the jobs you care about.

How a peering job works

Each peering job corresponds to a specific type of data sent in a single direction. Peer Manager enumerates all jobs for a connection in the connection's Overview page, where each row shows the job's type, status, producer, and the time it ran.

Peer Manager uses two properties to describe a job's type:

• Payload type: Denotes the kind of content the job carries. Data jobs transfer object, link, and file content, while ACK jobs carry the acknowledgments that confirm the remote system received previously sent data, along with metadata that synchronizes each system's view of their shared state, such as object type mapping configurations.
• Direction: Denotes whether the job sends data from your enrollment (Export) or receives data from the remote enrollment (Import).

Export jobs also display a sequencing value beneath the job type that indicates whether the job is concurrent or sequential, as described below. Import jobs display the sequencing of their corresponding export, but in practice all import jobs run concurrently.

Job types

Export jobs run in one of two sequencing modes: concurrent or sequential. Understanding the difference helps you interpret the health of a connection.

Concurrent

Concurrent jobs are real-time, on-demand exports. They fire whenever data is created or updated, and they run in parallel: a producer can run any number of concurrent jobs at the same time. Concurrent jobs are the fast path that keeps a connection up to date during steady-state peering.

Concurrent jobs carry both Data payloads, which are real-time object, link, and file changes, and Acknowledgement, or Ack, payloads, which are the acknowledgments a system sends back immediately after importing data, confirming receipt so the sender stops resending. A concurrent Ack job is the fast path for confirming a transfer, just as a concurrent Data job is the fast path for sending one. You can identify these immediate acknowledgments in the Jobs table by their Ack payload type combined with Concurrent sequencing.

Sequential

Sequential jobs are periodic, catch-up batch jobs that run one at a time for a given relationship: a producer runs only one sequential job at a time per relationship. They exist to backfill anything the real-time path missed, such as a concurrent export that failed or a backlog that built up while the connection was unavailable. Because sequential jobs for a relationship run one after another, a large sequential job blocks the next sequential job for that relationship until it completes.

Job statuses

Each job displays a status that reflects where it is in its lifecycle. The following table describes the statuses displayed in the jobs table.

Import jobs progress through equivalent receiving stages as data arrives from the remote system and is handed off to your enrollment.

Time spent collecting data

Sequential jobs may remain in the Collecting data status longer than other downstream statuses. This may occur because the peer producer carries the backlog of all data the remote system has not yet acknowledged. When a sequential job runs, it gathers everything that accumulated since the last successful transfer, such as the initial data sent during the first synchronization, or everything that built up while real-time peering was failing or the connection was unavailable.

A common cause of a long collecting phase is a data backlog. For example, when you enable peering for new object types across a connection, Peer Manager sends their history through sequential jobs, which require a longer duration to complete.

Empty jobs

Empty jobs transfer zero data and no acknowledgments, and they occur when a scheduled sequential job runs and finds nothing to transfer.

Empty jobs are harmless and expected. Their presence is a healthy sign, because it means concurrent, real-time peering is keeping up and is not encountering failures that require retries. You do not need to take any action on empty jobs, and Peer Manager hides them by default from the Jobs table.

Filter the jobs table

Use the available Filters to limit the jobs displayed in the Jobs table:

• Search by: Find a specific job by its job ID.
• Direction: Show only Export or Import jobs.
• Payload type: Show only Data or Ack jobs.
• Sequencing: Show only Concurrent or Sequential jobs.
• Producer: Show only jobs from a specific producer.
• Status: Show only jobs with the selected statuses. Empty jobs are hidden by default; use this filter to show them or to focus only on jobs that transferred data.
• Time: Show only jobs that ran during a selected time range. A job matches if it ran at some point during the range.

Select Reset all filters to clear every filter and return to the full list of jobs.

Interpret connection health

Peer Manager computes the health shown for a connection from its most recent non-empty jobs, so empty jobs do not affect the health indicator.

Follow the heuristics below to assess your connection's health:

• Concurrent jobs are the steady-state path. When real-time peering is keeping up, most transfers happen through concurrent as opposed to sequential jobs. This indicates there is not a significant backlog for multiple long-running sequential jobs to transfer.
• Sequential jobs reveal backlog. Small, short, or empty sequential jobs indicate a healthy connection. Sequential jobs that consistently collect large amounts of data indicate that real-time peering is falling behind, or that more data is being generated than the current configuration can keep up with.
• Failed jobs need attention. Investigate any Failed jobs using the error message and the error instance ID that Peer Manager provides.