简体繁体 English

在将消息发送到ActiveMQ之前先对其进行池化

[英]Pooling messages before sending them to ActiveMQ

原文 2015-01-16 08:54:42 5 1 java/ jms/ activemq

The requirement is to send form data produced by website visitors over JMS (ActiveMQ most probably) from Tomcat. 要求是通过JMS（最有可能是ActiveMQ）从Tomcat发送网站访问者生成的表单数据。 There are two competing ideas - one would utilize an intermediary store and a thread pool to send to the queue (and attempt resend if posting to JMS fails for some reason), and the other is to just try sending the payload directly over JMS from the thread that handles the visitors' post request - and fail the request if the JMS posting fails for some reason. 有两种相互竞争的想法-一种是利用中介存储和线程池发送到队列（如果由于某种原因而发布到JMS失败，则尝试重新发送），另一种就是尝试直接从JMS通过JMS发送有效负载。处理访问者发布请求的线程-如果JMS发布由于某种原因失败，则请求失败。

The second option seems better to me, as I think it is an overkill to add an intermediary store in front of a message queue - the message queue itself should be the intermediary store. 第二种选择对我来说似乎更好，因为我认为在消息队列前面添加中间存储是一个过大的选择-消息队列本身应该是中间存储。 Does that sound right? 听起来对吗？

1 个解决方案

What? 什么？ Wait - A MQ Broker IS an intermediary (persistent) store to cope with downtime at the receiver side that can handle resend and what not. 等待-MQ Broker是一个中间存储（持久性），用于应对接收方的停机时间，该时间可以处理重发，而不能处理重发。 Non the less, you are somewhat right. 非少，你是正确的。 You don't want to miss that order just because your (remote) broker is down. 您不希望仅仅因为您的（远程）经纪人失灵而错过订单。 A resilient solution to that problem is to setup a local, possibly embedded ActiveMQ broker, then make a "network of brokers" connection to the remote broker. 针对该问题的一种有弹性的解决方案是设置本地（可能是嵌入式的）ActiveMQ代理，然后与远程代理建立“代理网络”连接。 You can be sure that the local broker is up along with your webapp, and it will handle retransmission to the remote broker, if it happends to be offline for the moment. 您可以确定本地代理和您的Web应用程序都已启动，并且如果当前恰好处于脱机状态，它将处理向远程代理的重新传输。

I would, however, advice against implementing a simple in memory buffer to hold data until it can be posted to the broker. 但是，我建议不要实现一个简单的内存缓冲区来保存数据，直到将其发布到代理为止。

Let's take a scenario (I'm just making up a purpose of the form): 让我们来看一个场景（我只是在构成表单的目的）：

User A orders a bike through the form and presses submit. 用户A通过该表格订购一辆自行车，然后按提交。
The bike order is put on the in-memory "pool" to be dispatched. 自行车订单被放置在要分发的内存“池”中。
A message is returned to the user saying "thanks for your order, the bike will arrive soon". 将向用户返回一条消息，提示“感谢您的订购，自行车将很快到货”。
The MQ broker is down for whatever reason. MQ代理由于任何原因而关闭。
Some time passes 一段时间过去了
The web server restarts because some admin found a nice patch that needs to be installed. Web服务器重新启动，因为某些管理员发现需要安装一个不错的补丁程序。
Order is gone as memory in the "redelivery pool" is scraped during restart. 重新启动过程中刮掉了“交付池”中的内存，因此订单消失了。
A week later, the customer complains about the missing bike and your sales department has no clue what he is talking about. 一周后，客户抱怨自行车丢失，而您的销售部门不知道他在说什么。