Documentation

Contention Profile

A Contention Profile is a reusable policy that throttles how the Dispatcher releases Tasks onto a Platform. Profiles are created once and linked to one or more Platforms; the Dispatcher checks every linked profile when deciding whether to claim a queued Task.

Editor overview

The editor has two tabs:

  • General — name, type, scope, and enabled flag. The type is locked after first save and cannot be changed.
  • Settings — type-specific attribute values. This tab is only available once a type has been selected.

Fields

Field Description
Name Display name for the profile.
Type Contention strategy — Concurrency or Rate Limit. Locked after creation.
Scope Per Platform (default) or Global — see below.
Enabled When unchecked the profile is ignored by the Dispatcher even if linked.

Profile types

  • Concurrency Contention — caps the number of Tasks that can run at the same time. Configurable attributes:
    • Max Concurrent Tasks (required).
    • Queue Size Limit (optional) — how many runs can wait.
    • Queue Timeout Seconds (optional) — drop or fail waits older than this.
    • Exceed Action — what to do when full (Queue / Reject / DeferToNextWindow).
  • Rate Limit Contention — caps dispatches per rolling window. Configurable attributes:
    • Algorithm — Token Bucket (allows bursts) or Leaky Bucket (smooths).
    • Limit and Window Seconds (required).
    • Bucket / refill / leak tuning attributes (optional).

Scope

  • Per Platform (default, recommended) — the profile maintains an independent counter per linked Platform.
  • Global — every linked Platform shares one counter. Use only when the linked platforms share a downstream bottleneck (e.g., the same database).

Linking and composition

A Profile takes effect after you link it to one or more Platforms. A Task must satisfy every profile linked to its Platform — limits compose. The Dispatcher picks up profile changes immediately; no restart is needed.

Disabling a profile (setting Enabled to false) is the safest way to temporarily lift a limit without deleting the profile or unlinking it from Platforms.

Best practices

  • Start with Per Platform scope. Switch to Global only if you measure a shared bottleneck.
  • Use Concurrency to protect downstream services with a fixed thread pool; use Rate Limit to satisfy provider quotas.
  • Combine both — a Concurrency profile to cap simultaneous runs and a Rate Limit to smooth bursts is a common, safe baseline.
  • Disable a profile rather than deleting it when load-testing, so the Platform links are preserved.