728x90 반응형 전체 글77 배치에서 socket was closed by server가 터진 후 원인 파악 목적 대개체 작업을 진행 한 후, 여러 배치에서 SQLNonTransientConnectionException이 터졌는데, 문제가 되었던 배치가 있었다. 그러나 해당 배치와 동일한 DB를 사용하는데도 커넥션 문제가 없이 작동하여 DB 상의 문제가 아닌지 혼선을 주었다. 따라서 이에 대한 원인 파악 후, 팀원 분들과 논의해보고 찾아본 것들을 기록하고자 작성한다. 문제 이유 풀 설정이 잡혀있고, quartz 등으로 프로세스가 늘 떠있다가 스케줄링 설정이 돼있는데, 배치서버 혹은 was 서버 중 사용자가 새벽 시간에 아무도 접속하지 않다가 아침에 접속하는 등 query 요청을 장시간 하지 않는 경우에 빈번하게 발생된다. 이런 경우 connection 시간 설정과 DB 연결 시간 설정을 맞춰줘야 한다. 배경 M.. 2024. 3. 30. scdf kafka 리밸런싱 이슈로 둔갑한 레디스 블로킹 이슈 개요 팀 내 DB에 추가된 데이터를 지속적으로 폴링하여 레디스에 캐싱하는 scdf 프로젝트가 있다. 설정된대로 데이터가 노출되지 않는다는 CS가 발생하여 원인을 분석하다 로그를 추적했다. 최근 여러가지 프로젝트 확장으로 인해, 추가되는 스트림 객체가 그만큼 늘었고, 그에 따라 데이터 양 대비 캐싱 처리가 느려졌을 것을 인지하고 있었다. 로그 속 kafka 리밸런싱 이슈 group sync scdf에서 메세지 큐로 사용하던 kafka 쪽에서 폴링이 poll interval ms를 넘기는 이슈로 인해 컨슈머 리밸런싱이 일어났고, offset 커밋이 제대로 되지 않아 과거 데이터를 계속 컨슘했다. 따라서 최신 데이터로 캐싱되는 것이 아니라 과거 데이터로 캐싱되는 이슈가 있었다. 컨슈머 그룹 리밸런싱 완료되었고.. 2024. 3. 30. RabbitMQ 네트워크 파티션 발생으로 인한 데이터 큐잉 중단 이슈 개요팀에서 RabbitMQ에 추가된 데이터를 컨슘하여 레디스에 캐싱하는 scdf 프로젝트가 있었다.설정된대로 데이터가 노출되지 않는다는 CS가 발생하여 원인을 분석하던 중 rabbitMQ 쪽을 확인해봤고, 데이터 큐잉이 중단되어 있었다.큐잉이 중단되었기 때문에, 설정된대로 데이터가 노출되지 않았을 것이다.아래의 명령어를 통해 확인해봤더니,$ rabbitmqctl cluster_status기존에는 RabbitMQ에 구성된 노드는 3개였는데rabbitMQ 클러스터를 구성하던 노드 중 하나에서 네트워크 파티션이 발생했다는 것을 확인했다.그리고, 또 다른 노드는 rabbitMQ 클러스터 구성에서 탈퇴되었음을 확인했다.이것이 데이터 큐잉 중단과 관련이 있을 거 같아서 추적해봤다.이슈 1: s.. 2024. 3. 30. [RabbitMQ] RabbitMQ ACK Producer Confirm Producer가 RabbitMQ에게 Message를 전송한 후 RabbitMQ로부터 ACK를 받는 기법 Producer는 설정에 따라 RabbitMQ의 ACK를 기다리지 않을 수도 있음. Producer는 RabbitMQ에게 메세지 전송 RabbitMQ는 수신한 메세지를 Exchange에게 전달 Exchange는 Exchange에 설정된 규칙에 따라 수신한 메세지를 버리거나, Queue 혹은 다른 Exchange에게 전달한다. (1) Queue가 Mirroring되어 있을 경우 메세지는 미러링된 모든 큐에 복사된 이후 producer에게 ACK를 보낸다. (2) 그렇지 않은 경우 메세지가 버려진다면 RabbitMQ는 Producer에게 바로 ACK를 전송한다. 메세지가 큐.. 2022. 5. 17. 이전 1 2 3 4 5 6 ··· 20 다음 728x90 반응형
