我们几周来一直在研究HornetQ。
在我们的业务中,我们有许多“delta”消息,并且(不幸的是......)它们没有版本化(因为这是一个国际标准,它们不会版本化)。这意味着显然是两次发出相同的消息。尽管如此,标准承认它无法真正避免,并指示发件人在这种情况下将消息标记为可能重复。
我浏览了HornetQ的文档,它谈到了很多关于避免服务器重复收到的问题,但我找不到任何关于避免生成重复项的内容。
为了更清楚,假设以下情况:
在名义场景中,消费者在队列中接收消息,将消息发送给第三方,并在收到确认后,将消息发送给服务器,以便将其从队列中删除。
现在,这里的弱点是 ack 部分。第三方可能收到并处理了该消息,但(由于某种原因)ack失败并且消息不出列。
我意识到HQ不可能知道消息已经完全传递,但我希望它知道传递已经已经尝试并且消息的可能性很明显就第三方而言,将会是一个重复的 。
是否有任何方法可以让消费者了解此可能已经提供的状态,以便它可以正确标记消息?
答案 0 :(得分:2)
这样做的一种方法是发送NAC(如果第三方在指定时间段内未确认消息,则向HornetQ发回错误)。如果HornetQ中的队列配置了max-delivery-attempts> 0,然后这将导致重新传递消息。
此时,HornetQ客户端可以为参数“JMSXDeliveryCount”反省消息的标题 - 这将指示消息是第一次发送还是正在重新传送。
此处指示的方法假设HornetQ客户端使用JMS API来消费消息。我确信在核心API中也会有相同的东西。