Appearance
Reqular queue
FIFO or LIFO queue: input records are stored and the call returns at once; a background worker emits them one by one on Output. Use it to decouple a fast producer from slow processing, to serialize processing, or (persistable) to keep work across flow restarts. Optionally rejects duplicates.
Pins
| Pin | Kind | Types | Description |
|---|---|---|---|
| Input | input | any | Record to queue. |
| Clear | input | any | Any record; removes all queued records. The record content is not used. |
| Output | output | same as input | Queued records, one at a time, each with new metadata. |
| Already exists | continue | same as input | Records rejected as duplicates (same FilterProperty value within FilterLifetimeInMsec), with their original metadata. |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
QueueType | dropdown: 1 FIFO, 2 LIFO | 1 | Order in which records leave the queue. The field is locked in the designer. |
Name | string (max 128) | myqueue | Required. Queue name; Queue writer components in the same flow write into the queue by this name. |
MaxItemsInQueue | integer (≥ 0) | 0 | Capacity, 0 = unlimited. Also bounds the duplicate filter. |
FilterProperty | dropdown (property of the input type) | Optional. Property whose value is the duplicate key. Options appear after the input is connected. | |
FilterLifetimeInMsec | integer (≥ 0) | 0 | How long a key is remembered after its record was queued, in milliseconds. 0 = no time limit. |
Persistable | boolean | false | true keeps queued records and filter keys on disk and restores them when the flow starts again. |
ItemLifetimeInSec | integer (≥ 0) | 0 | Records older than this (since they were queued) are dropped with a warning. 0 = never. |
Behaviour
- At start the queue is created under
Namefor this flow and one worker starts. The item type is the type of theInputconnection (or ofOutputwhen only Queue writers feed the queue); a record of another type fails onInput. Input: the record is added and the call returns (warm-up calls are ignored). When the queue is full the record is dropped with a warning; when it is a duplicate it goes toAlready exists.- Worker: takes the next record (FIFO: oldest, LIFO: newest), skips expired ones, and calls
Output. The next record is taken only after theOutputcall returns. - Delivery is retried. If the
Outputbranch throws, the same record is delivered again after 100 ms, doubling up to 30 s, until it succeeds, it expires (ItemLifetimeInSec), the queue is cleared or the flow stops. Later records wait meanwhile. While the flow is paused nothing is delivered. - Duplicates: a key is remembered when its record is queued and stays for
FilterLifetimeInMsec(or untilClear), also after the record has left the queue. WithMaxItemsInQueue> 0 the filter keeps at most about that many keys; expired keys are swept first, then arbitrary ones. Clear: removes every waiting record and all filter keys, also from disk. A record being delivered at that moment finishes its current attempt but is not retried. Warm-up calls are ignored.- Persistable: a record is written to disk before
Inputreturns and removed after a successfulOutput, so delivery is at-least-once across restarts. On start the records are restored (expired and unreadable ones dropped with a warning); if the item type changed since the last run the old data is discarded. Data lives in the component's own folder ({user path}/data/{flow id}/{component id}/queue). - The queue belongs to its flow; a second queue component with the same
Namein the flow fails at start. When the flow stops a non-persistable queue loses its records.
Notes
- Records leave the queue with new metadata (new correlation id, no session data of the producer).
- Because of the retry, a record that always fails blocks the queue until it expires: set
ItemLifetimeInSec, or catch errors in theOutputbranch (Try catch) and route them elsewhere. - A persistable queue without
MaxItemsInQueuekeeps everything in memory too and warns at start. - Queues are per flow and per process; for flow-to-flow communication use Start flow or Port client / Port listener.
Example
json
{ "QueueType": 1, "Name": "orders", "MaxItemsInQueue": 10000, "FilterProperty": "OrderId", "FilterLifetimeInMsec": 3600000, "Persistable": true, "ItemLifetimeInSec": 86400 }Http listener → Reqular queue → Http client (calls a slow API one order at a time)