![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
비ASF 모드에서 메시지 처리 방법
비ASF 모드에서는 리스너 포트를 시작한 순간부터 스레드가 활성입니다. 활성 스레드 수는 최대 세션 수에 지정된 값으로 표시됩니다. 처리할 수 있는 메시지 수에 상관없이 최대 세션 수에 지정된 스레드 수가 활성입니다. 각 활성 스레드는 개별 실제 네트워크 연결입니다.
메시징 제공자로 IBM MQ 버전 7.0 이상을 사용하는 경우 최대 10개의 스레드가 단일 실제 네트워크 연결을 공유할 수 있습니다.
WebSphere® Application Server 버전 7
이상의 경우 리스너 포트는 안정화되었습니다. 자세한 정보는 안정화된 기능에 대한 항목을 참조하십시오. 리스너 포트 사용에서 활성화 스펙 사용까지의 WebSphere MQ 메시지 구동 Bean 배치 구성을 마이그레이션해야 합니다. 비ASF 모드에 대한 활성화 스펙을 구성하는 방법에 대한 자세한 정보는 비ASF 모드에 대한 활성화 스펙 구성을 참조하십시오. 그러나 애플리케이션이 WebSphere Application Server 버전 7 이전의 애플리케이션 서버에서 작업할 필요가 없음을 확신할 때까지 이러한 마이그레이션을 시작하지 않아야 합니다.
예를 들어, 버전 6.1의 일부 멤버와 이후 버전의 일부 멤버를 사용하는 애플리케이션 서버 클러스터가 있는 경우 클러스터의 모든 애플리케이션 서버를 이후 버전으로 마이그레이션하기 전에는 활성화 스펙을 사용하기 위해 해당 클러스터의 애플리케이션을 마이그레이션하지 않아야 합니다.
비ASF 모드에서 메시지 처리
NON.ASF.RECEIVE.TIMEOUT 메시지 리스너 서비스 사용자 정의 특성에 대해 0이 아닌 값을 지정하여 비ASF 모드를 활성화합니다. NON.ASF.RECEIVE.TIMEOUT은 ASF 모드를 끄는 스위치 역할을 수행하며 receive() 메소드의 제한시간 값으로도 사용됩니다.
- SERVER.SESSION.POOL.REAP
- SERVER.SESSION.POOL.UNUSED.TIMEOUT
- SERVER.SESSION.POOL.UNUSED.TIMEOUT.Ipaname
다음 다이어그램에서는 WebSphere Application Server 및 IBM MQ 사이에서 비ASF 모드로 메시지 처리가 수행되는 방식을 보여줍니다.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)

- 리스너 포트가 시작되면 메시지 리스너 서비스 스레드 풀에서 하나의 스레드를 가져옵니다.
- 리스너 포트가 스레드에서 IBM MQ 큐 관리자에 대한 연결을 열고 JMS 메시지 이용자를 작성합니다. 메시지 이용자는 리스너 포트가 청취하도록 구성된 JMS 대상을 청취합니다.
- 리스너 포트가 메시지 처리를 관리하도록 트랜잭션을 작성합니다.
- 스레드가 메시지 이용자의 receive() 메소드를 호출하여 대상에 있는 메시지를 청취합니다. receive() 메소드가 NON.ASF.RECEIVE.TIMEOUT에 지정된 시간 동안 메시지를 발견하지 못하면 애플리케이션 서버가 활성 트랜잭션을 롤백하고 새 트랜잭션을 시작합니다. 그런 다음 스레드가 receive() 메소드 호출을 다시 시작합니다.
- 메시지 이용자가 메시지를 발견하면 메시지가 리스너 포트를 사용하는 MDB에 적합한지를 검사합니다.
- 메시지가 적합한 경우 receive() 메소드가 대상에서 해당 메시지를 가져와 스레드에 보냅니다.
- 스레드가 메시지 이용자에서 MDB의 onMessage() 메소드를 호출하고 메시지가 처리됩니다.
- 메시지가 처리를 완료하면 트랜잭션이 커미트됩니다. 메시지가 성공적으로 처리되지 않으면 트랜잭션이 롤백됩니다.
- 새 트랜잭션이 시작되고 메시지 이용자가 새 메시지를 청취하도록 receive() 메소드를 호출합니다.
- 리스너 포트가 시작되면 메시지 리스너 서비스 스레드 풀에서 두 개의 스레드를 가져옵니다.
- 리스너 포트가 각 스레드에 하나의 트랜잭션과 메시지 이용자를 작성합니다. 메시지 이용자는 리스너 포트가 청취하도록 구성된 대상을 청취합니다.
- 두 메시지 이용자 모두 receive() 메소드를 호출하여 대상에서 메시지를 청취합니다. 이용자는 대상의 메시지를 가져오려고 경쟁합니다.
- 이용자 중 한 명이 메시지를 성공적으로 검색한 경우 MDB의 onMessage() 메소드를 호출하여 메시지를 처리합니다. 기타 메시지 이용자는 대상에서 메시지를 청취하도록 계속 receive() 메소드를 호출합니다.
원치 않는 트랜잭션 제한시간 초과를 방지하는 방법
메시징 시스템을 비ASF 모드로 실행 중인 경우에 트랜잭션 제한시간이 원치 않게 초과되지 않도록 하려면 전체 트랜잭션 지속 시간 제한시간에 도달하기 전에 처리가 완료될 수 있을 정도로 처리 시간이 충분해야 합니다. 그러므로 NON.ASF.RECEIVE.TIMEOUT 메시지 리스너 서비스 사용자 정의 특성에 지정하는 값이 전체 트랜잭션 지속 시간 제한시간에 지정하는 값보다 더 작은지, 그리고 이 두 가지 특성 값 간의 차이가 MDB(Message-Driven Bean)의 onMessage() 메소드가 메시지를 처리하는 데 필요한 시간보다 더 큰지를 확인해야 합니다.
- 리스너 포트가 시작됩니다. 스레드 풀에서 스레드를 할당하고 스레드에 트랜잭션과 메시지 이용자를 작성합니다.
- 스레드는 receive() 메소드를 호출하여 메시지를 청취합니다.
- 110초가 지나면 메시지가 대상에 표시됩니다.
- 스레드가 대상에서 메시지를 제거하고 MDB의 onMessage() 메소드를 호출하여 메시지를 처리하기 시작합니다.
- 10초 후에 트랜잭션 제한시간에 도달합니다. 애플리케이션 서버가 해당 트랜잭션을 롤백 대상으로 표시합니다.
- 5초 후에 onMessage() 메소드가 메시지 처리를 완료하고 트랜잭션을 커미트하려고 시도합니다.
- 트랜잭션이 시작된 이후에 경과된 총 시간은 125초(메시지 대기 시간 110초 + 메시지를 처리하는 데 걸린 시간 15초)입니다. 이 값이 트랜잭션 제한시간보다 길기 때문에 애플리케이션 서버가 트랜잭션이 커미트되지 않도록 하며 트랜잭션이 롤백됩니다.
원하지 않는 트랜잭션 제한시간 초과를 방지하도록 NON.ASF.RECEIVE.TIMEOUT 및 총 트랜잭션 수명 제한시간 특성을 구성하는 방법에 대한 자세한 정보는 관련 태스크를 참조하십시오.