友情提示:如果本网页打开太慢或显示不完整,请尝试鼠标右键“刷新”本网页!阅读过程发现任何错误请告诉我们,谢谢!! 报告错误
狗狗书籍 返回本书目录 我的书架 我的书签 TXT全本下载 进入书吧 加入书签

JMS简明教程(PDF格式)-第19章

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
————未阅读完?加入书签已便下次继续阅读!






    客户端使用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 提供商的可靠性特性。  

    NON_PERSISTENT 消息,非永久性订阅,和临时目的地都是不可靠的。JMS 提供商关闭 

或失败时很可能造成NON_PERSISTENT 消息的丢失和临时目的地以及非永久性订阅持有的消 

息的丢失。终止应用很可能造成由非永久性订阅和临时目的地持有的消息的丢失。  



4。11  方法跨消息域继承  



    由于统一了消息域,因此某些不适用于一个域的方法可以在域类中被继承。例如,Session 

接口有方法createQueueBrowser 。由于TopicSession 继承了Session 接口,因此TopicSession 

继承了 createQueueBrowser    方法,尽管这个方法不能被主题使用,也就是主题不支持 

QueueBrowser 。表4�1 列出了这些实例。  

    如果应用企图调用列出的方法,则JMS 提供商必须抛出IllegalStateException。  

                      表4�1 必须抛出IllegalStateException 的方法  



                 接口                                       方法  



            QueueConnection                  createDurableConnectionConsumer  



              QueueSession                        createDurableSubscriber  



                                                   createTemporaryTopic  



                                                       createTopic  



                                                       unsubscribe  



              TopicSession                         createQueueBrowser  



                                                      createQueue  



                                                  createTemporaryQueue  



5  JMS 点对点模型  



5。1  概述  



    点对点系统是与消息队列一起工作的。它们是点对点的是因为客户端将消息发送到一个 

队列。某些PTP 系统通过给客户端提供自动分发消息功能模糊了PTP 和Pub/Sub 间的差别。  



                                                                          42 / 66  

  


…………………………………………………………Page 43……………………………………………………………

                                         



    对客户端来讲,通常是将它们的消息转发到单个队列中。  

    和常见的邮件箱一样,队列可以包含混合消息。但类似于实际的邮件箱,创建和维护每 

�
返回目录 上一页 下一页 回到顶部 赞(1) 踩(1)
未阅读完?加入书签已便下次继续阅读!
温馨提示: 温看小说的同时发表评论,说出自己的看法和其它小伙伴们分享也不错哦!发表书评还可以获得积分和经验奖励,认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦!