[
https://issues.apache.org/jira/browse/CASSANDRA-19101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911699#comment-17911699
]
Stefan Miklosovic edited comment on CASSANDRA-19101 at 1/9/25 11:15 PM:
------------------------------------------------------------------------
for the record, this passed 20k times
CommitLog.discardCompletedSegments method is only ever called in production
code in PostFlush class (inner class of ColumnFamilyStore). I guess what that
does is that if a memtable is flushed to disk, it will go over segments and
discard these which are completed.
CommitLog.discardCompletedSegments is called in CommitlogShutdownTest too as a
mean to get rid of completed segments directly, just like that ...
I think that what happens is that flushing of memtables is done independently
of what we do in the test. So when we flush, randomly, it can create other
commitlogs, so we see more than 2 of them. However, if I force flush every
keyspace before shutting down CommitLog, that will get rid of completed
segments ... and we finally see just 2 of them.
https://github.com/instaclustr/cassandra/commit/5ef1e249cd1a09148b2e71039d35c1d4c96dba37
I am not completely sure if me doing that does not beat the goal of that test.
I see we use byteman like this:
{code}
@Test
@BMRule(name = "Make removing commitlog segments slow",
targetClass = "CommitLogSegment",
targetMethod = "discard",
action = "Thread.sleep(50)")
public void testShutdownWithPendingTasks() throws Exception
{code}
I am not completely sure what we want to achieve by this. I mean ... I can
read, but it just does connect the dots, huh ...
was (Author: smiklosovic):
for the record, this passed 20k times
CommitLog.discardCompletedSegments method is only ever called in production
code in PostFlush class (inner class of ColumnFamilyStore). I guess what that
does is that if a memtable is flushed to disk, it will go over segments and
discard these which are completed.
CommitLog.discardCompletedSegments is called in CommitlogShutdownTest too as a
mean to get rid of completed segments directly, just like that ...
I think that what happens is that flushing of memtables is done independently
of what we do in the test. So when we flush, randomly, it can create other
commitlogs, so we see more than 2 of them. However, if I force flush every
keyspace before shutting down CommitLog, that will get rid of completed
segments ... and we finally see just 2 of them.
https://github.com/instaclustr/cassandra/commit/5ef1e249cd1a09148b2e71039d35c1d4c96dba37
> Test Failure: org.apache.cassandra.db.commitlog.CommitlogShutdownTest failed
> on trunk
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19101
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Test/unit
> Reporter: Jacek Lewandowski
> Assignee: Josh McKenzie
> Priority: Normal
> Fix For: 5.x
>
>
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.cassandra.db.commitlog.CommitlogShutdownTest.testShutdownWithPendingTasks(CommitlogShutdownTest.java:96)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:393)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
> {noformat}
> Manual testing to confirm issues found by CircleCI when testing
> CASSANDRA-18464. Run with Java 11 / IntelliJ
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
