인터페이스 패턴,환경,네트웍 등 상황에 따라 동일한 인터페이스 패턴이지만 다른 증상과 에러가 발생되는 경우가 있는것 같습니다.
이번에러는 네트웍 문제라 추측은 하지만 원인은 아직 몰라서 만약 PO문제이지 않을까라는 가정하에 확인하는 내용을 담고 있습니다.
타임아웃 발생 인터페이스 현상정리
- 1초에 여러번 호출되는 소스가 하나고 타겟이 여러개인 인터페이스
- REST to JDBC 동기 인터페이스
- Rest Sender 채널 별로 타임아웃 설정되어있음
- 여러 인터페이스 일부분만 타임아웃이 확인
- Audit로그에서는 'JDBC Adapter Receiver Channel [채널명] : Processing started...' 이후에 'Synchronous timeout exceeded' 발생
- 로그뷰어에서도 타임아웃 원인 찾기 힘듬
- 유독 특정시간에 타임아웃이 발생되는것 같음
로그뷰어 로그
SourceName: /Applicatons/ExchangeInfrastructure/AdapterFramework/SOAPI_Messaging_System
Application: sap.com/com.sap.aii.af.app
Location: com.sap.engine.messaging.impl.util.auditlog.AuditLogManagerw
ThreadName: Thread[HTTP Worker...
CSNComponent: BC-XI-CON-MSG
Text: Synchronous timeout exceeded
컴포넌트와 에러내용을 가지고 노츠를 검색해보니 3개의결과를 확인하였고 그중 '2211696 - "Synchronous Timeout Exceeded" error in SAP Process Integration' 노츠의 한부분을 직역해보면
메시지 시간 초과가 발생하는 이유는 무언인가요?
시스템에 메시지 부하가 많고 메시지를 한 번에 처리 할 수 있는 리소스(어댑터 스레드)가 충분하지 않은 경우
따라서 새 메시지는 어댑터 스레드가 비어 있을 때까지 기다려야 하며, 경우에 따라 이 대기 시간이 메시지 시간 초과만큼 길어질 수 있으므로 메시지 시간 초과가 트리거 되어 메시지가 실패 될수 있습니다.
내용을 이해해보면 Receiver Adapter가 호출 후에 스레드를 기다리는 시간이 타임아웃 설정시간보다 초과하면 저런에러가 발생될수 있다? 라고 이해를 했는데
Message Monitoring의 Audit로그를 보면 Receiver어댑터를 호출 후에 타임아웃 난거라 타겟시스템 DB에서 응답을 못줘서 타임아웃 난거라 이해할수 밖에 없는 현상이고 다만 서로다른 어댑터(DB정보 서로다름)에서 발생된거라 네트웍 문제일수도 있다는 생각으로 변화가 되었습니다.
정말 SAP PO내부문제이지 않을까?
스레드 리소스가 부족할까?
PO내의 메시지 큐는 어댑터별로 4개(동기2개,비동기2개)가있는것으로 확인됩니다.
Call: Sync Outobund
Recv: Async Inbound
Rqst: Sync Inbound
Send: Async Outbound
출처: [XI/PI] Adapter 별 Threads 개수 설정
PO서버와 노드개수에 따라 설정된 스레드 개수로 동시처리할수 있는 메시지는 다를수 있으나 메일 발생되는 에러도 아니고 한거당 처리시간도 1초내로 보면 현재 스레드 리소스로는 처리가 가능하다는 생각도 들긴하지만 해당 시간에 발생되는 인터페이스가 이것밖에 없으니 가끔 원인은 이외의 곳에서 확인되는 경우도 있던것 같습니다.
그리고 전에 블로그에 큐관련 글이 있는것을 보았는데
동기 메시지 처리할때 SI > BI > VI > MS 후에
- Put_In_Disp_Queue: 디스패처 큐에 메시지 넣기
- Wait_In_Disp_Queue: 디스패처 큐의 대기시간
- Put_In_Queue: 메시지를 처리 큐에 적재
- Wait_In_Queue: 처리 대기열의 대기시간
이후에 메시지 상태 업데이트하고 AM > SO > VO > AT순으로 실행이 되고 동기니깐 다시 역순으로 실행되는것으로 이해했습니다.
Audit로그에서 보이는 큐관련 내용을 보면
메시지타입이 CALL일때
- Application attempting to send an XI message synchronously using connection REST_http://sap.com/xiXI/System
- Trying to put the message into call queue
- Message successfully put into the queue
- Message retrieved from call queue
- Meessage status set to DLNG
- Executing Request Mapping...
- Delivering to channel: [채널명]
- Message was successfully transmitted to endpoint
using connection REST_http://sap.com/xi/XI/System - Message status set to DLVD
- Application sent message synchronously using connection REST_http://sap.com/xi/XI/System. Returning to application
정확하지는 않지만 이해를 해보면
디스패처 큐나 대기열에 메시지를 넣기위해 스레드를 연결해서 가 큐처리 이전과 후에 메시지 상태를 변경
위내용으로 보면 'call queue'라는 건 동기식 스레드(큐)인 'SystemCall'로 이해가 됩니다.
메시지 타입이 Rtrn일때
- Executing Response Mapping...
- Application attempting to send an XI message asynchronously using connection JDBC_http://sap.com/xi/XI/System
- Trying to put the message into the send queue
- Message status set to DLVD
- The application sent the meesage asynchronously using connection JDBC_http://sap.com/xi/XI/System. Returning to application
리턴 Audit 로그에서 이외였던게 REST스레드나 큐를 사용할줄 알았는데 'send queue'를 보아 JDBC의 비동기 'SystemSend' 스레드(큐)를 사용하는것으로 이해가 됩니다.
만약 새벽에 비동기 JDBC_Sender어댑터의 스케쥴,배치가 실행이 많아서 JDBC대기열의 시간초과? 뭐.. 이런 생각도 했지만 로그레벨을 조정해서 모든로그를 보거나 테스트를 해본게 아니기때문에 현재는 그럴가능성은 없다는 생각입니다.
댓글 없음:
댓글 쓰기