问题标签 [qpid]

我们正在构建一个测试客户端来为 Apache Qpid 进行一些负载/故障转移测试。

我的管理员同行告诉我，我应该随机化消息负载中的字节。他们对此的推理是，存在某种类型的缓存可能会影响测试的有效性。

在我费尽心思随机化所有有效负载字节（这本身会对测试结果产生影响）之前，这是真的吗？是否存在我应该注意的接口级别的缓存？您认为这会显着影响我的测试结果吗？考虑到除了消息的有效负载之外，其他字段也会发生变化（消息 ID、目的地、元数据等）

I was browsing for an open source messaging software and after some good bit of research I came across these three products. I've taken these out for a preliminary test drive, having had them handle messages for queues and topics, and from what I've read all three of these products are good picks for an Open Source messaging solution for most companies. What I was wondering was what are the advantages that these products may have over one another? What I'm particularly interested in is messaging throughput, including persistent messaging throughput, security, scalability, reliability, support, routing capabilities, administrative options such as metrics and monitoring, and generally just how well each program runs in a large business environment.

我有一个 C++ 发布者来发送这样的消息：

我有一个这样的 Java 订阅者：

上述代码中未收到任何消息。我很困惑这将如何工作？对于消费者来说，正确的绑定 URL 形式是什么？我错过了什么？

弹簧配置

我的服务.java

当我重新启动 QPID

如果没有 reconnectOnException=true，我不断收到此异常，但没有重新连接

使用 reconnectOnException=true ，它会连接和断开连接

我必须使用带有 apache qpid java 客户端的 rabbitmq-server（因为我必须使用 apache camel）。但我对它们的版本感到困惑，特别是因为它们都支持 amqp 协议。

哪个版本的 java 客户端 qpid 可以消费/生产，例如 rabbitmq-server 的最后一个稳定版本？或者最好的配对版本是什么？使用哪种 qpid url 格式？

提前致谢。

ZeroMQ我的应用程序需要高性能消息总线，因此我正在评估RabbitMQ和的性能Apache Qpid。为了测量性能，我正在运行一个测试程序，该程序使用其中一个消息队列实现发布 10,000 条消息，并在同一台机器上运行另一个进程来使用这 10,000 条消息。然后我记录发布的第一条消息和收到的最后一条消息之间的时间差。

以下是我用于比较的设置。

1. RabbitMQ：我使用了“扇出”类型的交换和默认配置的队列。我使用了 RabbitMQ C 客户端库。
2. ZeroMQ：我的发布者tcp://localhost:port1使用ZMQ_PUSH套接字发布，我的代理监听tcp://localhost:port1并将消息重新发送到 tcp://localhost:port2，我的消费者tcp://localhost:port2使用ZMQ_PULL套接字监听。我使用代理而不是点对点通信ZeroMQ来使性能比较与使用代理的其他消息队列实现公平。
3. QpidC++ 消息代理：我使用了“扇出”类型的交换和默认配置的队列。我使用了 Qpid C++ 客户端库。

以下是性能结果：

1. RabbitMQ: 接收 10,000 条消息大约需要 1 秒。
2. ZeroMQ: 接收 10,000 条消息大约需要 15 毫秒。
3. Qpid: 接收 10,000 条消息大约需要 4 秒。

问题：

1. 有没有人在消息队列之间进行类似的性能比较？然后我喜欢将我的结果与你的结果进行比较。
2. 有什么方法可以调整RabbitMQ或Qpid使其性能更好吗？

笔记：

测试是在分配有两个处理器的虚拟机上完成的。结果可能因不同的硬件而异，但我主要对 MQ 产品的相对性能感兴趣。

如何强制仅在 Red Hat MRG/Apache QPID 中浏览队列，以便客户端只能浏览队列。即使某些客户端尝试从队列中消费消息，他也不应该这样做。

我正在使用corosync和操作系统 Debian。当我启动 qpidd 程序时，写下这条消息：

警告 ClasterClock 任务延迟 1 次，平均延迟 70 毫秒

如何确保消息确认仅删除消息，直到在 jms 代理中调用确认的消息。目前我有一个系统，它从 jms 队列中消耗并部分处理它。稍后，一批这些消息被不同的线程持久化。我现在需要确认消息。但问题是我必须停止使用这些消息，否则确认先前收到的消息也将确认收到的所有其他后续消息。

换句话说，假设我在队列中有 10 条消息。我消耗了其中的 7 个，然后在第 5 条消息上确认。这反过来会从队列中删除消费者收到的所有 7 条消息。有没有办法只从队列中确认和删除消息，直到第 5 条消息。

编辑：我尝试创建两个会话并从不同的会话中使用，但是（至少使用 apache qpid）这执行不一致。我的意思是不一致，有时在测试过程中，一个消费者能够接收消息，而另一个消费者根本没有收到消息，无论您等待多长时间。这对我来说是一个解决方案，但由于不一致，不能将其用作解决方案。

我正在为我的公司编写电子邮件网络服务。主要要求之一是保证交付，因此我们在 JMS 传输上使用了一个薄的 HTTP 层，使用持久性 QPid 队列。

我遇到的问题之一是处理过程中的错误处理。如果我在出现错误时简单地回滚事务，则消息将转到队列的头部。如果错误足够普遍，这可能会锁定整个队列，直到有人手动干预，我们希望通过回发到头部来避免这种情况，以便同时处理消息。

然而，这就是我的问题。首先，虽然 AMQP 有一种机制来原子地“拒绝和重新排队”消息而不是确认消息，但 JMS 似乎没有任何类似的功能，所以访问它的唯一方法是通过强制转换，这将我与具体的 JMS 实现。此外，CXF 的 JMS 传输似乎没有任何方法可以在传输级别覆盖或注入行为，这意味着我要么编写字节码代理要么更改代码并重新编译以获得我想要的行为。

为了解决这个问题，我尝试了在 CXF 中实现一个错误处理程序的想法，它只是从 CXF 消息中重建 JMS 消息，然后重新排队。但是我不能使用事务处理的会话，因为故障导致我无法覆盖的回滚，然后我将在头部（来自回滚）和尾部（从重新排队）。而且我不能使用 CLIENT_ACKNOWLEDGE，因为 JMS 传输在提交消息进行处理之前会确认消息，这意味着如果服务器在错误的时间关闭，我可能会丢失消息。

所以基本上，只要我坚持接受 JMS 传输的默认行为，似乎不可能在不影响数据完整性的情况下获得我想要的行为（失败消息的重新排队）。

一位同事建议完全避开 JMS 传输，直接调用队列。然后，服务实现将是一个框架类，它的存在仅用于将消息放入队列，另一个进程将实现一个消息侦听器。对我来说，这个解决方案不是最理想的，因为我失去了不可知 Web 服务的优雅，并且由于将我的实现与底层技术耦合而失去了一些可伸缩性。

我还考虑过使用 RabbitMQ 客户端库为 AMQP 编写 CXF 传输。这将需要更长的时间，但我们公司可以继续使用它，也许可以回馈给 CXF 项目。也就是说，我对这个想法并不感兴趣，因为编写、运行和测试代码需要花费大量时间。

这是我的 CXF beans.xml：

我缺少一些简单的东西吗？或者有没有更好的方法来解决这个问题，可以回避这个问题？