PTP 与发布/订阅
使用消息队列的点对点方法是最标准的方法。尤其是在批处理应用程序中,我看不到使用 Publish subscribe 的直接理由,它假定您有多个相同消息的消费者。
理论上,如果需要在相同的数据块上执行多个功能,您可以将不同的处理器组织为订阅者,这样可以扩展应用程序,但这是非常高级的使用场景。
是否可以从 JMS 队列中批量读取消息:
这里的 JMS 规范只讨论(可能是误读了)消息的批量确认,但它没有对消息的批量传递设置要求。
CLIENT_ACKNOWLEDGE - 使用此选项,客户端通过调用消息的确认方法来确认消息。确认消费的消息会自动确认已收到其会话已传递的所有消息。
简单地说,关于批量交付的答案是“如果 JMS 提供者支持它,则支持,否则不支持”
大多数提供商允许批量确认消息
这是执行此操作的 Oracle 界面:
public interface com.sun.messaging.jms.Message {
void acknowledgeThisMessage() throws JMSException;
void acknowledgeUpThroughThisMessage() throws JMSException;
}
CLIENT_ACKNOWLEDGE 的组合。+ 在 . message 将及时确认收到的所有消息。
手动确认消息:
这可以通过 CLIENT_ACKNOWLEDGE 和 Message 上的确认方法来实现。在这里,我将再次引用您的确认方法的 javadoc,该方法也再次引用了您的第二个问题,它谈到了对所有消息的批量确认。
void acknowledge() throws JMSException 确认此消费消息的会话的所有消费消息。所有消费的 JMS 消息都支持在客户端指定其 JMS 会话的消费消息将被显式确认时使用的确认方法。通过对消费消息调用确认,客户端确认消息传递到的会话所消费的所有消息。
对于事务会话和指定为使用隐式确认模式的会话,都会忽略确认调用。
客户端可以在每条消息被消费时单独确认,或者它可以选择将消息确认为应用程序定义的组(这是通过对组的最后接收到的消息调用确认来完成的,从而确认会话消费的所有消息。 )
已收到但未确认的消息可能会被重新传递。