0

我们已经研究 HornetQ 几个星期了。

在我们的业务中，我们有许多“delta”消息，并且（不幸的是......）它们没有版本化（并且由于这是一个国际标准，它们不会被版本化）。这意味着两次发出相同的消息显然是不受欢迎的。尽管如此，该标准承认它确实无法避免，并指示发件人在这种情况下将消息标记为可能重复。

我翻阅了 HornetQ 的文档，它谈到了很多关于避免服务器接收到的重复，但我找不到任何关于避免产生重复的内容。

为了更清楚，假设以下情况：

  • 1个总部服务器
  • 1 消费者

在名义场景中，消费者在队列中获取一条消息，将其发送给第 3 方，并在收到确认后，向服务器确认消息，以便将其从队列中删除。

现在，这里的弱点是ack部分。第 3 方可能收到并处理了消息，但（由于某种原因）ack 失败并且消息没有出队。

我意识到总部不可能知道消息已完全传递，但是我希望它知道已经尝试传递，并且消息很可能是重复的第三方有关。

有没有办法让消费者知道这个可能已经交付的状态，以便它可以适当地标记消息？

4

1 回答 1

2

One way of doing this would be to send a NAC (or throw back an error to HornetQ if the message was not acknowledged by the third party in the specified time period). If the queue in HornetQ has been configured with max-delivery-attempts > 0, then this will result in the message being redelivered.

At that point, the header of the message can be introspected by the HornetQ client for the parameter "JMSXDeliveryCount" - this will indicate whether the message is being sent for the first time or it is being redelivered.

The methodology indicated here assumes that the HornetQ client uses the JMS API for consuming the messages. I'm sure there will also be something equivalent in the core API.

于 2012-04-05T14:28:40.633 回答