Task 2-2: Test JMSListenerRecoveryScheduler
Phase: 2 - Stability Priority: Medium Depends on: Không có Reference:
docs/BountyHunter-Backend/details/feature-batch-async-processing/SPEC.md
Background
JMSListenerRecoveryScheduler tự động khôi phục listener bị down, nhưng chưa có test nào verify nó hoạt động đúng.
Tasks
Verify implementation
- [ ] Đọc source
JMSListenerRecoverySchedulerđể confirm logic: - Lấy tất cả containers từ
JmsListenerEndpointRegistry - Check
isRunning()cho từng container - Nếu không running → gọi
start()
Integration test
DI Note: In the test class, inject
JmsListenerEndpointRegistryandJMSListenerRecoverySchedulervia@Autowired(Spring integration test context).@Autowired private JmsListenerEndpointRegistry registry; @Autowired private JMSListenerRecoveryScheduler recoveryScheduler;
- [ ] Force stop 1 listener container bằng cách inject
JmsListenerEndpointRegistryvà gọistop(id) - [ ] Wait for recovery scheduler tick
- [ ] Verify listener được restart (log:
Recovered listener) - [ ] Send message tới queue đó → listener nhận bình thường
Negative test
- [ ] Tất cả listeners running → scheduler không log recovery
- [ ] Scheduler không accidentally stop healthy listeners
Recovery frequency
- [ ] Verify interval của scheduler (nên nhỏ hơn message TTL để không mất messages)
Verification / Acceptance Criteria
- [ ]
JMSListenerRecoveryTestcompiles and passes in CI - [ ] Recovery test: after forcing a container stop, the scheduler detects and restarts it within one tick interval; log contains
Recovered listenerwith the container ID - [ ] No false positive: when all listeners are running, no
Recovered listenerlog line is emitted during scheduler tick - [ ] No false negative / accidental stop: healthy running containers remain
isRunning() == trueafter scheduler executes - [ ] Recovery interval is documented and confirmed to be shorter than the shortest message TTL across all queues
Files
batch/jms/JMSListenerRecoveryScheduler.java(read only)- Test class:
batch/test/.../JMSListenerRecoveryTest.java(new)