Sun Java System Message Queue 3.7 UR1 管理指南

停用消息队列包含消息

症状：

列出目的地后，发现停用消息队列包含消息。例如，执行如下所示的命令：

imqcmd list dst

在提供用户名和密码后，将显示类似以下内容的输出：

Listing all the destinations on the broker specified by:
---------------------------------
Host         Primary Port
---------------------------------
localhost    7676
----------------------------------------------------------------------
   Name     Type    State   Producers  Consumers  Msgs
                                         Total    Count  UnAck  Avg Size
------------------------------------------------- ----------------------
MyDest      Queue  RUNNING       0          0        5      0    1177.0
mq.sys.dmq  Queue  RUNNING       0          0       35      0    1422.0
Successfully listed destinations.

在本示例中，停用消息队列 mq.sys.dmq 包含 35 条消息。

可能的原因：

可能的原因：消息的数目或者其大小超出目的地限制。

确认问题的起因：使用 QBrowser 演示应用程序来查看停用消息队列的内容。要了解 QBrowser 演示程序特定于平台的位置，请参见附录 A， Message Queue^TM 数据在特定平台上的位置并查看“示例应用程序和位置”表。

下面是 Windows 平台中的一个调用示例：

cd \MessageQueue3\demo\applications\qbrowser java QBrowser

QBrowser 主窗口出现后，选择队列名称 mq.sys.dmq，然后单击 "Browse"。将会出现如前面“消息超时值即将到期”中所示的列表。双击消息可显示该消息的详细信息，如“消息超时值即将到期”中所示。

请注意下列消息属性的值：

JMS_SUN_DMQ_UNDELIVERED_REASON
JMS_SUN_DMQ_UNDELIVERED_COMMENT
JMS_SUN_DMQ_UNDELIVERED_TIMESTAMP

请注意 JMS 标题下面的 JMSDestination 值，以确定消息将停用的目的地。

解决此问题：增加目的地限制。例如：

imqcmd update dst - n MyDest -o maxNumMsgs=1000

可能的原因：代理时钟和生成方时钟不同步。

确认问题的起因：使用 QBrowser 应用程序来查看停用消息队列中各消息的详细信息。检查 JMS_SUN_DMQ_UNDELIVERED_REASON 的值，查找原因为 EXPIRED 的消息。

在代理日志文件中，查找下列任一消息：B2102、 B2103、B2104。这些消息均报告检测到可能的时钟脉冲相位差。

解决此问题：检查您是否正在运行时间同步程序，如准备系统资源中所述。

可能的原因：消息超时前，使用方未接收到消息。

确认这是否就是问题的起因：使用 QBrowser 应用程序来查看停用消息队列中各消息的详细信息。检查 JMS_SUN_DMQ_UNDELIVERED_REASON 的值，查找原因为 EXPIRED 的消息。

检查目的地中是否有任何使用方。例如：

imqcmd query dst -t q -n MyDest

检查列出的“当前活动使用方数”值。如果有活动使用方，则下面的某一项为真：

使用方的连接暂停。
相对使用方执行速度而言，消息超时时间太短。

解决此问题：请求应用程序开发者提高消息的生存时间值。

可能的原因：相对使用方数目而言，生成方太多。

确认问题的起因：使用 QBrowser 应用程序来查看停用消息队列中各消息的详细信息。检查 JMS_SUN_DMQ_UNDELIVERED_REASON 的值。如果原因是 REMOVE_OLDEST 或 REMOVE_LOW_PRIORITY，请使用 imqcmd query dst 命令来检查目的地中的生成方和使用方的数目。如果生成方的数目超过使用方的数目，则生成率可能会远远超出使用率。

解决此问题：添加更多的使用方客户端，或者使用如下所示的命令，将目的地限制行为设置为 FLOW_CONTROL（该限制行为通过使用率来控制生成率）：

imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL

可能的原因：生成方比使用方的速度快。

确认问题的起因：要确定较慢的使用方是否会导致生成方的速度降低，请使用如下所示的命令，将目的地限制行为设置为 FLOW_CONTROL（该限制行为通过使用率来控制生成率）：

imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL

使用如下所示的命令，使用度量来检查目的地的输入和输出：

imqcmd metrics dst - n myDst -t q -m rts

在度量输出中，检查以下值：

Msgs/sec Out：显示代理每秒删除多少条消息。在所有使用方确认收到消息后，代理将删除这些消息，因此，该度量反映了使用率。
Msgs/sec In：显示代理每秒从生成方接收多少条消息。此度量反映了生成率。

