Eric Allam
6ebd435e81
* WIP execution concurrency controls implemented via Redis - Split up resuming a run and executing a run - Added some new statuses to better show what is going on in a run - Removed preprocessing runs * WIP * Convert to using ZSETs and adding env vars * Removed unused import * Improve run number generation using advistory locks, and only on start * More execution concurrency stuff * Add support for job concurrency limits and concurrency limit groups * Create wild-swans-battle.md * Increase slots refresh timeout to 10s * Try to fix Redis connection issues * Don’t be so strict about the APP_ENV * Add the blank tls option to the normal redis client as well * Add docs
48 lines
1007 B
Plaintext
48 lines
1007 B
Plaintext
---
|
|
title: "defineConcurrencyLimit()"
|
|
description: "Define a concurrency limit group to control the concurrency of your jobs."
|
|
---
|
|
|
|
You can control the concurrency of run executions for a group of jobs using a concurrency limit group.
|
|
|
|
<RequestExample>
|
|
|
|
```ts example
|
|
const concurrencyLimit = client.defineConcurrencyLimit({
|
|
id: `test-shared`,
|
|
limit: 5, // Limit all jobs in this group to 5 concurrent executions
|
|
});
|
|
|
|
client.defineJob({
|
|
id: `test-job-1`,
|
|
name: `Test Job 1`,
|
|
version: "1.0.0",
|
|
trigger: eventTrigger({
|
|
name: "test",
|
|
}),
|
|
concurrencyLimit,
|
|
});
|
|
|
|
client.defineJob({
|
|
id: `test-job-2`,
|
|
name: `Test Job 2`,
|
|
version: "1.0.0",
|
|
trigger: eventTrigger({
|
|
name: "test",
|
|
}),
|
|
concurrencyLimit,
|
|
});
|
|
```
|
|
|
|
</RequestExample>
|
|
|
|
## Parameters
|
|
|
|
<ParamField body="id" type="string" required>
|
|
The ID of the concurrency limit group.
|
|
</ParamField>
|
|
|
|
<ParamField body="limit" type="number" required>
|
|
The maximum number of concurrent executions allowed for this group.
|
|
</ParamField>
|