|
| |
| Sun Java System Message Queue 3 2005Q1 管理指南 | |
第 12 章
问题疑难解答本章介绍如何了解及解决以下问题：
出现问题时，检查所安装 Message Queue 软件的版本号会很有帮助。使用版本号来确保目前正在使用的文档版本与软件版本相匹配。向 Sun 报告问题时，也需要用到版本号。要检查版本号，请执行以下命令：
imqcmd -v
客户机无法建立连接此问题的症状如下：
本节详细说明了以下可能的原因：
客户机应用程序不是闭合连接，导致连接数超出资源限制
确认这是否就是问题的起因
列出代理的所有连接：
imqcmd list cxn
输出结果将列出所有的连接以及发起每个连接的主机，从而展示特定客户机的特有的打开连接数。
解决此问题
重写有问题的客户机，以关闭未使用的连接。
代理未运行或者网络连接有问题
确认这是否就是问题的起因
解决此问题
连接服务处于非活动状态或者已暂停
确认这是否就是问题的起因
检查所有连接服务的状态：
imqcmd list svc
如果某个连接服务的状态显示为 unknown （未知）或 paused（暂停），客户机将无法使用该服务建立连接。
解决此问题
要正确配置 SSL 服务，请参见使用基于 SSL 的服务。
- 如果连接服务的状态显示为 paused，可以恢复该服务（请参见暂停和恢复连接服务）。
连接所要求的线程数不够
确认这是否就是问题的起因
在代理日志中检查下面的条目：
WARNING [B3004]: 没有可用于处理服务上新连接的线程 ...正在关闭新连接。
此外，请检查连接服务上的连接数以及当前使用的线程数（使用以下格式之一）：
imqcmd query svc -n serviceName
imqcmd metrics svc -n serviceName -m cxn
每个连接都需要两个线程：一个用于外来消息，另一个用于外出消息（请参见线程池管理器）。
解决此问题
- 如果使用专用线程池模型 (imq.service_name. threadpool_model=dedicated)，则最大连接数是该线程池中的最大线程数的一半。因此，要增加连接数，请增加线程池的大小 (imq.service_name.max_threads) 或切换到共享线程池模型。
- 如果使用共享线程池模型 (imq.service_name. threadpool_model=shared)，则最大连接数是下面两个属性的乘积的一半。连接监视限制 (imq.service_name.connectionMonitor_limit) 和最大线程数 (imq.service_name.max_threads)。因此，要增加连接数，可以增加线程池的大小或增大连接监视限制。
- 最终，可支持的连接数（或连接上的吞吐量）将达到输出/输出限制。这种情况下，可以使用多代理群集在群集内的代理实例之间分布连接。
Solaris 或 Linux 操作系统上连接数所需的文件描述符不足
有关此问题的详细信息，请参见设置文件描述符限制（Solaris 或 Linux）。
确认这是否就是问题的起因
在代理日志中检查类似下面的条目：打开的文件太多。
解决此问题
增大文件描述符限制，如 ulimit 手册页中所述。
TCP 待办事项限制了可以同时建立的新连接请求数目
TCP 待办事项设置可以存储在系统待办事项 (imq.portmapper.backlog) 中的同时连接请求数限制后，端口映射器才会拒绝额外的请求。（在 Windows 操作系统上，有一种硬编码的待办事项限制：Windows 台式机限制为 5，而 Windows 服务器限制为 200。）
出于待办事项限制而拒绝请求通常是一种由于同时连接请求数过多而导致的瞬态现象。
确认这是否就是问题的起因
检查代理日志。首先，检查代理是否在接受某些连接的同时拒绝其他连接。其次，检查说明拒绝连接原因的消息。如果找到此类消息，则说明问题可能不是由 TCP 待办事项引起的，因为代理不记录由于 TCP 待办事项而引起的连接拒绝。
如果记录了一些成功连接，但未记录任何连接拒绝，则问题可能是由 TCP 待办事项引起的。
解决此问题
下列方法可用于解决 TCP 待办事项限制：
操作系统限制了并行连接数
Windows 操作系统许可证对支持的并行远程连接数进行了限制。
确认这是否就是问题的起因
检查是否有可用于连接的足够线程（使用 imqcmd query svc），并检查您的 Windows 许可协议的条款。如果您可以从本地客户机建立连接，但不能从远程客户机建立连接，则操作系统的限制可能就是问题的起因。
解决此问题
对用户的验证或授权失败
验证可能因为密码错误而失败，原因是在用户系统信息库中没有该用户的条目，或者该用户没有对连接服务的访问权限。
确认这是否就是问题的起因
检查代理日志中的条目，判断是否有禁用错误消息。此消息指明存在验证错误，但不会指明该错误的原因。
解决此问题
- 如果在用户系统信息库中没有该用户的条目，则将该用户添加到用户系统信息库中（请参见填充和管理用户系统信息库）。
- 如果使用了错误的密码，请提供正确的密码。
- 如果访问控制属性设置不当，则编辑访问控制属性文件以授予连接服务权限（请参见用于连接服务的访问控制）。
连接的吞吐量太慢此问题的症状如下：
- 消息的吞吐量与预期不符。
- 支持的代理连接数受到限制不是如客户机无法建立连接中所述的原因，而是出于消息的输入/输出速率。
本节详细说明了以下可能的原因：
网络连接或 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 兼容的数据存储库，则检查插入的持久性是否正确配置（请参见第 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 状态 用户名 消息数/确认数 创建时间
----------------------------------------------------------------------
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，则说明代理发生错误。
解决此问题
