TIBCO Enterprise Message Service
Queuetibco-ems
JMS broker with persistent, non-persistent and reliable delivery modes.
| property | type | values | required | kind default | this component |
|---|---|---|---|---|---|
| backoff | enum | none | fixed | exponential | exponential-jitter | no | — | inherited |
| deadLetterQueue | boolean | — | no | false | ▸ false |
| delivery | enum | at-most-once | at-least-once | exactly-once | yes | — | ▸ at-least-once |
| deliveryMode | enum | persistent | non-persistent | reliable-delivery | no | persistent | inherited |
| faultTolerance | boolean | — | no | false | inherited |
| instances | integer | — | no | — | inherited |
| managed | boolean | — | no | false | ▸ false |
| maxAttempts | integer | — | no | — | inherited |
| ordering | enum | none | per-key | global | no | none | ▸ none |
| persistence | boolean | — | no | true | inherited |
| replay | boolean | — | no | false | ▸ false |
| retentionDays | integer | — | no | — | inherited |
| role | enum | work | dlq | retry | offline-mailbox | frontier | no | work | inherited |
| routing | boolean | — | no | false | inherited |
Every rule whose selector covers this component's kind or its category. Whether a rule fires depends on the design: its properties, its edges and its groups.
queue-missing-dlq
A queue that receives asynchronous traffic and has no dead-letter queue either drops poison messages or retries them forever. Neither outcome leaves anything for a human to investigate.
- — all of these hold:
- — the node's `deadLetterQueue` is false
- — the node has at least one asynchronous incoming edge
retry-queue-without-dlq
A retry queue is where poison messages end up. With no dead-letter queue they are retried forever or dropped in silence, and nobody ever looks at the failed payment.
- — all of these hold:
- — the node's `role` is "retry"
- — the node's `deadLetterQueue` is false
Retry queue without backoffwarning
retry-without-backoffRetrying a transient failure at full speed turns one slow dependency into a retry storm. A retry queue backs off, preferably exponentially and with jitter.
- — all of these hold:
- — the node's `role` is "retry"
- — any of these hold:
- — the node's `backoff` has no value
- — the node's `backoff` is "none"
nodes:
- { id: "tibco-ems", component: "tibco-ems" }Simple Message Queue (formerly MNS)alibaba-mnsApsaraMQ for RabbitMQalibaba-rabbitmqApsaraMQ for RocketMQalibaba-rocketmqAmazon MQaws-mqAmazon SQSsqsAzure Queue Storageazure-queue-storageAzure Service Busazure-service-busCloudflare Queuescloudflare-queuesApache ActiveMQactivemqGearmangearmanIBM MQibm-mqMessage queuemessage-queueNSQnsqApache Qpid Broker-JqpidGeneric queuequeueRabbitMQrabbitmqRedis queueredis-queueSolace PubSub+ Event BrokersolaceGoogle Cloud Tasksgoogle-cloud-tasksIBM Cloud Messages for RabbitMQibm-messages-for-rabbitmqIBM MQ on Cloudibm-mq-on-cloudOCI Queueoci-queueOpenStack Zaqaropenstack-zaqar
# yaml-language-server: $schema=../../schema/component.schema.json # TIBCO Enterprise Message Service: JMS broker whose delivery modes are PERSISTENT, NON_PERSISTENT and # the EMS extension RELIABLE_DELIVERY; only PERSISTENT messages are written to the server store # ("Message Delivery Modes", "How EMS Manages Persistent Messages"). schemaVersion: "1" type: "component" id: "tibco-ems" kind: "queue" provider: "default" docs: "https://docs.tibco.com/pub/ems/8.6.0/doc/html/GUID-FD538023-D7B6-464B-9AAD-F3E603AC34EE.html" defaults: delivery: "at-least-once" ordering: "none" deadLetterQueue: false replay: false managed: false properties: deliveryMode: type: "enum" values: ["persistent", "non-persistent", "reliable-delivery"] default: "persistent" faultTolerance: type: "boolean" default: false routing: type: "boolean" default: false