Spectrum SRMArchiverLog error Could not capture range of thresholds to process
search cancel

Spectrum SRMArchiverLog error Could not capture range of thresholds to process

book

Article ID: 424513

calendar_today

Updated On:

Products

Network Observability Spectrum

Issue/Introduction

The following error is recorded in the $SPECROOT/tomcat/logs/stdout.log file after applying the steps from SRM records purge is not working as configured - archive event_staging:

Dec 30, 2025 03:00:01.068 (CrystalOnlyUserManager) (SRMArchiverLog) - (ERROR) - Could not capture range of thresholds to process.

Caused by: org.springframework.dao.TransientDataAccessResourceException: StatementCallback; SQL [SELECT '2023-01-13 00:00:00.0'  + INTERVAL 1 DAY, '2023-01-13 00:00:00.0'  + INTERVAL 2 DAY, '2023-01-13 00:00:00.0'  + INTERVAL 3 DAY, '2023-01-13 00:00:00.0'  + INTERVAL 4 DAY, '2023-01-13 00:00:00.0'  + INTERVAL 5 DAY, '2023-01-13 00:00:00.0'  + INTERVAL 6 DAY, '2023-01-13 00:00:00.0'  + INTERVAL 7 DAY, '2023-01-13

Environment

DX NetOps Spectrum 25.4.x

Cause

The error java.sql.SQLException: HOUR_OF_DAY: 0 -> 1 indicates that the application is trying to create a java.sql.Timestamp for a time that does not exist in the JVM's current timezone. This typically happens during a Daylight Saving Time (DST) transition where the clock jumps forward (e.g., from 00:00:00 directly to 01:00:00), making "00:00:00" an invalid time for that specific date.Our SRM code executes a SQL query to generate a list of timestamps by adding days to the lastThresholdProcessed. The SQL query (SELECT ... + INTERVAL X DAY) returns timestamps that are likely at midnight (00:00:00). When the JDBC driver tries to read these timestamps, it fails for the date of the DST transition. The fix is to calculate these catch-up timestamps in Java instead of using a SQL query. Java's Calendar class handles DST transitions gracefully (e.g., it will automatically adjust 00:00:00 to 01:00:00 if the former is

Resolution

Engineering has identified a general fix for this issue which should work well for both DST Timestamps and non-DST as well.

We will make the fix available in the upcoming main release 25.4.5.0.