按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
与起初转发的消息序列不同，因为消息到期和收到更高优先级的消息。
会话必须设置消息的redelivered 标记，表示它是由于恢复而被重新转发的。
38 / 66
…………………………………………………………Page 39……………………………………………………………
4。4。12 消息的重复转发
JMS 提供商不能重复转发已确认消息。
当客户端使用AUTO_ACKNOWLEDGE 模式时，它不会直接控制消息的确认。由于这种客
户端不能确切知道某个消息是否已经被确认，因此它们必须做好再次收到最后消费的消息的
准备。这可能由于客户端完成它的工作恰好在防止消息确认发生失败之前引起。只有会话测
最后消费的消息会遇到这种情况。JMSRedelivered 消息头字段将用于这种情况下被重发的消
息。
4。4。13 消息的重复产生
JMS 提供商不能生产重复的消息。这意味着生产消息的客户端可以依赖JMS 提供商来保
证消息的消费者一个消息只会接收一次。客户端的错误不会引起提供商重复一个消息。
如果在客户端提交和提交方法返回期间出现错误，那么客户端不能决定事务是否被提交
还是被回滚。当非事务性的发送一个 PERSISTENT 消息和发送方法返回之间产生错误时，会
产生同样的不确定性问题。
这种不确定性由JMS 应用来处理。在某些情况下，这可能会造成客户端生产重复消息。
由于恢复被重发的消息不认为是重复消息。
4。4。14 客户端代码的有序执行
尽管java 语言本身提供多线程，但写多线程程序仍然比写单线程程序困难。
因此，JMS 不会引起客户端代码的并非执行，除非客户端显式地要求这样做。做到这一
点的一种途径是一个会话对所有消息的异步转发进行排序。
为了异步接收消息，客户端向MessageConsumer 注册实现了JMS MessageListener 接口
的对象。事实上，会话使用一个单线程来运行所有的MessageListener。当线程正在执行一个
监听器时，所有其他被异步转发的消息必须等待。
4。4。15 并行消息转发
希望并行转发的客户端可以使用多会话。事实上，每个会话的监听器线程并行的运行。
当会话上的监听器正在执行时，在另一个会话上的监听器也可以被执行。
注意，JMS 本省不提供并行处理主题消息集合的功能（这些消息被转发到单个消费者）。
客户端可以使用单个消费者但实现多线程逻辑来并行处理这些消息；但是，这样做是不可靠
的，因为JMS 没有事务功能来处理这种方式需要的并发事务。
4。5 MessageConsumer
客户端使用 MessageConsumer 来接收来自目的地的消息。通过向 Session 的
createConsumer 方法传入Queue 或Topic 来创建MessageConsumer。
消费者可以用消息选择器来创建。这可以让客户端限制转发到消费者的消息，只有符合
39 / 66
…………………………………………………………Page 40……………………………………………………………
选择器的消息才能被转发到该消费者。参见节3。8。1 “消息选择器”了解更详细的信息。
客户端可以同步接收消费者的消息，也可以让提供商在消息到达时异步地转发消息。
4。5。1 同步转发
客户端可以要求来自MessageConsumer 的下一个消息使用某个receiver 方法。有几个接
收变量可以让客户端获取或等待下一个消息。
4。5。2 异步转发
客户端可以向MessageConsumer 注册一个实现了JMS MessageListener 接口的对象。当
消息到达消费者时，提供商通过调用监听器的onMessage 方法来转发它们。
监听器可能会抛出RuntimeException；但是这被看作是客户端程序错误。好的监听器应
当捕获这种异常并尽量将产生异常的消息转发到应用的‘未处理消息’目的地。
监听器抛出RuntimeException 的结果依赖于会话的确认模式。
z AUTO_ACKNOWLEDGE 或DUPS_ACKNOWLEDGE——消息被立即重发。JMS 提供商在
放弃之前重发同一个消息次数由提供商决定。在这种情况下，将为重发的消息设置
JMSRedelivered 消息头字段。
z CLIENT_ACKNOWLEDGE——为监听器转发下一个消息。如果客户端希望让前一个未
确认的消息被重发，那么它必须手工恢复会话。
z 事务性的会话——为监听器转发下一个消息。客户端可以提交或回滚这个会话（换
句话说，RuntimeException 不自动回滚这个会话）。
JMS 提供商应当对抛出RuntimeException 作为可能故障的具有消息监听器的客户端进行
标记。
参见节4。4。14 “客户端代码的顺序执行”了解onMessage 如何被会话有序的调用。
4。6 MessageProducer
客户端使用MessageProducer 来向Destination 发送消息。通过向会话的createProducer
方法传入Queue 或Topic 来创建MessageProducer。
客户端也可以不提供目的地来创建消息生产者。在这种情况下，必须在每次发送操作时
提供目的地。这种风格的生产者的通常用于使用请求的 JMSReplyTo 目的地来发送请求的回
复。
客户端可以指定一个缺省的转发模式、优先级和消息的生存时间。它也可以为每个消息
指定转发模式、优先级和消息的生存时间。
客户端每次创建一个MessageProducer，它定义了一个新的消息序列，这些消息和以前
发送的消息没有顺序关系。
参见节3。4。9 “JMSExpiration ”进一步了解生存时间。参见节3。4。10 “JMSPriority ”进一
步了解优先级。
40 / 66
…………………………………………………………Page 41……………………………………………………………
4。7 消息转发模式
JMS 支持两种消息转发模式。
z NON_PERSISTENT 模式是最小符合的转发模式。因为它不要求将消息记录到稳定存
储器中。JMS 提供商失败可能导致NON_PERSISTENT 消息丢失。
z PERSISTENT 模式告诉JMS 提供商要保证在转发期间消息不能由于JMS 提供商失败
而造成消息丢失。
JMS 提供商必须“最多一次的”转发NON_PERSISTENT 消息。这意味着它可能丢失消息，
但不会转发两次。
JMS 提供商必须“有且只有一次的”转发 PERSISTENT 消息。这意味着JMS 提供商的失
败不能引起消息的丢失，但不会转发两次。
PERSISTENT 和NON_PERSISTENT 消息转发对JMS 客户端来说是两种转发技术的选择，一
种是在JMS 提供商不工作时可以丢失消息，另一种是尽力保证消息在JMS 提供商失败时还
要存在。这种选择暗含了性能/可靠性的平衡。当客户端选择NON_PERSISTENT 转发模式时，
它表示它更看重性能而不是可靠性；选择PERSISTENT 则相反。
使用PERSISTENT 消息不保证所有的消息总是被转发到每个合格的消费者。参见节4。10
“可靠性”做进一步了解。
4。8 消息的生存时间
客户端可以为它发送的每个消息以毫秒为单位指定生存时间。它定义了消息的到期时间，
到期时间是消息的生存时间和发送的GMT 的和（对于事务性发生，这个时间是客户端发送
消息的时间，不是事务提交的时间）。
JMS 提供商应当尽力做到精确的终止消息；但是，JMS 没有定义如何提供精确性。简单
地忽略生存时间是不可接受的。
参见3。4。9 “JMSExpiration ”了解消息到期的更详细信息。
4。9 异常
JMSException 是所有JMS 异常的基类。参见第7 章“JMS 异常”了解更详细的信息。
4。10 可靠性
大多数客户端应当使用生产 PERSISTENT 消息的生产者。这样可以保证有且只有一次的
转发来自队列或永久订阅的消息。
在某些情况下，应用只可以要求最多一次的消息转发。通常在发布NON_PERSISTENT 消
息时使用。这些消息通常有较低的负荷；但是，这些消息可能在JMS 提供商失败时被丢失。
PERSISTENT 和NON_PERSISTENT 消息都能被发布到同一个目的地。
通常，一个消费者在确认之前完整处理每个消息。这保证 JMS 不会因为机器出问题等
而导致丢弃部分处理的消息。消费者通过使用事务的或CLIENT_ACKNOWLEDGE 会话来达到。
JMS 提供商必须设置由于系统失败而导致重发的未确认的消息的JMSRedelivered 消息头字段。
41 / 66
…………………………………………………………Page 42……………………………………………………………
如果NON_PERSISTENT 消息被转发到永久订阅或一个队列，那么如果永久订阅变成不活
动的（也就是，如果它当前没有订阅者）或 JMS 提供商关闭然后被重新启动，则转发不受
保证。
重要的消息期望使用 PERSISTENT 转发模式在事务内生产，并且在来自非临时队列或永
久订阅的事务内被消费。
当这些都被做时，应用就拥有了最高级别的保证：消息已经被正确的生产，可靠的转发
和精确的消费。非事务的生产和消费也可以达到相同的保障级别；但是这要求认真的编码。
JMS 提供商可以限制高容量目的地能处理的消息数量或不响应的客户端数量。如果消息
由于消息限制被丢弃，则这是一个需要注意的严重的管理问题。JMS 要求的正确功能是客户
端是响应的且有足够的资源服务于这些客户端。
正如本规范描述的一样，有且只有一次的的消息转发有重要的一点，就是它不会覆盖由
于消息到期或其他管理原因毁坏的消息。它也不覆盖由于资源限制丢失的消息。为 JMS 应
用配置足够的资源和处理能力是管理员的工作，他必须知道JMS 提供商的可