Josh McKenzie created CASSANALYTICS-131:
-------------------------------------------
Summary: Move to a singleton SidecarStatePersister managed by the
CdcManager
Key: CASSANALYTICS-131
URL: https://issues.apache.org/jira/browse/CASSANALYTICS-131
Project: Apache Cassandra Analytics
Issue Type: Task
Components: CDC
Reporter: Josh McKenzie
This will touch both {{cassandra-analytics}} and {{cassandra-sidecar}}.
Currently, we create a SidecarStatePersister in CdcManager per Cdc object, then
pass this persister into the Cdc object. We don't otherwise manage their
lifecycle and this disconnect leads to difficulty reasoning about the role of
state persistence during CdcPublisher.restart calls.
The StatePersister API looks to be clearly intended to be Cdc object agnostic:
{code}
void persist(String jobId, int partitionId, @Nullable TokenRange tokenRange,
@NotNull ByteBuffer buf);
{code}
Since the StatePersister's role is to durably checkpoint to the DB when we
reach a certain point, there's no reason to have one of these per Cdc instance.
On top of that, since we create them inside our sidecar in CdcManager, we're
creating a bunch of these instances, not tracking their lifecycle, and handing
them off to other things to use and track (in another library!)
Instead, we should have a single instance managed by the CdcPublisher that Cdc
objects get a reference to and can enqueue state persistence in as they need
to, deferring to higher level abstractions on the right time to durably flush
that persistence layer to the DB and what to do upon flush failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]