Change priority on retried queue items

Use case:

  • A dispatcher/performer model using REF.
  • During a daily run 200-300 transactions are entered into the queue.
  • Processing these items first-in, first-out is required
  • A failed transaction (SE) gets one retry, managed from the orchestrator.

The problem:
After a queue items has failed, the retry mechanism enters it as a new, cloned queue item. This in itself is the desired way of working, but, the item ends in the end of the queue, disrupting the FIFO sequence.

What I’m looking for is a way to alter this processing sequence, without customizing too much from the regular out of the box retry mechanisms. Having the retry managed via the orchestrator is a requirement, so internal retries are out of scope in this case.

Any thoughts?

And while writing I thought of a simple solution. Sharing it here for those that a similar desire to solve this question.

I alter the REF slightly.
change 1: I store the transactionitem.reference in a variable I retain top level
change 2: the get transactionitem sequence:
→ get transactionitem using the previous reference.
→ if nothing, get transactionitem the classic way.

This way the orchestrator-retried item is always served first. If there is no retry the first get TI returns nothing and the second one is used.

And my problem is solved… :smile:

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.