由于流控制使生成与使用协调一致，因此请注意生成是否减慢或停止。如果生成减慢或停止，则说明生成方和使用方的处理速度不一致。也可以使用 imqcmd list dst 命令，检查未确认的 (UnAcked) 发送消息的数目。如果未确认的消息数目小于目的地大小，则表明目的地尚有额外的容量，它受到客户端流控制的抑制。

解决此问题：如果生成率始终高于使用率，可以考虑有规律地使用流控制以使系统保持协调一致。此外，使用后面各节的内容，考虑并尝试消除下列可能的因素：

可能的原因：使用方太慢。

确认问题的起因：使用度量来确定生成和使用的速率，如前面“生成方比使用方的速度快”中所述。

解决此问题：

使用如下所示的命令，将目的地限制行为设置为 FLOW_CONTROL：

imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL

使用流控制将生成率降低到使用率，防止消息在代理中堆积。生成方应用程序保留消息，直到目的地可以处理它们，从而降低过期风险。
向应用程序开发者了解生成方是以稳定的速率发送消息，还是周期性成批发送。如果应用程序发送成批消息，请按照下一项中的说明增加目的地限制。
根据消息数和/或字节数增加目的地限制。要更改目的地中的消息数，请输入如下格式的命令：

imqcmd update dst - n destName -t {q|t} -o maxNumMsgs=number

要更改目的地的大小，请输入如下格式的命令：

imqcmd update dst -n destName -t {q|t} -o maxTotalMsgBytes=number

请注意，增加限制会增加代理使用的内存数。如果限制过高，代理可能会耗尽内存，从而无法处理消息。
考虑您是否可以在高负载生成期间接受消息丢失。

可能的原因：客户端不提交消息。

确认问题的起因：与应用程序开发者进行确认以查明应用程序是否使用事务。如果应用程序使用事务，则按如下所示列出活动事务：

imqcmd list txn

下面是一个命令输出示例：

----------------------------------------------------------------------
Transaction ID       State    User name  # Msgs/# Acks   Creation time
----------------------------------------------------------------------
6800151593984248832  STARTED  guest           3/2     7/19/04 11:03:08 AM

请注意消息和确认的数目。如果消息的数目很高，则生成方可能正在发送个别的消息，而未能提交事务。代理在收到提交之前，无法路由并传送该事务的消息。如果确认的数目很高，则使用方可能正在发送个别消息的确认，而未能提交事务。代理在收到提交之前，无法删除该事务的确认。

解决此问题：联系应用程序开发者以修复编码错误。

可能的原因：使用方未能确认消息。

确认问题的起因：联系应用程序开发者以确定应用程序使用的是基于系统的确认还是基于客户端的确认。如果应用程序使用基于系统的确认，则跳过本节；如果应用程序使用基于客户端的确认 (CLIENT_ACKNOWLEDGE)，请先使用如下命令减少客户端中存储的消息数：

imqcmd update dst -n myDst -t q -o consumerFlowLimit=1

其次，确定是因为代理由于使用方速度慢而缓冲消息，还是因为使用方处理消息的速度很快但未对其进行确认。使用以下命令列出目的地：

imqcmd list dst

在提供用户名和密码后，将显示类似以下内容的输出：

Listing all the destinations on the broker specified by:
---------------------------------
Host         Primary Port
---------------------------------
localhost    7676
----------------------------------------------------------------------
   Name     Type    State   Producers  Consumers  Msgs
                                         Total    Count  UnAck  Avg Size
------------------------------------------------ -----------------------
MyDest      Queue  RUNNING       0          0        5    200    1177.0
mq.sys.dmq  Queue  RUNNING       0          0       35      0    1422.0
Successfully listed destinations.

未确认数值表示代理已发送且正在等待确认的消息数。如果此数值较高或不断增加，则说明代理正在发送消息，因此不等待速度较慢的使用方。还说明使用方未确认消息。

解决此问题：联系应用程序开发者以修复编码错误。

可能的原因：长期使用方处于非活动状态。

确认问题的起因：使用以下命令格式查看主题的长期订户：

imqcmd list dur -d topicName

解决此问题：

使用 imqcmd purge dur 命令清除长期使用方。
重新启动使用方应用程序。

可能的原因：发生意外的代理错误。

确认问题的起因：使用 QBrowser 对消息进行检查，如前面“生成方比使用方的速度快”中所述。如果 JMS_SUN_DMQ_UNDELIVERED_REASON 的值是 ERROR，则说明代理发生错误。

解决此问题：

检查代理日志文件以查找相关错误。
联系 Sun 技术支持以报告代理问题。