TIBCO EMS, Visualised: How a Message Actually Moves

Most EMS incidents are not caused by EMS being broken. They are caused by EMS doing exactly what it was configured to do, in a way nobody pictured when they configured it. A queue that stops draining, a producer that hangs, a disk that fills over three weeks — each one is the ordinary behaviour of a feature, meeting a situation nobody drew on a whiteboard.

So this page draws them. Five concepts, each animated from the normal case to the way it fails. Every animation plays once when it scrolls into view; you can pause, step through, or restart it, and every frame is written out underneath.

The numbers in the animations are illustrative — they show the shape of the behaviour, not EMS defaults.

Queues: one message, one consumer

A queue delivers each message to exactly one consumer. With one consumer, that also means in order. The surprise comes when you add a second consumer for throughput.

Animation Queue — each message to exactly one consumer

Six messages wait on queue.orders, in the order they were sent. One consumer, A, is connected.

Step 1 / 6

Delivery order is preserved; completion order across several consumers is not. Exclusive queues trade that parallelism back for order.

Topics: a copy for whoever is listening

A topic delivers a copy of each message to every subscriber — but only the ones connected at the moment it is published.

Animation Topic — a copy for everyone connected

Three subscribers on topic.prices. A and C are connected. B is restarting.

Step 1 / 6

A non-durable subscriber receives only what is published while it is connected.

Durable subscribers: remembered, even when they never return

A durable subscription is how a topic keeps messages for a subscriber that is away. The server has no way to tell away from gone.

Animation Durable subscriber — kept for someone who never returns

D creates a durable subscription on topic.audit, then disconnects. Unlike an ordinary subscriber, the server keeps D’s subscription while it is away.

Step 1 / 5

An abandoned durable subscription raises no error while it grows. show durables lists every durable and what it is holding.

Prefetch: the consumer that takes more than it can handle

Consumers do not collect messages one at a time. The server sends them a batch ahead of time, and a batch held by a slow consumer is a batch nobody else can have.

Animation Prefetch — one consumer takes the batch

Eight messages wait on queue.orders. No consumer has connected yet.

Step 1 / 6

Values are illustrative, not EMS defaults. Check the prefetch property on your own destinations.

Flow control: a producer that stops without an error

When a destination fills to its limit, something has to give. With flow control, it is the producer — and it gives by waiting, not by failing.

Animation Flow control — the producer stops without an error

The producer sends faster than the consumer reads. A backlog starts to form on the queue.

Step 1 / 5

Flow control must be enabled on the server and set on the destination, and real limits are set in bytes. The limit of six messages here is illustrative.

What comes next

Each of these gets its own article, with the commands to see it happening on a real server: how to read the queue that stopped draining, find the durable nobody reads, and tell a blocked producer from a slow one.