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]

Reply via email to