【问题标题】:Messages pending in subscriber queue订阅者队列中待处理的消息
【发布时间】:2012-11-06 14:41:06
【问题描述】:

我正在使用 jboss-5.1 部署消息驱动 bean,它用于从第三方队列订阅消息。

大约 16 条消息已发布到该队列,但它们在我们的订阅者队列中仍处于待处理状态。我重新启动了服务器,消息很容易被挑选出来。

据我分析,我认为maxsize 和maxsession 可能会影响它,因为两者都是 15。但我不明白是否存在真正的问题,如何通过重新启动来解决。

日志处于错误模式。我没有得到完整的堆栈跟踪。

这是错误日志的 sn-p。

[2012-10-30 17:01:00,228] [MQQueueAgent (GQH1_PLANNING_MDM_001)]
[ERROR] STDERR: 2012.10.30 17:01:00 MQJMS1023E rollback failed

[2012-10-30 17:01:00,228] [exceptionDelivery0] [WARN ]
org.jboss.resource.adapter.jms.inflow.JmsActivation: Failure in jms activation 
org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@85d0d(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@b21aae
destination=remotewsmq/NOTIFICATION_PLANNING_MDM_001.SUBQ
destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=RemoteWSMQJMSProvider
 user=null maxMessages=1 minSession=1 maxSession=5 keepAlive=60000 useDLQ=false)

GQH1_PLANNING_MDM_001: 用于订阅的队列名称。

我用来配置 MDB 属性的文件如下。

1.ejb3-interceptors-aop.xml

  <domain name="Message Driven Bean" extends="Intercepted Bean" inheritBindings="true">
      <bind pointcut="execution(public * *->*(..))">
         <interceptor-ref name="org.jboss.ejb3.security.AuthenticationInterceptorFactory"/>
         <interceptor-ref name="org.jboss.ejb3.security.RunAsSecurityInterceptorFactory"/>
      </bind>

      <!-- TODO: Authorization? -->

      <bind pointcut="execution(public * *->*(..))">
         <interceptor-ref name="org.jboss.ejb3.tx.CMTTxInterceptorFactory"/>
         <interceptor-ref name="org.jboss.ejb3.stateless.StatelessInstanceInterceptor"/>
         <interceptor-ref name="org.jboss.ejb3.tx.BMTTxInterceptorFactory"/>
         <interceptor-ref name="org.jboss.ejb3.AllowedOperationsInterceptor"/>
         <interceptor-ref name="org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor"/>
         <!-- interceptor-ref name="org.jboss.ejb3.interceptor.EJB3InterceptorsFactory"/ -->
         <stack-ref name="EJBInterceptors"/>
      </bind>

      <annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.Pool)">
         @org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=15, timeout=10000)
      </annotation>
   </domain>

2.standardjboss.xml

<invoker-proxy-binding>
      <name>message-driven-bean</name>
      <invoker-mbean>default</invoker-mbean>
      <proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory>
      <proxy-factory-config>
        <JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
        <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
        <CreateJBossMQDestination>false</CreateJBossMQDestination>

        <!-- WARN: Don't set this to zero until a bug in the pooled executor is fixed -->

        <MinimumSize>1</MinimumSize>
        <MaximumSize>15</MaximumSize>
        <KeepAliveMillis>30000</KeepAliveMillis>
        <MaxMessages>1</MaxMessages>

        <MDBConfig>
          <ReconnectIntervalSec>10</ReconnectIntervalSec>
          <DLQConfig>
            <DestinationQueue>queue/DLQ</DestinationQueue>
            <MaxTimesRedelivered>10</MaxTimesRedelivered>
            <TimeToLive>0</TimeToLive>
          </DLQConfig>
        </MDBConfig>

      </proxy-factory-config>
    </invoker-proxy-binding>

   <activation-config-property>
        <activation-config-property-name>maxSession</activation-config-property-name>
        <activation-config-property-value>15</activation-config-property-value>
   </activation-config-property>

