-
Bug
-
Resolution: Done
-
Minor
-
2.6.1.Final
-
None
Bug report
What Debezium connector do you use and what version?
sqlserver 2.6.1
What behaviour do you expect?
A single notification is emitted when completed reading from a capture instance.
What behaviour do you see?
There is a small chance the connector doesn't advance and re-reads the same LSN range. This happens under the following conditions:
- a new capture instance has been added in the current LSN range;
- while reading CDC changes, one of existing capture instances disappears.
The disappeared capture instance causes an exception, which is caught and processed in processErrorFromChangeTableQuery. This leads to the current connector iteration to be correctly exited without advancing. On the next iteration, the connector starts from the same LSN as the previous iteration and finds the same new capture instance. Although Set was used to track the list of tables to be removed SqlServerChangeTable doesn't implement hashCode so the same table could be added multiple times to the same set.
Feature request or enhancement
Implementation ideas (optional)
The fix is to use a hash map with capture instance names as keys. Additionally, a synchronization block is needed where the tables are added to the hash map as it happens in a different thread from the one that removes the tables from the hash map.
- relates to
-
DBZ-7043 Emit a notification when completed reading from a capture instance
- Closed
- links to
-
RHEA-2024:139598 Red Hat build of Debezium 2.5.4 release