---
id: queues--queue-plugin
title: "Reqular queue"
summary: "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."
audience: user
keywords: "input, clear, output, already exists, queuetype, name, maxitemsinqueue, filterproperty, filterlifetimeinmsec, persistable, itemlifetimeinsec"
---
# 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 `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)