JMS处理消息时间太长
应用程序有一个JMS队列负责交付审计日志。应用程序将日志发送到JMS队列，该队列由MDB使用。
但是，发送的消息是大 XML 文件，大小从 20 MB 到 100 MB 不等。问题在于 JMS 队列使用消息的时间太长，从而导致内存不足错误。
我应该怎么做才能解决这个问题？
共有1个答案
这个答案可能对jguhermemv没有帮助，只是想为那些能阅读这篇文章的人分享一个想法，一个解决大消息的方法。第一件事是尽量不要发送大消息，现在我们有两个选择（但是这些需要实现更改，可以在开始时完成，或者如果系统实现更改允许在稍后阶段进行）：
>
尝试将日志保存在数据库中，并在 JMS 消息中仅发送日志 ID。（不建议在 DB 中保存日志，因为保存日志的大小和时间在稍后阶段将再次成为问题。
将日志以文件的形式保存（保存在公共位置）和数据库中的文件名，并通过JMS共享这些文件名ID。消费者可以在消费后读取该日志文件。
-
我有一个Python进程（或者更确切地说，在一个使用者组中并行运行的一组进程），它根据来自某个主题的Kafka消息输入来处理数据。通常每条消息的处理都很快，但有时，取决于消息的内容，可能需要很长时间（几分钟）。在这种情况下，Kafka broker断开客户端与组的连接，并启动重新平衡。我可以将设置为一个非常大的值，但它可能会超过10分钟，这意味着如果客户机死亡，集群在10分钟内无法正确地重新平衡。
-
我可以在solace JMS队列中搜索任何特定的消息，然后在其他消息之前处理吗？我们有这样的功能w. r. t慰藉队列。
-
使用Spring AMQP（使用RabbitMQ作为消息代理），我正在准备一个消息，并且我希望我的消息在有时之后被使用。在此之前，它可以在某个队列中等待，比如等待队列，然后移动到我们的主队列，在那里我们有消费者，它正在等待处理来自主队列的消息。 p.s>如果没有rabbitmq_delayed_message_exchange插件也可以。
-
在FLTK中是通过Fl_Widegt::handle(),虚拟函数来处理系统的消息。我们可以查看Fltk的源代码来分析系统是怎样处理一些系统消息的，如按钮的消息处理 /******************************************************* Fl_Button中处理消息的代码，省略了具体的处理代码 *******************************
-
我有一个中间件位于两个JMS队列之间。它从一个数据库读取、处理一些数据到数据库中，然后写入另一个数据库。 这里有一个小图来描绘设计： 考虑到这一点，我有一些有趣的逻辑要集成到服务中。 null
-
我正在网上阅读苹果的文档 处理本地和远程通知 在我看来，它有相互矛盾的说法。有人能澄清这些困惑吗？现在让我们严格地说一下远程通知（与本地通知相比）。 文档称，如果按下通知上的操作按钮，它将调用application:didfishlaunchingwithoptions并传递通知负载。之后，它会说，如果应用程序在前台运行，它会通过应用程序：DidReceiveMemoteNotify:发送通知。这