如何从主题中删除邮件 [英] How to remove messages from a topic

问题描述

我正在尝试编写一个使用JMS发布订阅模型的应用程序。但是我遇到了挫折，我希望能够让发布者从主题中删除消息。用例是我拥有持久的订阅者，活跃的订阅者将获得消息（因为它或多或少立即），但如果有非活动订阅者并且发布者决定消息错误，我想让他能够删除消息这样订阅者一旦活跃就不会再收到它了。
问题是，我不知道如何做到这一点。
对于提供商我决定使用glassfish的实现，但如果其他替代方案提供此功能，我可以切换。

I am trying to write an Application that uses the JMS publish subscribe model. However I have run into a setback, I want to be able to have the publisher delete messages from the topic. The usecase is that I have durable subscribers, the active ones will get the messages (since it's more or less instantly) , but if there are inactive ones and the publisher decides the message is wrong, I want to have him able to delete the message so that the subscribers won't receive it anymore once they become active. Problem is, I don't know how/if this can be done. For a provider I settled on glassfish's implementation, but if other alternatives offer this functionality, I can switch.

谢谢。

推荐答案

JMS是一种异步消息传递形式，因此发布者和订阅者在设计上是分离的。这意味着没有机制可以满足您的要求。对于在发布时处于活动状态的订阅者，他们将使用该消息而不能及时接收删除消息以对其进行操作。如果订阅者处于脱机状态，那么他们会，但异步消息应该是原子的。如果您继续设计其他响应者的答案（创建删除消息并要求重新连接消费者以读取整个队列以查找删除消息），那么您将创建一种情况，其中系统的行为根据订户是否不同而不同在发布特定消息/删除组合时是否在线。还存在竞争条件，其中订户在发布者发出删除消息之前完成对保留消息的读取。这意味着您必须将重要逻辑放入订阅者以协调这些条件，甚至更多地协调竞争条件。

JMS is a form of asynchronous messaging and as such the publishers and subscribers are decoupled by design. This means that there is no mechanism to do what you are asking. For subscribers who are active at time of publication, they will consume the message with no chance of receiving the delete message in time to act on it. If a subscriber is offline then they will but async messages are supposed to be atomic. If you proceed with design of other respondent's answer (create a delete message and require reconnecting consumers to read the entire queue looking for delete messages), then you will create a situation in which the behavior of the system differs based on whether or not a subscriber was online or not at the time a specific message/delete combination was was published. There is also a race condition in which the subscriber completes reading of the retained messages just before the publisher sends out the delete message. This means you must put significant logic into subscribers to reconcile these conditions and even more to reconcile the race condition.

这种做法的可接受方法就是所谓的补偿交易。在生产者和消费者不共享单个工作单元或共享公共状态（例如使用相同的DB来存储状态）的任何系统中，退出或纠正先前的事务需要第二个事务来反转第一个事务。消费者当然必须能够正确地应用补偿交易。使用此模式时，结果是所有订阅者都表现出相同的行为，无论消息是在消费者重新启动后实时消费还是批量消费。

The accepted method of doing this is what are called "compensating transactions." In any system where the producer and consumer do not share a single unit of work or share common state (such as using the same DB to store state) then backing out or correcting a previous transaction requires a second transaction that reverses the first. The consumer must of course be able to apply the compensating transaction correctly. When this pattern is used the result is that all subscribers exhibit the same behavior regardless of whether the messages are consumed in real time or in a batch after the consumer has restarted.

请注意，补偿交易与删除消息不同。其他响应者的答案中提出的删除消息是一种影响消息流本身的命令和控制形式。另一方面，补偿交易通过系统状态的交易更新影响系统状态。

Note that a compensating transaction differs from a "delete message." The delete message as proposed in the other respondent's answer is a form of command and control that affects the message stream itself. On the other hand, compensating transactions affect the state of the system through transactional updates of the system state.

作为一般规则，您从不想要通过使用命令和控制功能操作消息流来管理系统状态。这很脆弱，容易受到攻击，很难进行审计或调试。相反，设计系统以提供受其服务质量约束的每条消息并处理所有消息。完全在应用程序中处理状态变化（包括撤销先前的操作）。

As a general rule, you never want to manage state of the system by manipulating the message stream with command and control functions. This is fragile, susceptible to attack and very hard to audit or debug. Instead, design the system to deliver every message subject to its quality of service constraints and to process all messages. Handle state changes (including reversing a prior action) entirely in the application.

例如，在交易触发次要影响（如透支费用）的银行业务中，常见的程序是在白天备忘录交易，然后在银行关闭后分批批量应用。这允许在之前协调错误它导致透支费用。最近，这些交易是实时应用的，但触发器被扣留，直到当天的账簿关闭，这样才能达到相同的结果。

As an example, in banking where transactions trigger secondary effects such as overdraft fees, a common procedure is to "memo post" the transactions during the day, then sort and apply them in a batch after the bank has closed. This allows a mistake to be reconciled before it causes overdraft fees. More recently, the transactions are applied in real time but the triggers are withheld until the day's books close and this achieves the same result.

这篇关于如何从主题中删除邮件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！