Advanced Queue Settings are different for Never, On Failure, Always Queue Setting

[jerchap]

If Queue messages is Never, I get these advanced queue settings:

• Retry Count Before Queue/Error
• Retry Interval (ms)

If Queue messages is On Failure, I get these advanced queue settings:

• Retry Count Before Queue/Error
• Retry Interval (ms)
• Rotate Queue
• Regenerate Template
• Include Filter/Transformer
• Queue Threads
• Thread Assignment Variable
• Queue Bugger Size

If Queue messages is On Failure, I get these advanced queue settings:

• Retry Interval (ms)
• Rotate Queue
• Regenerate Template
• Include Filter/Transformer
• Queue Threads
• Thread Assignment Variable
• Queue Bugger Size

Question 1:
So does this mean a destination has no retry capability if queue message is "Always"? Because that setting is disabled in the UI (Mirth 4.4.1) Why would retry settings be dependent on the queue setting?

Question 2:
Why can the template not be regenerated and filter/transformer not be re-executed if the destination is retried when queue message is never? I don't understand why regeneration and re-execution on retry would be related to the queue setting.

[JoeFox82]

Question 1:
If you have activated the On Failure setting, the message is sent directly by the connector. If the transmission fails, the transmission attempt is repeated as often as the number you have entered in the Retry Count. The message will be queued if the retry count is reached and the message is not successfully send, yet.
With the Always setting, the connector inserts the message directly into the queue without attempting to send it.

Question 2:
If you resend a message manually via the dashobard, all data of the connector is always pulled again, regardless of the queue setting. The settings in the queue only apply to automatic resending in case that the messages end up in the queue.

[jerchap]

Thank you for the response. I guess my question is, what is technically preventing some of those settings from supporting behaviors that other settings have? It appears like a needless limitation.