用于管理被拒绝消息的MQ消息传递架

Question

我在管理MQ客户端上的消息拒绝的2x方法之间遇到了一些困难。不可否认，它更像是一种意识形态论证，而不是技术论证。

考虑这一点：客户端读取队列上的消息（XML）。在进一步处理之前，客户端检查数字签名（并且，通过扩展，检查消息是否遵循某个模式）。但是，我们说数字签名的验证失败了。我不希望邮件得到进一步处理。它需要回到源头并手动整理出来。

据我所知，我可以采取2x方法：

选项1

• 客户端读取消息
• 客户确认收到
• 客户端发现消息无效

• 客户将无效邮件写入＆＃39;拒绝＆＃39;队列

                    CLIENT   MQ CLIENT
                     READ    +-------+        +----+ 
     OUT Q | --- | --------> |PROCESS| -----> |NEXT| 
           | --- |           |MESSAGE|        |STEP| 
           +-----+           +-------+        +----+ 
                                 | 
                                 | 
  REJECT Q | --- | <-------------+ 
           | --- |     FAILURE
           +-----+
  

选项2

• 客户端读取消息
• 客户端发现消息无效
• 客户未确认收到消息

• MRRTY = 0（？）因此QM将消息写入拒绝Q

                     CLIENT   MQ CLIENT
                      READ    +-------+        +----+
     OUT Q  | --- | --------> |PROCESS| -----> |NEXT|
            | --- | <-------- |MESSAGE|        |STEP|
            +-----+  FAILURE  +-------+        +----+
               |
               |
               V
  REJECT Q  | --- |
            | --- |
            +-----+
  

我偏向于选项2，其中QM负责将失败的消息写入拒绝队列，因为在我看来它是一个更整洁的解决方案。这也意味着客户的通信只在一个方向。我理解CLIENT_ACKNOWLEDGE用于接收到达确认点之前的所有消息：我是否误以为每个消息的确认将是允许我将QM写入失败的消息发送到被拒绝的每个MRRTY参数Q的机制？

任何意见/讨论都很重视标准模式/架构。

Answer 1

感谢Morag和Attila提供的帮助和意见。

它归结为基本上是这样的：

  

应用程序应该处理应用程序错误，而格式错误的消息是应用程序错误。队列管理器应该只处理传输错误。 （Attila）

这......

  

没有机制让队列管理器将失败的消息路由到副队列。这是应用程序的责任。 （Morag）

因此，在应用程序错误的情况下，客户端本身应该将失败/格式错误的消息写回到带外的单独队列中。