Dead Letter Queue
When a JMS message reaches the maximum retry defined, it is sent to a dead queue configured with the respective route. In case of time dependencies if the time dependency is not run within the predefined retry count it is saved into the database and is not picked by Orchestrator. This can be still triggered from JConsole using the JMX interface.
Following are the cases when the dead letter queue is used:
- JMS Event fails after max retries: JMS messages are routed to Dead letter Queue in JMS. This can be viewed using JMS Clients. The user can replay it by moving the dead letter queue messages back to source queue events or by using the JMX operations provided to move them to the source queue.
- Timer Events for Time dependent plan items fail after max retries: Time Events that fail after the max number of retries is moved to the dead letter table in the database.
- Batching Errors: If the batching is configured, database Notifications are batched and run and committed in the batch. If the transaction fails, each notification from the batch is run separately and committed in the database. If it still fails, the order id that is related to the notification is marked as batch error and the notification is moved to the dead letter table in the database. Any other notifications for the same order are moved to the dead letter table. User can run them manually using the JMX console.
- Database table structure for dead letter queue:
DEAD_LETTER table Column Description SID ID DEADLETTERID Dead Letter ID (Any reference based on the dead letter type) For Time dependency and Batch, its order id. DEADLETTERTYPE Allowed Values are TIME_DEPENDENCY and BATCH. VALUE Data blob. LASTSTATUSCHANGE Timestamp when record was last updated. - Any JMS events on those orders before manually running these requests are moved to the JMS dead letter queue.
- Any Timer events on those orders before manually running these requests are moved to the DB dead letter queue.
- Following JMX operations are exposed to the user for viewing and running the dead letter queue.
Operation Arguments Expected Results getDLQDB A string value indicates the dead letter type. Allowed value is Tenantid
. It can be an empty string.Displays the list of all dead letters according to the input parameter. If the input is an empty string, it lists out all the dead letters including batch errors and time events. getDLQJMS A string value indicates the dead queue name or it can be an empty string. Allowed values: queueName
andtenantid
.Displays list of messages pending on respective dead queue provided as input. If the input is an empty string, it lists out all the pending messages on all Orchestrator related dead queues. runDLQBatchErrors A string value indicates orderID or it can be an empty string. Allowed values: orderid
andtenantid
.Runs further processing of respective orderID. If the input is an empty string, it processes all orderIDs available in the dead letter. runOrchJMSDLQ A string value indicates the dead queue name or it can be an empty string. Allowed values: queuename
,nodeid
andtenantid
.Processes all messages pending on respective dead queue. If input is an empty string, it processes messages pending on all dead queues. getOrchStatus The node ID that you want the status for. Returns the status for a given node ID indicating if the node is in INIT or STARTED state. moveJMSMessages sourceQueue - The queue from which messages have to be moved.
targetQueue - The target queue where they are copied.
sourceOriginator - Filters messages from sourceQueue based on originator value.
targetOriginator - Indicates the new value of the originator header for the messages that are moved.
tenantId - Indicates the tenant whose messages have to be moved.
Moves messages from a source to a target queue and also changes the value of the originator
header if indicated by the caller.
The following dead queues are supported by JMX operations to move back the messages to its source destination:
Dead Queue Name | Description |
---|---|
tibco.aff.orchestrator.order.submit.dead | Submit Order Request dead queue |
tibco.aff.orchestrator.planItem.execute.reply.dead | PlanItem execution response dead queue |
tibco.aff.orchestrator.planItem.milestone.notify.request.dead | MilestoneNotifyRequest from process components to Orchestrator dead queue |
tibco.aff.orchestrator.order.withdraw.dead | Withdraw Order dead queue |
tibco.aff.orchestrator.order.activate.dead | Activate order request dead queue |
tibco.aff.orchestrator.planItem.suspend.reply.dead | PlanItem suspend response dead queue |
tibco.aff.orchestrator.order.suspend.dead | Suspend order request dead queue |
tibco.aff.orchestrator.cache.cleanup.dead | Cache cleanup dead queue |
tibco.aff.orchestrator.provider.order.feasibility.reply.dead | External Feasibility reply dead queue |
tibco.aff.orchestrator.provider.order.prequal.failed.reply.dead | External PreQualificationFailed reply dead queue |
tibco.aff.orchestrator.provider.planItem.failed.reply.dead | PlanItem error handler response dead queue |
tibco.aff.orchestrator.planItem.externalDependency | PlanItem External Dependency Release |
release.request.dead | Request dead queue |
tibco.aff.orchestrator.cache.addEvent.dead | Time dependency add event dead queue |
com.tibco.fom.oms.afi.orch.opdresponse.sender.dead.queue | OPDResponse to Orchestrator dead queue |
com.tibco.af.oms.orderService.amendment.task.ack.dead.queue | Order amendment acknowledgment task dead queue |