-
Bug
-
Resolution: Done
-
Major
-
3.4.0.Alpha2
-
None
Bug report
What Debezium connector do you use and what version?
3.4 for DB2 LUW/Z
What is the connector configuration?
The pertinent part is that there is signaling on source and kafka enabled.
What is the captured database version and mode of deployment?
Local Container of DB2 LUW.
What behavior do you expect?
Upon a Kafka signal for a blocking snapshot being received, it should be processed immediately, whether or not there are CDC events being processed by the connector.
What behavior do you see?
When the database is idle and the streaming event source loop is running, the paused code that coordinates the ability of a blocking snapshot isn't reached because on no changes found, a short metronome and then a continue of the main loop are taken. Therefore, the signal isn't processed until there is a change in the database.
This is not observed via the source signal path, as that itself is a change in the database, and it does not take this shorter codepath.
Do you see the same behaviour using the latest released Debezium version?
Yes.
Do you have the connector logs, ideally from start till finish?
No. This is only observed with a debugger.
How to reproduce the issue using our tutorial deployment?
Set up source and Kafka signalling, and with an idle database, send a Kafka signal for a blocking snapshot.
Implementation ideas (optional)
I have the code to fix this.