Skip to content

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 ​

PinKindTypesDescription
InputinputanyRecord to queue.
ClearinputanyAny record; removes all queued records. The record content is not used.
Outputoutputsame as inputQueued records, one at a time, each with new metadata.
Already existscontinuesame as inputRecords rejected as duplicates (same FilterProperty value within FilterLifetimeInMsec), with their original metadata.

Configuration ​

FieldTypeDefaultDescription
QueueTypedropdown: 1 FIFO, 2 LIFO1Order in which records leave the queue. The field is locked in the designer.
Namestring (max 128)myqueueRequired. Queue name; Queue writer components in the same flow write into the queue by this name.
MaxItemsInQueueinteger (≥ 0)0Capacity, 0 = unlimited. Also bounds the duplicate filter.
FilterPropertydropdown (property of the input type)Optional. Property whose value is the duplicate key. Options appear after the input is connected.
FilterLifetimeInMsecinteger (≥ 0)0How long a key is remembered after its record was queued, in milliseconds. 0 = no time limit.
Persistablebooleanfalsetrue keeps queued records and filter keys on disk and restores them when the flow starts again.
ItemLifetimeInSecinteger (≥ 0)0Records older than this (since they were queued) are dropped with a warning. 0 = never.

Behaviour ​

  • At start the queue is created under Name for this flow and one worker starts. The item type is the type of the Input connection (or of Output when only Queue writers feed the queue); a record of another type fails on Input.
  • 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 to Already exists.
  • Worker: takes the next record (FIFO: oldest, LIFO: newest), skips expired ones, and calls Output. The next record is taken only after the Output call returns.
  • Delivery is retried. If the Output branch 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 until Clear), also after the record has left the queue. With MaxItemsInQueue > 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 Input returns and removed after a successful Output, 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 Name in 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 the Output branch (Try catch) and route them elsewhere.
  • A persistable queue without MaxItemsInQueue keeps 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)

Viaducta documentation