2012-11-06 8 views
1

jboss-5.1을 사용하여 타사 큐에서 메시지를 구독하는 데 사용되는 메시지 기반 Bean을 배포하고 있습니다.구독자 큐에서 보류중인 메시지

약 16 개의 메시지가 해당 큐에 게시되었지만 구독자 큐에 대기 중입니다. 서버를 다시 시작하면 메시지가 쉽게 선택되었습니다.

내가 분석 한 것만 큼 maxsizemaxsession이 모두 영향을 미쳤을 수 있다고 생각합니다.하지만 실제 문제가 있다면 어떻게 다시 시작해야하는지 이해할 수 없습니다.

로그가 오류 모드입니다. 전체 스택 추적을 얻지 못했습니다.

이것은 오류 로그의 스 니펫입니다.

[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 
[email protected]([email protected] 
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-인터셉터 - 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> 

도와주세요.

답변

1

오류에 따르면 트랜잭션 ROLLBACK 호출에 실패했습니다. 실패 후에, 큐 관리자는 아마도이 메시지를 미결 작업 단위 (UOW)에 보유한 것입니다. 서버를 다시 시작하면 연결이 닫히고 큐 관리자가 응용 프로그램을 대신하여 트랜잭션을 롤백합니다. 다시 시작하면 응용 프로그램은 새 UOW를 작성하고 메시지를 검색합니다.

WebSphere MQ의 큐 관리자 오류 로그 및 전역 오류 로그를보고 오류가 자원 부족으로 인한 것인지 판별하십시오. 큐 관리자 트랜잭션 로그의 크기를 늘리거나 MAXUOW과 같은 트랜잭션 매개 변수를 조정해야 할 수도 있습니다.

또한 MQ 클라이언트 버전 또는 큐 관리자 버전을 업데이트해야 할 수도 있습니다. this Technote에 따르면 MQJMS1023E 오류를 야기한 버그를 수정하기 위해 WebSphere MQ JMS 클래스가 6.0.2.3에서 갱신되었습니다. 클라이언트 버전을 업데이트해야 할 경우 SupportPac MQC75과 같이 무료로 다운로드 할 수 있습니다. 새 클라이언트는 모든 백 레벨 큐 관리자와 함 2 실행할 수 있습니다. 업그레이드 후에는 새로운 클라이언트 코드의 버그 수정 및 성능 향상의 이점을 얻고 연결하는 대기열 관리자 버전에 적합한 API 기능을 제공합니다. 현재 설치된 WebSphere MQ JMS 클라이언트 버전은 무엇입니까? 현재 어떤 WebSphere MQ 대기열 관리자 버전이 설치되어 있습니까?

+0

이 MAXUOW는 jboss에 적용됩니까? 그렇다면 설정 방법을 알고 있습니까? 우리의 경우 메시지를 받으면 그냥 커밋합니다.그래서 어떤 문제가 발생하면 우리는 단순히 그것을 처리하지 않습니다. 따라서 거래가 실패하는 것에 대한 의문은 없습니다. – dev

+0

제 생각에 이것은 이유가 될 수 있습니다. – dev

+0

대량의 JMS 메시지가 프리 페치 양으로 MDB에 전달되면 각 풀에이 인스턴스가 할당되고 onMessage 함수를 통해 해당 인스턴스로 전달됩니다. 메시지 프리 페치가이 풀의 maxSize를 초과하면 메시지는 MDB 인스턴스를 기다립니다. 메시지 전달에서 onMessage 호출까지의 시간이 메시지의 풀 시간 초과를 초과하면 EJBException이 발생합니다. 대량 프리 페치 및 평균 평균 대기 시간의 경우 대기열 끝으로 향하는 메시지가 실패하기 시작합니다. 하지만 다시 이해할 수없는 서버 재시작 가능성이 있습니까? – dev

2

리스너가 다시 연결을 시도하지 않은 경우, 실패한 메시지가 보류 중일 수 있습니다.

관련 문제