The primary reason I avoided integrating a daemon into the Cassandra process was the increase in heap pressure and further muddying of the profile of heap usage. We've already seen that mixing read/write, compaction, streaming, and repair in the same JVM causes a nasty mix of allocation patterns that are pretty much impossible to optimize for, so furthering that problem wasn't on my ToDo list.
Having a tool in-tree? Sure. But I'd strongly recommend against having it be in-process. On Thu, Feb 9, 2017 at 7:19 PM, Jay Zhuang <jay.zhu...@yahoo.com.invalid> wrote: > No. It's going to have Cassandra to manage the CDC logs, instead of having > another daemon process to handle that. > > Here is CDC design JIRA: CASSANDRA-8844. The pain point is to develop and > manage the daemon. If they're integrated, it's going to be easier to manage > and monitor that. > > Thanks, > Jay > > > On 2/9/17 3:57 PM, Dikang Gu wrote: > >> Is it for testing purpose? >> >> On Thu, Feb 9, 2017 at 3:54 PM, Jay Zhuang <jay.zhu...@yahoo.com.invalid> >> wrote: >> >> Hi, >>> >>> To process the CDC commitLogs, it requires a separate Daemon process, >>> Carl >>> has a Daemon example here: CASSANDRA-11575. >>> >>> Does it make sense to integrate it into Cassandra? So the user doesn't >>> have to manage another JVM on the same box. Then provide an ITrigger like >>> interface (https://github.com/apache/cassandra/blob/trunk/src/java/org >>> /apache/cassandra/triggers/ITrigger.java#L49) to process the data. >>> >>> Or maybe provide an interface option to handle the CDC commitLog in >>> SegmentManager(https://github.com/apache/cassandra/blob/trun >>> k/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmen >>> tManagerCDC.java#L68). >>> >>> Any comments? If it make sense, I could create a JIRA for that. >>> >>> Thanks, >>> Jay >>> >>> >> >> >>
