Re: TTL of paxos table
It's just that compaction hasn't occured. TTL works even though GCGS is 0. There's been multiple discussions around this in the past, but we haven't come to a consensus yet though. Some proposals to change compaction strategy, some want to make it customisable. Treating paxos as sub-tables has also come up and the improvements listed in CASSANDRA-13548. TBH we should probably do 13548 and see where that gets us. On 30 August 2018 at 13:14, Yuji Ito wrote: > Hi, > > I wonder why records on the system.paxos table aren't removed, though all > records are updated with TTL (at least 3 hours). > That's because gc_grace_seconds of system.paxos table is always 0 and users > can't change that value of System keyspace! > > Why is the TTL of paxos record invalidated? > Or, I'm misunderstanding? > > Related to: > https://issues.apache.org/jira/browse/CASSANDRA-5451 > https://issues.apache.org/jira/browse/CASSANDRA-13548 > > Thanks, > Yuji >
TTL of paxos table
Hi, I wonder why records on the system.paxos table aren't removed, though all records are updated with TTL (at least 3 hours). That's because gc_grace_seconds of system.paxos table is always 0 and users can't change that value of System keyspace! Why is the TTL of paxos record invalidated? Or, I'm misunderstanding? Related to: https://issues.apache.org/jira/browse/CASSANDRA-5451 https://issues.apache.org/jira/browse/CASSANDRA-13548 Thanks, Yuji
FYI: builds.apache.org is down
https://status.apache.org/ https://lists.apache.org/thread.html/53e9cf7ded15f2e348be2fd36a11fd3aa4dc43462d6aa5a197dbd337@%3Cbuilds.apache.org%3E -- Kind regards, Michael - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Reaper as cassandra-admin
We can wait for a week post Freeze so everyone can participate however we need to decide after that so we can make progress. I am leaning towards piecemeal approach so we can review the code and pick best of all 3 options > On Aug 29, 2018, at 00:26, kurt greaves wrote: > > 2c: There's a lot to think about here, and as Blake already mentioned most > people don't have time to dedicate a lot of thought to this at the moment. > There appear to be a lot of voices missing from the discussion, and I think > it's pretty clear this isn't super tied to the freeze, so maybe we should > leave this discussion until next week when everyone can take part? This > kind of goes for every sidecar related discussion going on at the moment > IMO. > > On 29 August 2018 at 16:44, Vinay Chella > wrote: > >>> I haven’t settled on a position yet (will have more time think about >> things after the 9/1 freeze), but I wanted to point out that the argument >> that something new should be written because an existing project has tech >> debt, and we'll do it the right way this time, is a pretty common software >> engineering mistake. The thing you’re replacing usually needs to have some >> really serious problems to make it worth replacing. >> >> Agreed, Yes, I don’t think we should write everything from the scratch, but >> carry forwarding tech debt (if any) and design decisions which makes new >> features in future difficult to develop is something that we need to >> consider. I second Dinesh’s thought on taking the best parts from available >> projects to move forward with the right solution which works great and >> easily pluggable. >> >> - >> Vinay Chella >> >> >>> On Tue, Aug 28, 2018 at 10:03 PM Mick Semb Wever wrote: >>> >>> the argument that something new should be written because an existing >>> project has tech debt, and we'll do it the right way this time, is a >> pretty >>> common software engineering mistake. The thing you’re replacing usually >>> needs to have some really serious problems to make it worth replacing. >>> >>> >>> Thanks for writing this Blake. I'm no fan of writing from scratch. >> Working >>> with other people's code is the joy of open-source, imho. >>> >>> Reaper is not a big project. None of its java files are large or >>> complicated. >>> This is not the C* codebase we're talking about. >>> >>> It comes with strict code style in place (which the build enforces), unit >>> and integration tests. The tech debt that I think of first is removing >>> stuff that we would no longer want to support if it were inside the >>> Cassandra project. A number of recent refactorings have proved it's an >>> easy codebase to work with. >>> >>> It's also worth noting that Cassandra-4.x adoption is still some away, in >>> which time Reaper will only continue to grow and gain users. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Reaper as cassandra-admin
Agreed here - combining effort and making things pluggable seems like a good solution -- Jeff Jirsa On Aug 28, 2018, at 11:44 PM, Vinay Chella wrote: >> I haven’t settled on a position yet (will have more time think about > things after the 9/1 freeze), but I wanted to point out that the argument > that something new should be written because an existing project has tech > debt, and we'll do it the right way this time, is a pretty common software > engineering mistake. The thing you’re replacing usually needs to have some > really serious problems to make it worth replacing. > > Agreed, Yes, I don’t think we should write everything from the scratch, but > carry forwarding tech debt (if any) and design decisions which makes new > features in future difficult to develop is something that we need to > consider. I second Dinesh’s thought on taking the best parts from available > projects to move forward with the right solution which works great and > easily pluggable. > > - > Vinay Chella > > >> On Tue, Aug 28, 2018 at 10:03 PM Mick Semb Wever wrote: >> >> >>> the argument that something new should be written because an existing >> project has tech debt, and we'll do it the right way this time, is a pretty >> common software engineering mistake. The thing you’re replacing usually >> needs to have some really serious problems to make it worth replacing. >> >> >> Thanks for writing this Blake. I'm no fan of writing from scratch. Working >> with other people's code is the joy of open-source, imho. >> >> Reaper is not a big project. None of its java files are large or >> complicated. >> This is not the C* codebase we're talking about. >> >> It comes with strict code style in place (which the build enforces), unit >> and integration tests. The tech debt that I think of first is removing >> stuff that we would no longer want to support if it were inside the >> Cassandra project. A number of recent refactorings have proved it's an >> easy codebase to work with. >> >> It's also worth noting that Cassandra-4.x adoption is still some away, in >> which time Reaper will only continue to grow and gain users. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Reaper as cassandra-admin
2c: There's a lot to think about here, and as Blake already mentioned most people don't have time to dedicate a lot of thought to this at the moment. There appear to be a lot of voices missing from the discussion, and I think it's pretty clear this isn't super tied to the freeze, so maybe we should leave this discussion until next week when everyone can take part? This kind of goes for every sidecar related discussion going on at the moment IMO. On 29 August 2018 at 16:44, Vinay Chella wrote: > > I haven’t settled on a position yet (will have more time think about > things after the 9/1 freeze), but I wanted to point out that the argument > that something new should be written because an existing project has tech > debt, and we'll do it the right way this time, is a pretty common software > engineering mistake. The thing you’re replacing usually needs to have some > really serious problems to make it worth replacing. > > Agreed, Yes, I don’t think we should write everything from the scratch, but > carry forwarding tech debt (if any) and design decisions which makes new > features in future difficult to develop is something that we need to > consider. I second Dinesh’s thought on taking the best parts from available > projects to move forward with the right solution which works great and > easily pluggable. > > - > Vinay Chella > > > On Tue, Aug 28, 2018 at 10:03 PM Mick Semb Wever wrote: > > > > > > the argument that something new should be written because an existing > > project has tech debt, and we'll do it the right way this time, is a > pretty > > common software engineering mistake. The thing you’re replacing usually > > needs to have some really serious problems to make it worth replacing. > > > > > > Thanks for writing this Blake. I'm no fan of writing from scratch. > Working > > with other people's code is the joy of open-source, imho. > > > > Reaper is not a big project. None of its java files are large or > > complicated. > > This is not the C* codebase we're talking about. > > > > It comes with strict code style in place (which the build enforces), unit > > and integration tests. The tech debt that I think of first is removing > > stuff that we would no longer want to support if it were inside the > > Cassandra project. A number of recent refactorings have proved it's an > > easy codebase to work with. > > > > It's also worth noting that Cassandra-4.x adoption is still some away, in > > which time Reaper will only continue to grow and gain users. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
