使用WASV7（V8）的MQ 消息传递提供者激活规范处理消息
简介： 本文将介绍了 WebSphere Application Server 中的 WebSphere MQ 消息传递提供者激活规范，以及这些规范用于连接 WebSphere MQ 队列管理器和监控消息目标的机制，随后展示了应用程序服务器如何向消息驱动 bean 传递适当的消息以供处理。本文面向两类读者：需要调优系统的 ...显示全部
查看其它 3 个回答一路向北的回答
当这样的异常发生时，队列管理器会将 Message Reference 中的消息标记为 "unmarked"，以便能重新处理这些消息。可以使用 Start timeout 更改激活规范 Advanced 属性面板上的 10 秒的时间限制，如图 4 所示：
图 4. 修改服务器会话超时和等待工作开始的时间
如前所述，如果 WMQJCAResourceAdapter 线程池中没有足够的线程，工作可能会被延迟，这引发了一个明显的问题 “这个线程池的大小应该是多少？”。激活规范对每个应用程序服务器使用一个线程池来运行服务器会话。每个激活规范都有一个名为 Maximum server sessions 的高级属性，可用于定义并发服务器会话的最大数量。由于每个服务器会话都用于处理消息，因此这个属性本质上表明使用这个激活规范的消息驱动 bean 可以同时处理多少消息。因此，为了确定 WMQJCAResourceAdapter 线程池的大小应该是多少，需要对应用程序服务器上每个 WebSphere MQ 消息传递提供者激活规范的 Maximum server sessions 属性值进行合计。例如，假设您定义了 25 个激活规范，每个激活规范的 Maximum server sessions 属性值都设置为 3。这样，最多可以同时运行 75 个服务器会话，每个会话都使用 WMQJCAResourceAdapter 线程池中的一个线程。图 5 显示了 WebSphere Integrated Solutions Console 中的 WMQJCAResourceAdapter 线程池，您可以在其中更改这个线程池的大小：
图 5. 更改应用程序服务器中定义的所有激活规范可用的最大线程数量
如果您看到应用程序服务器 SystemOut.log 文件中开始出现 WorkRejected 错误，那么首先应该检查 WMQJCAResourceAdapter 线程池的大小是否足够处理您的激活规范所需的所有服务器会话。如果线程池大小适当，那么导致错误的原因是 Work Manager 不能在指定的时间内启动工作请求。这时，您应该增加激活规范高级属性 Start Timeout 的值，或者减少您的应用程序服务器系统上的负载。
图 4. 修改服务器会话超时和等待工作开始的时间
如前所述，如果 WMQJCAResourceAdapter 线程池中没有足够的线程，工作可能会被延迟，这引发了一个明显的问题 “这个线程池的大小应该是多少？”。激活规范对每个应用程序服务器使用一个线程池来运行服务器会话。每个激活规范都有一个名为 Maximum server sessions 的高级属性，可用于定义并发服务器会话的最大数量。由于每个服务器会话都用于处理消息，因此这个属性本质上表明使用这个激活规范的消息驱动 bean 可以同时处理多少消息。因此，为了确定 WMQJCAResourceAdapter 线程池的大小应该是多少，需要对应用程序服务器上每个 WebSphere MQ 消息传递提供者激活规范的 Maximum server sessions 属性值进行合计。例如，假设您定义了 25 个激活规范，每个激活规范的 Maximum server sessions 属性值都设置为 3。这样，最多可以同时运行 75 个服务器会话，每个会话都使用 WMQJCAResourceAdapter 线程池中的一个线程。图 5 显示了 WebSphere Integrated Solutions Console 中的 WMQJCAResourceAdapter 线程池，您可以在其中更改这个线程池的大小：
图 5. 更改应用程序服务器中定义的所有激活规范可用的最大线程数量
如果您看到应用程序服务器 SystemOut.log 文件中开始出现 WorkRejected 错误，那么首先应该检查 WMQJCAResourceAdapter 线程池的大小是否足够处理您的激活规范所需的所有服务器会话。如果线程池大小适当，那么导致错误的原因是 Work Manager 不能在指定的时间内启动工作请求。这时，您应该增加激活规范高级属性 Start Timeout 的值，或者减少您的应用程序服务器系统上的负载。
浏览689