[#138] fix. 크론 스케줄러가 spring.task.scheduling 설정을 따르게 한다

[howudong]

배경

application.yml의 spring.task.scheduling.pool.size: 3(#211)이 적용된 적이 없었다. 이 값은 Boot 자동설정의 taskScheduler에만 쓰이는데, WebSocket 설정이 TaskScheduler 빈(messageBrokerTaskScheduler, webSocketHeartbeatScheduler)을 등록해서 자동설정이 꺼진다. 그러면 TaskSchedulerRouter가 스레드 하나짜리 기본 실행기로 크론을 돌린다. 시작 로그에 "More than one TaskScheduler bean exists ..."가 남는다.

그래서 #211이 막으려던 "월 00:00 퀴즈 오픈 알림이 도는 동안 매분 sweep이 밀린다"가 그대로 남아 있었다.

이슈 #138은 처음에 "크론이 하트비트 스레드를 막는다"로 쓰였지만 전제가 틀렸다. 크론은 하트비트와 다른 스레드에서 돌고 있었다. 정정 내용은 이슈 댓글에 적었다.

변경

SchedulingConfig가 SchedulingConfigurer를 구현하고, Boot의 ThreadPoolTaskSchedulerBuilder로 크론 스케줄러를 만든다. 자동설정과 같은 빌더라 spring.task.scheduling 설정(스레드 수·이름 등)이 그대로 적용된다. 스레드 수는 yml에서만 정한다.

	크론 스레드
이전	pool-N-thread-1 1개 (yml 무시)
이후	scheduling-1~3 3개 (yml 적용)

동작 변화

서로 다른 크론이 처음으로 동시에 돈다. 같은 크론은 이전처럼 자기 자신과 겹치지 않는다. 같은 시각에 걸리는 조합은 모두 매분 sweep + 다른 크론 하나다.

버그 리뷰로 본 동시 실행 영향:

• 알림 중복 없음: 알림 유형마다 그 유형을 남기는 크론이 하나뿐이다
• 데드락 없음: 크론 중 행 잠금은 sweep의 방 마감뿐이다. 목 05:00 매칭(이번 주 그룹)과 sweep의 미응답 거절(지난주 그룹)은 대상이 다르다
• 커넥션: 크론 스레드당 많아야 1개라 Hikari 10개 중 최대 3개
• 남은 의심: notification.created_at 인덱스가 없어 04:10 알림 정리 DELETE가 끝날 때까지 같은 시각 sweep의 알림 INSERT가 기다릴 수 있다. 잠금 대기 한도(50초)를 넘길 때만 피해가 있고, 04:10은 방 개방·마감 시각이 아니다

확인

• 로컬 bootRun: jstack에 scheduling-1~3, ws-heartbeat-1이 따로 있고 sweep SQL이 scheduling-1에서 찍힘. "More than one TaskScheduler" 로그 사라짐
• 수정 전 코드로도 띄워서 크론이 pool-3-thread-1 하나에서 도는 것을 확인
• ./gradlew :api:check 통과 (테스트 1176개)
• SchedulingConfig는 test 프로필에서 꺼져 있어 자동 테스트로는 검증되지 않는다

후속

• 탈퇴 회원 완전 삭제 크론이 자기 호출이라 @Transactional이 적용되지 않는다 #267 탈퇴 회원 완전 삭제 크론의 트랜잭션 누락 (리뷰 중 발견, 이번 변경과 무관)

스키마·공개 API 변경 없음.

Closes #138

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud