Skip to content

Comments

Make changelog polling signals pluggable#2

Closed
kevinconway wants to merge 13 commits intomainfrom
signals
Closed

Make changelog polling signals pluggable#2
kevinconway wants to merge 13 commits intomainfrom
signals

Conversation

@kevinconway
Copy link
Owner

Test failures in some environments suggested that either the file watcher or the signal handling code is fallible in some way that results in the system not polling after the SQLite file changes. To account for this, I've refactored the file watcher into a pluggable interface and added a time based polling implementation to use alongside file watching or in environments where file watching isn't possible.

Additionally, this change adds a suite of benchmarks to measure the overhead of the triggers on insert, update, and delete operations. A summary of the results is included in the README.

These were previously calculated where needed but they ended up being
needed in multiple locations.
The current CDC engine implementation embeds the file watching logic.
This change extracts that logic, along with some alternative
implementations, into a new interface that can be used by any engine
implementation.
This fixes a timing condition where the watch loop of a signal could
still be waiting to write an event when the channel is closed. This
condition resulted in a panic due to the closed channel write. Now, the
channels are never closed but the goroutines are guaranteed to exit once
the signals are stopped by selecting all writes along with reads of the
closer channel.
The trigger CDC engine implementation previously embedded the FS watcher
logic. This is factored out and replaced with customizable signals. The
default signal is now set to a combination of the FS watcher and a timer
after discovering that some resource constrained or containerized
environments don't always emit FS events consistently. I didn't get to
an exact root cause but the tests would intermittently pass or fail on
some, but not all, machines.
The bootstrap events are useful for systems that accumulate state based
on the CDC stream and then later encounter a critical fault. The
standard recovery is to bootstrap but bootstrap records are otherwise
identical to INSERT change records. This leaves the consuming system
with no way of knowing whether any currently persisted state is invalid
such as a record that was deleted but the system failed to correctly
process the delete. In this case, a bootstrap event can be a signal to
purge any persisted state relevant to a table before handling the
bootstrap events.
The CLI for setup/teardown of triggers is now a different exectuable
from the CLI for processing changes. This is to help limit the scope of
the CLI when running change processing as a side-car process to some
other system that stores data in SQLite.
@kevinconway kevinconway closed this Jan 7, 2025
@kevinconway kevinconway deleted the signals branch January 7, 2025 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant