[SAP EAI] JDBC Receiver Channel (Maximum Concurrency Error)

SAP PI System을 사용하는 중 JDBC Receiver Channel 에서 해당 에러가 발생했습니다.

 

Error 내용

Channel has reached configured maximum concurrency (2 concurrent messages) and could not find free resource within 180,000 milliseconds; consider incressing the maximum concurrency level

 

maximum Concurrency Error 화면

 

Maximum Concurrency는 java의 Thread의 갯수라고 보시면 됩니다. 한 프로세스에서 한번에 병렬 처리할 수 있는 최대 처리 량을 뜻합니다. 

 

https://answers.sap.com/questions/12615717/maximum-concurrency-use.html 의 캡처화면 참고

해당 에러가 발생했을때 Maximum Concurrency의 값은 2로 설정되어 있었고,  poolWaitingTime의 값은 180,000으로 설정해두었습니다.

 

poolWaitingTime Setting 화면

해당 에러의 경우에는 Maximum Concurrency로 설정한 값보다 더 많은 양의 값을 처리하고자 하여 에러가 난 내용으로 해결 방법은 아래와 같습니다.

 

---

1) 한번에 처리되어야 할 데이터의 양을 늘린다.

  - Maximum Concurrency 의 값을 늘린다.(SAP에서는 Maximum Concurreny의 최대 권장값은 5로 지정하고 있습니다.)

 

2) PoolWaitingTime의 값을 늘려준다.

 - PoolWaitingTime은 JDBC Reciver Channel이 병렬 연결이 완료될 때까지 연결을 기다리는 시간(in milli seconds)이다.

 

3) Disconnect from Database After Processing Each Message를 체크해준다.

 - Database에 접속하여 Transaction처리를 하고 연결을 끊어준다는 설정이다. (큐가 처리될 때마다 Database에 다시 접속하여 Transaction 처리)

 

4) NWA 접속해서 Prameter 값을 늘려 Maximum Concurrency의 값을 늘려준다.(적용 시 서비스 재시작 필요)

 - 접속 경로

   : http://<server>:<port>/nwa/sys-config/

   : http://<server>:<port>/nwa -> Configuration -> Infrastructure -> Java System Properties

Default values
(name=global,messageListener=localejbs/AFWListener,exceptionListener=localejbs/AFWListener,pollInterval=60000,pollAttempts=60,Send.maxConsumers=5, Recv.maxConsumers=5,Call.maxConsumers=5,Rqst.maxConsumers=5).

Changed values of example 
(name=JMS_http://sap.com/xi/XI/System, messageListener=localejbs/AFWListener, exceptionListener=localejbs/AFWListener, pollInterval=60000, pollAttempts=60, Send.maxConsumers=7, Recv.maxConsumers=7, Call.maxConsumers=7, Rqst.maxConsumers=7).

 

5) 데이터를 전송할 때 한번에 많은 양을 처리하지 않고 일정 시간을 두고 몇건씩 처리할 수 있도록 Sender채널로 설정되어있는 타 시스템에서 제어를 한다.

 

6) Reciver Channel에 연결된 Database에 동시에 접속할 수 있는 Max_connection 값을 늘려달라고 요청한다.

---

 

해당 에러가 발생할 경우 가장 큰 문제점은 에러가 난 채널이 아닌 다른 EO(무작위 처리)로 되어있는 큐에도 영향이 갈 수 있기 때문이다. 그렇기 때문에 최대한 이 문제점이 생기지 않도록 개선을 하는것을 권장한다.

 

해당 내용과는 다른 내용일 수 있는데 메세지 처리 방식에서는 동기(Synchronously)방식의 BE(Best Effect)와 비동기(Asynchronously) 방식의 EO(Exactily Once), EOIO(Exactly Once In Order)가 있다.(참고: ju-hyung.tistory.com/32)

BE 방식의 경우에는 동기화된 방식으로 한번 처리하게 되면 에러가 나든 나지 않든 한번의 처리로 끝나기 때문에 큐에 걸려있지 않는다. 때문에 에러가 나더라도 EAI에서는 재처리가 불가하다.

다만 EO,EOIO의 경우에는 다르다. 비동기방식이기 때문에 에러가 발생하게 되면 다시 처리할 수 있도록 되어있어 큐에 계속 남아있는다. 다른점은 EO의 경우에는 비순차처리로 앞에 전문이 에러로 인해 큐에 걸리더라도 뒤에 전문이 멈추지 않고 처리가 진행이 되지만 EOIO의 경우에는 앞에 전문이 에러로 인해 걸려있으면 뒤에 전문또한 처리되지 않게끔 설계되어 있다.

그렇기 때문에 위와 같이 EO로 되어있는 경우에 병렬로 처리할 수 있는 것도 그 이유이다.

<참고>링크로 두번째로 걸어둔 페이지의 글을 보면 잘 표현되어있다.

https://answers.sap.com/questions/12615717/maximum-concurrency-use.html 화면 참고

Receiver Queue에는 기본적으로 순차적으로 처리가 되지만 백엔드 시스템의 부하를 방지하기 위해 동기화 장벽을 사용합니다. 이러한 내용을 작성하는 이유는 해당 에러가 났을 때 질문이 왜 처음들어온것보다 나중에 들어온게 처리가 더 빨리 되었냐는 질문을 받았기 때문이다. Threads의 동시처리의 경우 위의 그림을 보면 이해하기 쉽다. 동시처리는 말그대로 동시에 한번에 처리되는게 아니라 동시에 처리되는것 처럼 보이도록 시스템의 처리방식에 맞게 여러개의 메세지를 분할해서 처리하는 방식이다. 그렇기 때문에 하나의 메세지를 처리하는데 있어서 에러가 났더라도 다른 메세지는 계속해서 진행 할 수 있는것이다. 때문에 먼저 들어온 메세지보다 나중에 들어온 메세지가 먼저 처리될 경우가 생기는것이다.

 

---

반응형

<참고>

https://blogs.sap.com/2012/12/14/decoding-max-concurrency-poolwaittime-driver-properties-in-jdbc-receiver-adapter-configuration/

Decoding Max Concurrency ,poolWaitTime ,Driver properties in JDBC receiver Adapter Configuration | SAP Blogs

https://answers.sap.com/questions/12615717/maximum-concurrency-use.html

Maximum concurrency use - SAP Q&A

https://answers.sap.com/questions/11033072/how-to-change-messagingsystemqueueparallelismmaxre.html

How to change "messaging.system.queueParallelism.maxReceivers" parameter in XI 710 - SAP Q&A

https://help.sap.com/viewer/6dbe2ddcde6a4087858c533f8032445b/7.31.25/en-US/48cbb47bcea80783e10000000a42189d.html

Properties Related to the Messaging System