Activemq如何配置消费者监听器(Java中)
如果有人能分享一个在 Spring 中基于 xml 的消费者侦听器配置的简单示例,我会很高兴。提前致谢。
编辑;
我只是想听听消费者的监听器,而不是消费者的实现,因为我已经在我的应用程序中实现了 active-mq。它运行良好,但是我无法确定生产者同步发送的消费项目的顺序。 问题是由于并发消费者一次异步执行方法(将一些对象保存到数据库以记录它们)而导致的不一致和数据操作。
编辑2: 让我澄清一下这种复杂性。我有一个由两个基本独立部分组成的应用程序。第一个是同步执行的Producer,向db询问新来的产品,然后通过active-mq提供的“jmsTemplate.send”方法“一个一个”发送它们。这是从 Cron/Timer 同步执行的操作。换句话说,生产者是从计时器/cron 执行的。现在的问题是消费者本身。当生产者“一个接一个”发送产品时,异步消费者(启用并发)接收产品并异步消费它们。
问题就从这里开始。因为该方法是消费者刚收到产品时执行的,它会执行一些数据库持久化操作。当相同的产品被不同的并发消费者接收时(这是因为我们的系统而发生的,而不是 jms 问题,不要注意这一点),然后对同一实体执行相同的持久性操作,会发生一些易于预测的异常。如何防止产品的这种异步操作或管理此类应用程序中消费产品的订单。
谢谢。
I would be happy on the condition that anyone share a simple sample for xml based configuration of consumer listener in Spring. Thanks in advance.
EDIT;
I just would like to hear about the listener of consumer, not the consumer implementation because I have already implemented an active-mq in my app. and it is running well, however I cannot be sure the order of consuming items which are send by producer synchronously.
The problem is the inconsistency and data manipulation due to async executions of a method (persisting some objects to db in order to log them) from concurrent consumers at a time.
EDIT2:
Let me clarify this complexity. I have an application that consist of two base separate parts. The first one is the synchronously executing Producer that asks db for the products newly come, and then "one by one" send them thorough the "jmsTemplate.send" method provided by active-mq. This was the operation which is synchronously executed from a Cron/Timer. In other words, producer is being executed from a timer/cron. Now The problem is consumer itself. When producer sends products "one by one", async consumers (with concurrency enabled) receive the products and consume them asynchronously.
The problem begins here. Because the method, which is executed from the consumer when the products are just received, does some db persistence operations. When the same product is being received by separate concurrent consumers (it happens because of our system, not a jms issue, dont pay attention on this point) then doing the same persistence operations on the same entity occurs some exceptions as easy to predict. How can I prevent this async operations of products or manage the orders of comsuming products in that kind of application.
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
侦听消息的 Java 类 itslef:
}
启动此侦听器只需获取应用程序上下文,一旦执行此操作,它将自动启动 JMS 侦听器。
根据其他问题进行编辑:
那么您的系统可能会生成(例如)2条甚至更多条消息,这些消息传递给具有相同productID的消费者?首先,这不是您的问题,而是应用程序的问题。即使你以某种方式修复了它,它也不是真正的修复,而是隐藏问题本身的一种方法。然而,如果被迫提供解决方案,现在我只能想到一个,最简单的,禁用并发消费之类的。这是我要做的:接收队列中的消息,并且该队列上只有一个消费者。在这个 Consumer 中,我会尽可能少地处理消息 - 仅获取 ProductID 并将其放入其他队列中。在此之前,您必须始终检查 ProductID 是否已不在该队列中。如果只是默默返回,如果不是,则意味着它从未被处理过,因此将此消息放置在另一个队列中:例如 Queue2,然后在第二个队列 Queue2 上启用并发消费者。但这仍然有缺陷:首先,productID 队列应该以某种方式偶尔清理一次,否则它将永远增长,但这就是那么困难。棘手的部分:如果您在 ProductID 队列中有一个 ProductID,但该产品是在数据库中进行更新而不是插入,该怎么办?那你就不应该拒绝...
And the Java class that listens to the message itslef:
}
Starting this listener it's a matter of getting the Application Context, it will auto-start the JMS Listener once you do that.
EDIT according to the other question :
So your system may generate (for example) 2 or even more messages delivered to the Consumers with the same productID? Well first this is rather not YOUR problem, but the application's. Even if you somehow you fix it, it is not really a fix, but it is a way to hide the problem itself. Nevertheless, if forced to provide a solution, right now, I can think of only one, the easiest, disable the concurrent consuming, sort of. Here is what I would do: Receive the messages in the Queue and have only one Consumer on that queue. Inside this Consumer I would process as little from the message as I can - take ONLY the productID and place it in some other queue. Before this you would have to always check if the productID is not already in that queue. If it is just return silently, if it is not, that means it has never been processed, thus place this message in a different Queue : Queue2 for example, and then enable concurrent consumers on the second Queue Queue2. This still has flaws though: first the productID queue should somehow be cleaned once in a while, otherwise it will grow forever, but that is that that hard. The tricky part: what if you have a productID in the productID queue, but the product came for an UPDATE in the DB and not INSERT? You should not reject it then...