3.jms-ds.xml

<?xml version="1.0" encoding="UTF-8"?>

<connection-factories>

  <!-- ==================================================================== -->
  <!-- JMS Stuff                                                            -->
  <!-- ==================================================================== -->

   <!--
       The JMS provider loader. Currently pointing to a non-clustered ConnectionFactory. Need to
       be replaced with a clustered non-load-balanced ConnectionFactory when it becomes available.
       See http://jira.jboss.org/jira/browse/JBMESSAGING-843. 
   -->
   <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
          name="jboss.messaging:service=JMSProviderLoader,name=JMSProvider">
      <attribute name="ProviderName">DefaultJMSProvider</attribute>
      <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
      <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
      <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
      <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
   </mbean>

   <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
   <tx-connection-factory>
      <jndi-name>JmsXA</jndi-name>
      <xa-transaction/>
      <rar-name>jms-ra.rar</rar-name>
      <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
      <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
      <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
      <max-pool-size>20</max-pool-size>
      <security-domain-and-application>JmsXARealm</security-domain-and-application>
      <depends>jboss.messaging:service=ServerPeer</depends>
   </tx-connection-factory>

</connection-factories>

请帮忙。

【问题讨论】:

    标签: jboss5.x ibm-mq mq ejb-2.x


    【解决方案1】:

    如果侦听器没有尝试重新连接,则可能是未决消息导致它失败。

    【讨论】:

      【解决方案2】:

      根据错误,事务ROLLBACK 调用失败。失败后,队列管理器可能将这些消息保存在未完成的工作单元中。重新启动服务器将关闭连接,此时队列管理器将代表应用程序回滚事务。重新启动时,应用程序将创建一个新的 UOW 并检索消息。

      查看 WebSphere MQ 的队列管理器错误日志和全局错误日志,以确定错误是否是由资源短缺引起的。可能需要增加队列管理器事务日志的大小或调整事务参数,例如MAXUOW。

      您可能还需要更新 MQ 客户端版本或队列管理器版本。根据this Technote 的说法,WebSphere MQ JMS 类已从 6.0.2.3 更新,以修复导致 MQJMS1023E 错误的错误。如果您需要更新客户端版本,可通过SupportPac MQC75 免费下载。新客户端能够与任何后级队列管理器一起运行。升级后,该应用程序受益于新客户端代码的错误修复和性能增强,并提供适用于其连接的队列管理器版本的 API 功能。当前安装了哪个版本的 WebSphere MQ JMS 客户端?当前安装了哪个版本的 WebSphere MQ 队列管理器?

      【讨论】:

      • 这个MAXUOW适用于jboss吗?如果是,您是否知道设置它的方法。在我们的例子中,一旦我们收到一条消息,我们就提交它。所以万一出现问题,我们根本不处理它。所以不存在交易失败的问题。
      • 据我了解,这可能是原因。
      • 当一批 JMS 消息以预取的数量传递到 MDB 时,每个都从该池中分配一个实例,并通过 onMessage 函数传递到该实例。如果消息预取超过此池的 maxSize,则消息等待 MDB 实例。如果从消息传递到调用 onMessage 的时间超过任何消息的池超时,则会抛出 EJBException。对于较大的预取和较长的平均 onMessage 时间,队列末尾的消息将开始失败。但是我还是不明白,什么服务器重启可能改变了?
      • 您可能会想到MAXUMSGS,我知道我在列表服务器上错误地写了MAXUOW 时,所以几次。 MAXUMSGS 是一个 QMgr 属性。您确定 QMgr 和客户端的版本了吗? QMgr 端的错误日志说了什么?
      猜你喜欢
      • 2016-11-25
      • 2016-08-11
      • 1970-01-01
      • 2016-06-19
      • 2021-05-17
      • 1970-01-01
      • 2021-12-27
      • 2011-12-07
      • 2012-11-29
      相关资源
      最近更新 更多