|
| |
| Sun Java System Message Queue 3 2005Q4 管理指南 | |
第 12 章
问题疑难解答本章介绍如何了解及解决以下问题：
出现问题时，检查所安装 Message Queue 软件的版本号会很有帮助。可以使用版本号来确保目前正在使用的文档版本与软件版本相匹配。向 Sun 报告问题时，也需要用到版本号。要检查版本号，请执行以下命令：
imqcmd -v
客户端无法建立连接此问题的症状如下：
本节探讨了如下可能的原因：
客户端应用程序不关闭连接，导致连接数超出资源限制
确认这是否就是问题的起因
列出代理的所有连接：
imqcmd list cxn
输出结果将列出所有连接以及发起每个连接的主机，从而显示具体是哪些客户端的打开连接数超出限制。
解决此问题
重写有问题的客户端，以关闭未使用的连接。
代理未运行或者网络连接有问题
确认这是否就是问题的起因
解决此问题
连接服务处于非活动状态或者已暂停
确认这是否就是问题的起因
检查所有连接服务的状态：
imqcmd list svc
如果某个连接服务的状态显示为 unknown 或 paused，客户端将无法使用该服务建立连接。
解决此问题
要正确配置 SSL 服务，请参见使用基于 SSL 的服务。
- 如果连接服务的状态显示为 paused，请恢复该服务（请参见暂停和恢复连接服务）。
相对于所需的连接数而言，可用线程数不足
确认这是否就是问题的起因
在代理日志中检查下面的条目：
警告 [B3004]：服务上没有可以用来处理新连接的线程...关闭新连接。
此外，请检查连接服务上的连接数以及当前使用的线程数（使用以下格式之一）：
imqcmd query svc -n serviceName
imqcmd metrics svc -n serviceName -m cxn
每个连接都需要两个线程：一个用于传入消息，另一个用于传出消息（请参见线程池管理）。
解决此问题
- 如果使用专用线程池模型 (imq.serviceName. threadpool_model=dedicated)，则最大连接数是该线程池中的最大线程数的一半。因此，要增加连接数，请增加线程池的大小 (imq.serviceName.max_threads) 或切换到共享线程池模型。
- 如果使用共享线程池模型 (imq.serviceName. threadpool_model=shared)，则最大连接数是下面两个属性的乘积的一半：连接监视限制 (imq.serviceName.connectionMonitor_limit) 和最大线程数 (imq.serviceName.max_threads)。因此，要增加连接数，可以增加线程池的大小或增大连接监视限制。
- 最终，可支持的连接数（或连接上的吞吐量）将达到输出/输出限制。这种情况下，可以使用多代理群集在群集内的代理实例之间分布连接。
相对于 Solaris 或 Linux 操作系统上需要的连接数而言，文件描述符不足
有关此问题的详细信息，请参见设置文件描述符限制。
确认这是否就是问题的起因
在代理日志中查找与下面显示的条目类似的条目：打开了太多文件。
解决此问题
增大文件描述符限制，如 ulimit 手册页中所述。
TCP 待办事项限制了可以同时建立的新连接请求的数目
TCP 待办事项限制可以同时存储在系统待办事项 (imq.portmapper.backlog) 中的连接请求数，超过此限制后，端口映射器将拒绝额外的请求。（在 Windows 操作系统上，有一种硬编码的待办事项限制：Windows 台式机限制为 5，而 Windows 服务器限制为 200。）
出于待办事项限制而拒绝请求通常是一种由于同时连接请求数过多而导致的瞬态现象。
确认这是否就是问题的起因
检查代理日志。首先，检查代理是否在接受某些连接的同时拒绝其他连接。其次，检查说明拒绝连接原因的消息。如果找到此类消息，则说明问题可能不是由 TCP 待办事项引起的，因为代理不记录由于 TCP 待办事项而引起的连接拒绝事件。
如果记录了一些成功连接，但未记录任何连接拒绝事件，则问题可能是由 TCP 待办事项引起的。
解决此问题
以下方法可用于解决 TCP 待办事项限制：
操作系统限制了并行连接数
Windows 操作系统许可证对支持的并行远程连接数进行了限制。
确认这是否就是问题的起因
检查是否有可用于连接的足够线程（使用 imqcmd query svc），并检查您的 Windows 许可协议的条款。如果您可以从本地客户端建立连接，但不能从远程客户端建立连接，则操作系统的限制可能就是问题的起因。
解决此问题
对用户的验证或授权失败
验证可能因为密码错误而失败，原因是在用户系统信息库中没有该用户的条目，或者该用户没有对连接服务的访问权限。
确认这是否就是问题的起因
检查代理日志中的条目，查看是否有 Forbidden 错误消息。此消息指明存在验证错误，但不会指明该错误的原因。
解决此问题
- 如果在用户系统信息库中没有该用户的条目，则将该用户添加到用户系统信息库中（请参见填充和管理用户系统信息库）。
- 如果使用了错误的密码，请提供正确的密码。
- 如果访问控制属性设置不当，则编辑访问控制属性文件以授予连接服务权限（请参见用于连接服务的访问控制）。
连接的吞吐量太低此问题的症状如下：
- 消息的吞吐量与预期不符。
- 支持的代理连接数受到限制不是如客户端无法建立连接中所述的原因，而是由于消息的输入/输出速率而导致的。
本节探讨了如下可能的原因：
网络连接或 WAN 太慢
确认这是否就是问题的起因
Ping 网络，查看返回 ping 需要的时间，然后咨询网络管理员。另外还可以使用本地客户端发送并接收消息，并将传送时间与远程客户端（使用网络链路）的传送时间相比。
解决此问题
如果连接太慢，则升级网络链路。
与 TCP 相比，连接服务协议本身就慢
例如，基于 SSL 或基于 HTTP 的协议要比 TCP 慢（请参见图 11-5）。
确认这是否就是问题的起因
如果您使用的是基于 SSL 或基于 HTTP 的协议，请尝试使用 TCP，然后比较传送时间。
解决此问题
应用程序的要求通常会限定使用的协议，因此您可以做的事情就很少了，无非是按调整传输协议中所述尝试调整协议而已。
连接服务协议未进行优化调整
确认这是否就是问题的起因
尝试调整协议，确定是否发生了变化。
解决此问题
尝试按调整传输协议中所述调整协议。
消息太大，以致于占用了过多的带宽
确认这是否就是问题的起因
尝试使用较小的消息运行基准测试程序。
解决此问题
使连接吞吐量变低的可能原因也就是消息传送过程中某个步骤的瓶颈
确认这是否就是问题的起因
如果上述每一条看来都不是造成连接吞吐量变低的原因，请参见图 11-1 了解其他可能的瓶颈，并检查与以下问题相关的症状：
解决此问题
遵循前面有关问题疑难解答的各节中提供的问题解决方针。
客户端无法创建消息生成方此问题的症状如下：
本节探讨了如下可能的原因：
物理目标被配置为仅允许有限数目的生成方
限制某个物理目标所支持的生成方 (maxNumProducers) 数目是避免消息在该物理目标上堆积的方法之一。
确认这是否就是问题的起因
检查物理目标（请参见显示有关物理目标的信息）：
imqcmd query dst
输出结果将显示当前的生成方数目以及 maxNumProducers 的值。如果这两个值相同，则说明生成方的数目已达到所配置的限制。如果新的生成方被代理拒绝，代理将返回“ResourceAllocationException [C4088]：已达到 JMS 目的地限制”消息，且在代理日志中生成如下条目：[B4183]：无法将生成方添加到目的地。
解决此问题
增大 maxNumProducers 属性的值（请参见更新物理目标属性）。
由于访问控制属性文件中的设置，用户未获得创建消息生成方的授权
确认这是否就是问题的起因
如果新的生成方被代理拒绝，代理将返回以下消息：
代理还在代理日志中记录以下条目：
解决此问题
更改访问控制属性，允许用户生成消息（请参见对物理目标的访问控制）。
消息的生成过程延迟或速度减慢此问题的症状如下：
本节探讨了如下可能的原因：
消息服务器上堆满了待办事项，使得消息生成方速度减慢
堆满待办事项的服务器将消息堆积在代理内存中。
当物理目标内存中的消息数或消息字节数达到配置的限制时，代理会尝试根据指定的限制行为来节省内存资源。以下限制行为会使消息生成方速度减慢：
同样，如果代理范围的内存（对于所有物理目标）中消息数或消息字节数达到配置的限制，代理将尝试通过拒绝最新的消息来节省内存资源。
另外，如果达到了系统内存限制（由于物理目标或代理范围限制设置不正确），代理将采取愈加严格的操作来防止内存过载。这些操作包括限制消息生成方。
确认这是否就是问题的起因
如果某个消息因为达到了配置的消息限制而被代理拒绝，代理将返回以下消息：
代理还在代理日志中记录以下条目：
该消息后面接有一条表明已达到限制的消息。如果物理目标上存在消息限制，则代理将生成如下所示的条目：
如果消息限制是代理范围的，则代理将生成如下所示的条目：
通常，您可以在发生拒绝之前按如下方式检查消息限制情况：
- 查询物理目标和代理，并检查其配置的消息限制设置。
- 使用相应的 imqcmd 命令，监视当前物理目标或代理（作为一个整体）中的消息数或消息字节数。有关可以监视的度量以及用来获取它们的命令的信息，请参见第 18 章“度量参考”。
解决此问题
有很多方法可以解决由于消息堆积而导致生成方变慢的问题。
通常，应该根据每个目标来管理内存，这样才不会达到代理范围的消息限制。有关更多信息，请参见代理调整。
例如，您可以指定 REMOVE_OLDEST 和 REMOVE_LOW_PRIORITY 限制行为，这些行为可以删除在内存中堆积的消息（请参见表 15-1）。
代理无法将持久性消息保存到数据存储中
如果代理无法访问数据存储或者无法将持久性消息写入数据存储，则生成方客户端将阻塞。如前所述，如果达到了目标或代理范围的消息限制，也会发生这种情况。
确认这是否就是问题的起因
如果代理无法写入数据存储，它将在代理日志中生成以下条目之一：
[B2011]：存储来自 connectionID 的 JMS 消息失败... 或 [B4004]：无法持续消息 messageID...解决此问题
- 如果是基于文件的持久性，则尝试增大基于文件的数据存储的磁盘空间。
- 如果是符合 JDBC 的数据存储，则检查基于 JDBC 的持久性是否正确配置（请参见第 4 章“配置代理”）。如果是这样，请向数据库管理员咨询，以解决其他数据库问题。
代理的确认超时太短
如果连接太慢或消息服务器反应迟缓（由于 CPU 占用率太高或者内存资源不足导致），代理用于确认收到持久性消息的时间比连接工厂的 imqAckTimeout 属性值所允许的时间要长。
确认这是否就是问题的起因
如果超出了 imqAckTimeout 值，代理将返回以下消息：
JMSException [C4000]：包确认失败
解决此问题
更改 imqAckTimeout 连接工厂属性的值（请参见可靠性和流控制）。
生成方客户端遇到了 JVM 限制
确认这是否就是问题的起因
解决此问题
调整 JVM（请参见 Java 虚拟机调整）。
消息堆积此问题的症状如下：
本节探讨了如下可能的原因：
主题目标上有非活动的长期订阅
如果长期订阅是非活动的，则消息会存储在目标中，直到相应的使用方变为活动状态且能够使用这些消息为止。
确认这是否就是问题的起因
检查每个主题目标上的长期订阅的状态：
imqcmd list dur -d destName
解决此问题
可以采用下列任意操作：
队列中可以使用消息的使用方太少
如果消息可以传送到的活动使用方太少，队列目标可能会随着消息的堆积而堆满了待办事项。只要有下列任何原因，都会发生此情况：
确认这是否就是问题的起因
要确定使用方不可用的原因，请检查目标上活动使用方的数目：
imqcmd metrics dst -n destName -t q -m con
解决此问题
您可以根据使用方不可用的原因采取下面相应的操作：
- 通过启动其他使用方客户端来为队列创建更多的活动使用方。
- 调整 imq.consumerFlowLimit 代理属性以优化向多个使用方的队列传送（请参见多使用方队列性能）。
- 指定队列的消息限制以及限制行为属性（请参见表 15-1）。例如，您可以指定 REMOVE_OLDEST 和 REMOVE_LOW_PRIORITY 限制行为，这些行为删除堆积在内存中的消息。
- 清除来自相应目标的所有消息（请参见清除物理目标）。
- 限制消息可以在内存中保留的时间。您可以重写生成方客户端以对每个消息都设置一个生存时间值，也可以通过设置 imqOverrideJMSExpiration 和 imqJMSExpiration 连接工厂属性来覆盖共享一个连接的所有生成方的任何此类设置（请参见消息头覆盖）。
消息使用方的处理速度太慢，跟不上消息生成方的速度
在这种情况下，主题的订阅者或队列的接收者使用消息的速度要比生成方发送消息的速度慢。有一个或多个目标因为这种不平衡而堆满了消息。
确认这是否就是问题的起因
检查消息流入和流出代理的速率：
imqcmd metrics bkr -m rts
然后检查每个单独目标的流速：
imqcmd metrics bkr -t destType -n destName -m rts
解决此问题
- 优化使用方客户端代码。
- 对于队列目标，增大活动使用方的数目（请参见多使用方队列性能）。
客户端确认处理减慢了消息的使用
有两个因素影响客户端确认处理：
确认这是否就是问题的起因
解决此问题
- 修改客户端使用的确认模式，例如切换到 DUPS_OK_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE。
- 如果使用 CLIENT_ACKNOWLEDGE 或事务会话，则将更多数目的消息组合到一个确认中。
- 调整使用方和连接流控制参数（请参见客户端运行时消息流调整）。
代理无法适应生成消息的速度
在这种情况下，消息流入代理的速度比代理可以将它们路由并发送到使用方的速度要快。代理的迟缓可能由下列任一或全部限制所导致：CPU、网络套接字读/写操作、磁盘读/写操作、内存分页、持久性存储或 JVM 内存限制。
确认这是否就是问题的起因
检查有无其他原因导致此问题。
解决此问题
客户端代码缺陷：使用方不确认消息
消息会保留在目标中，直到消息所发送到的所有使用方都进行了确认为止。如果客户端没有确认已使用消息，则该消息会在目标中堆积，而不会被删除。
例如，客户端代码可能存在以下缺陷：
确认这是否就是问题的起因
首先检查本节中列出的其他所有可能的原因。其次，使用以下命令列出目标：
imqcmd list dst
请注意 UnAcked 标题下列出的消息数目是否与目标中的消息数目相同。UnAcked 标题下的消息已发送到使用方但未得到确认。如果此数目与消息总数相同，则说明代理已发送所有消息，正在等待确认。
解决此问题
请求应用程序开发者帮助调试此问题。
消息服务器吞吐量呈间歇性此问题的症状如下：
本节探讨了如下可能的原因：
代理的内存资源非常低
由于目标和代理限制设置不当，代理采取了越来越严格的措施以防止内存过载，这样就导致代理变得非常迟缓，直到堆积的消息得到清除为止。
确认这是否就是问题的起因
在代理日志中检查内存低的情况（[B1089]：内存不足，代理正在尝试释放资源），该情况后面会接有一个描述新内存状态和已用内存总量的条目。
另外请检查 JVM 堆中的可用内存：
imqcmd metrics bkr -m cxn
当总 JVM 内存接近 JVM 内存最大值时，可用内存就会很低。
解决此问题
- 调整 JVM（请参见 Java 虚拟机调整）。
- 增大系统交换空间。
正在发生 JVM 内存回收（垃圾收集）
内存回收会定期清扫整个系统，以释放内存。发生此操作时，所有的线程都会阻塞。要释放的内存量以及 JVM 堆的大小越大，因内存回收而导致的延迟就越长。
确认这是否就是问题的起因
监视计算机上的 CPU 使用率。发生内存回收时，CPU 使用率会下降。
另外，使用以下命令行选项启动代理：
-vmargs -verbose:gc
其标准输出指明发生内存回收的时间。
解决此问题
在多个 CPU 的计算机中，将内存回收设置为并行发生：
-XX:+UseParallelGC=true
JVM 使用实时编译器来提高性能
确认这是否就是问题的起因
检查有无其他原因导致此问题。
解决此问题
让系统运行一段时间，性能应该会有所改善。
消息无法到达使用方此问题的症状如下：
本节探讨了如下可能的原因：
限制行为导致消息在代理上被删除
如果目标内存中的消息数或消息字节数达到了配置限制，代理将尝试节省内存资源。当达到限制时，代理将采取下列三个可配置的行为，从而导致消息丢失：
如果代理内存中的消息数或消息字节数达到配置的限制，代理将尝试通过拒绝最新的消息来节省内存资源。
确认这是否就是问题的起因
检查停用消息队列，如停用消息队列包含消息中所述。具体地说，是使用消息的数目或者其大小超出目标限制中的说明。查找 REMOVE_OLDEST 或 REMOVE_LOW_PRIORITY 原因。
解决此问题
增加目标限制。例如：
imqcmd update dst -n MyDest -o maxNumMsgs=1000
消息超时值即将到期
代理将删除超时值已过期的消息。如果目标上完全堆满了消息，生存时间值过短的消息将被删除。
确认这是否就是问题的起因
检查停用消息队列以查看消息是否超时。
使用 QBrowser 演示应用程序来查看 DMQ 内容。QBrowser 演示程序保存在特定于操作系统的位置；要了解该位置，请参见附录 A“Message Queue 数据在特定平台上的位置”并查看“示例应用程序和位置”表。
下面是 Windows 中的一个调用示例：
cd \MessageQueue3\demo\applications\qbrowser java QBrowser
QBrowser 主窗口出现后，选择队列名称 mq.sys.dmq，然后单击“浏览”。将出现如下所示的列表。
图 12-1 QBrowser 窗口
双击消息可显示该消息的详细信息。
图 12-2 QBrowser 消息的详细信息
请注意消息的 JMS_SUN_DMQ_UNDELIVERED_REASON 属性的值是否为 EXPIRED。
解决此问题
联系应用程序开发者，请他们提高生存时间值。
时钟不同步
如果时钟之间不同步，则代理对消息生命周期的计算可能有错误，从而导致消息超过它们的到期时间而被删除。
确认这是否就是问题的起因
在代理日志文件中，查找下列任一消息：B2102、B2103、B2104。这些消息均报告检测到可能的时钟脉冲相位差。
解决此问题
检查您是否正在运行时间同步程序，如准备系统资源中所述。
使用方客户端未能在某个连接上启动消息传送
除非客户端代码建立了连接，并在该连接上启动了消息传送，否则消息将无法传送。
确认这是否就是问题的起因
检查客户端代码是否能建立连接并启动消息传送。
解决此问题
重写客户端代码，以建立连接并启动消息传送。
停用消息队列包含消息此问题的症状如下：
在提供用户名和密码后，将显示类似以下内容的输出：
在本示例中，停用消息队列 mq.sys.dmq 包含 35 条消息。
本节探讨了如下可能的原因：
消息的数目或者其大小超出目标限制
确认这是否就是问题的起因
使用 QBrowser 演示应用程序来查看停用消息队列的内容。QBrowser 演示程序位于操作系统特定的位置；要了解该位置，请参见附录 A“Message Queue 数据在特定平台上的位置”并查看“示例应用程序和位置”表。
下面是 Windows 中的一个调用示例：
cd \MessageQueue3\demo\applications\qbrowser java QBrowser
QBrowser 主窗口出现后，选择队列名称 mq.sys.dmq，然后单击“浏览”。将会出现如图 12-1 所示的列表。
双击消息可显示该消息的详细信息。将会出现如图 12-2 所示的窗口。
请注意下列消息属性的值：
请注意 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 限制行为。FLOW_CONTROL 限制行为通过使用率来控制生成率。
使用如下例所示的命令来启动流控制行为：
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
生成方比使用方的速度快
确认这是否就是问题的起因
要确定较慢的使用方是否会导致生成方速度降低，请将目标限制行为设置为 FLOW_CONTROL。FLOW_CONTROL 限制行为通过使用率来控制生成率。
使用如下例所示的命令来启动流控制行为：
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
通过执行如下例所示的命令，使用度量来检查目标的输入和输出：
imqcmd metrics dst -n myDst -t q -m rts
在度量输出中，检查以下值：
由于流控制使生成与使用协调一致，因此请注意生成是否减慢或停止。如果速率减慢或停止，则说明生成方和使用方的处理速度不一致。
也可以使用 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 list txn
下面是一个命令输出示例：
----------------------------------------------------------------------
事务 ID 状态 用户名 # Msgs/# Acks 创建时间
----------------------------------------------------------------------
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
在提供用户名和密码后，将显示类似以下内容的输出：
列出指定的代理上的所有目的地：
---------------------------------
主机 主端口
---------------------------------
localhost 7676
----------------------------------------------------------------------
名称 类型 状态 生成方 使用方 消息总数计数 未确认 平均大小
-----------------------------------------------------------------------
MyDest Queue RUNNING 0 0 5 200 1177.0
mq.sys.dmq Queue RUNNING 0 0 35 0 1422.0
成功列出目标。
未确认数值表示代理已发送且正在等待确认的消息数。如果未确认数值较高或不断增加，则说明代理正在发送消息，因此不等待速度较慢的使用方。还说明使用方未确认消息。
解决此问题
联系应用程序开发者以修复编码错误。
长期使用方处于非活动状态
确认这是否就是问题的起因
使用以下命令格式查看主题的长期订户：
imqcmd list dur -d topicName
解决此问题
发生意外的代理错误
确认这是否就是问题的起因
使用 QBrowser 对消息进行检查，如生成方比使用方的速度快中所述。
如果 JMS_SUN_DMQ_UNDELIVERED_REASON 的值是 ERROR，则说明代理发生错误。
解决此问题
