jmckenzie-dev commented on code in PR #347:
URL: https://github.com/apache/cassandra-sidecar/pull/347#discussion_r3244112481
##########
server/src/main/java/org/apache/cassandra/sidecar/cdc/CachingSchemaStore.java:
##########
@@ -132,8 +146,15 @@ private void configureSidecarServerEventListeners()
return v;
});
}
- loadPublisher();
- publishSchemas();
+ try
+ {
+ loadPublisher();
+ publishSchemas();
+ }
+ catch (Exception e)
+ {
+ LOGGER.error("Failed to publish schemas to Kafka during
initialization, CDC will still start", e);
Review Comment:
So 2 things:
1. Why do we not warm up the cache or process anything before there's a
schema change? The flow of:
a. start process
b. be non-functional until
c. a schema change hits
d. THEN you warm up your cache and notify
Is surprising to me. I would expect we had 2 flows.
### Startup flow:
- Start process
- Preload / cache / get things ready w/what we know
- Notify about cache warmup
### Schema change flow
- Reload / recache things w/the new data
- Notify about cache warmup
Though writing it out there, "cache warmup" seems like the wrong name vs.
"CACHE_READY" or something.
And 2: An exponential backoff on retry that terminates at N attempts sounds
like a great idea for what to do when we can't publish schemas. Ultimately, if
we can't publish schemas I don't _think_ we should startup CDC, since any
subsequent schema changes will break things and by definition be some distance
away from the source of the breakage.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
