[jira] [Comment Edited] (CASSANDRA-9779) Append-only optimization
[
https://issues.apache.org/jira/browse/CASSANDRA-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15143857#comment-15143857
]
Caleb William Rackliffe edited comment on CASSANDRA-9779 at 2/12/16 1:35 AM:
-
Would it make sense to reject (or at least allow rejection) for the case of an
INSERT with only a partial row?
was (Author: maedhroz):
Would it make sense to reject (or at least allow rejection) for the case of an
INSERT with only partial row?
> Append-only optimization
>
>
> Key: CASSANDRA-9779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9779
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
>Reporter: Jonathan Ellis
> Fix For: 3.x
>
>
> Many common workloads are append-only: that is, they insert new rows but do
> not update existing ones. However, Cassandra has no way to infer this and so
> it must treat all tables as if they may experience updates in the future.
> If we added syntax to tell Cassandra about this ({{WITH INSERTS ONLY}} for
> instance) then we could do a number of optimizations:
> - Compaction would only need to worry about defragmenting partitions, not
> rows. We could default to DTCS or similar.
> - CollationController could stop scanning sstables as soon as it finds a
> matching row
> - Most importantly, materialized views wouldn't need to worry about deleting
> prior values, which would eliminate the majority of the MV overhead
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9779) Append-only optimization
[
https://issues.apache.org/jira/browse/CASSANDRA-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15143857#comment-15143857
]
Caleb William Rackliffe commented on CASSANDRA-9779:
Would it make sense to reject (or at least allow rejection) for the case of an
INSERT with only partial row?
> Append-only optimization
>
>
> Key: CASSANDRA-9779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9779
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
>Reporter: Jonathan Ellis
> Fix For: 3.x
>
>
> Many common workloads are append-only: that is, they insert new rows but do
> not update existing ones. However, Cassandra has no way to infer this and so
> it must treat all tables as if they may experience updates in the future.
> If we added syntax to tell Cassandra about this ({{WITH INSERTS ONLY}} for
> instance) then we could do a number of optimizations:
> - Compaction would only need to worry about defragmenting partitions, not
> rows. We could default to DTCS or similar.
> - CollationController could stop scanning sstables as soon as it finds a
> matching row
> - Most importantly, materialized views wouldn't need to worry about deleting
> prior values, which would eliminate the majority of the MV overhead
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11116) Gossiper#isEnabled is not thread safe
[
https://issues.apache.org/jira/browse/CASSANDRA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133359#comment-15133359
]
Caleb William Rackliffe edited comment on CASSANDRA-6 at 2/5/16 5:54 PM:
-
+1
was (Author: maedhroz):
+1 FWIW
> Gossiper#isEnabled is not thread safe
> -
>
> Key: CASSANDRA-6
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Sergio Bossa
>Assignee: Ariel Weisberg
>Priority: Critical
>
> {{Gossiper#isEnabled()}} relies on the presence of {{scheduledGossipTask}},
> which is not final nor volatile. As a consequence, when such method is called
> on a different thread, i.e. the gossip stage thread, it is sometimes detected
> as not enabled, causing particularly obscure failures.
> This is shown by the following logs. First the gossiper is started:
> {noformat}
> 1 TRACE [Thread-29] 2016-02-03 19:21:31,232 Gossiper.java (line 1310) gossip
> started with generation 1454527291
> {noformat}
> Then the same node misses a gossip message because the gossiper is seen as
> disabled:
> {noformat}
> 1 TRACE [GossipStage:1] 2016-02-03 19:21:32,016
> GossipDigestSynVerbHandler.java (line 44) Ignoring GossipDigestSynMessage
> because gossip is disabled
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11116) Gossiper#isEnabled is not thread safe
[
https://issues.apache.org/jira/browse/CASSANDRA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133359#comment-15133359
]
Caleb William Rackliffe commented on CASSANDRA-6:
-
+1 FWIW
> Gossiper#isEnabled is not thread safe
> -
>
> Key: CASSANDRA-6
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sergio Bossa
>Assignee: Ariel Weisberg
>Priority: Critical
>
> {{Gossiper#isEnabled()}} relies on the presence of {{scheduledGossipTask}},
> which is not final nor volatile. As a consequence, when such method is called
> on a different thread, i.e. the gossip stage thread, it is sometimes detected
> as not enabled, causing particularly obscure failures.
> This is shown by the following logs. First the gossiper is started:
> {noformat}
> 1 TRACE [Thread-29] 2016-02-03 19:21:31,232 Gossiper.java (line 1310) gossip
> started with generation 1454527291
> {noformat}
> Then the same node misses a gossip message because the gossiper is seen as
> disabled:
> {noformat}
> 1 TRACE [GossipStage:1] 2016-02-03 19:21:32,016
> GossipDigestSynVerbHandler.java (line 44) Ignoring GossipDigestSynMessage
> because gossip is disabled
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
Caleb William Rackliffe created CASSANDRA-11062:
---
Summary: BatchlogManager May Attempt to Flush Hints After
HintsService is Shutdown
Key: CASSANDRA-11062
URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
Project: Cassandra
Issue Type: Bug
Reporter: Caleb William Rackliffe
Priority: Minor
Fix For: 3.0.x
{{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
call {{replayFailedBatches()}} after drain has instructed both it and the
{{HintsService}} to shut down. When this happens, we get an exception when that
tries to submit a task to the executor in {{HintsWriteExecutor}}:
{noformat}
ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
Exception in thread Thread[BatchlogTasks:1,5,main]
java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
down
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
~[cassandra-all-3.0.1.816.jar:3.0.1.816]
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
[na:1.8.0_65]
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
[na:1.8.0_65]
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
~[cassandra-all-3.0.1.816.jar:3.0.1.816]
at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
~[na:1.8.0_65]
at
org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
~[cassandra-all-3.0.1.816.jar:3.0.1.816]
at
org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
~[cassandra-all-3.0.1.816.jar:3.0.1.816]
at
org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
~[cassandra-all-3.0.1.816.jar:3.0.1.816]
at
org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
~[cassandra-all-3.0.1.816.jar:3.0.1.816]
at
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
~[cassandra-all-3.0.1.816.jar:3.0.1.816]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_65]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[na:1.8.0_65]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_65]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0_65]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_65]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_65]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-11062:
Attachment: 11062-3.0.txt
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
>Reporter: Caleb William Rackliffe
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15113467#comment-15113467
]
Caleb William Rackliffe commented on CASSANDRA-11062:
-
I've submitted a little patch that configures {{BatchlogManager}} to stop
executing delayed tasks on shutdown.
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
>Reporter: Caleb William Rackliffe
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038807#comment-15038807
]
Caleb William Rackliffe commented on CASSANDRA-7466:
Given the way I'm seeing {{cassandra-2.1}} behave, I think this ticket is
invalid. I can still only run groups of tests from IDEA in a run configuration
with class-level forking, but the failures appear to be different than I had
originally reported here. In any case, I don't have time to track them down at
the moment.
The new failures are a hodgepodge of things like:
{noformat}
FSWriteError in
build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:135)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:381)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at org.apache.cassandra.SchemaLoader.cleanup(SchemaLoader.java:454)
at
org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:429)
at org.apache.cassandra.SchemaLoader.prepareServer(SchemaLoader.java:85)
at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:61)
at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.junit.runners.Suite.runChild(Suite.java:117)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.nio.file.NoSuchFileException:
build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1079)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:131)
{noformat}
...and...
{noformat}
org.apache.cassandra.exceptions.AlreadyExistsException: Cannot add existing
keyspace "Keyspace1"
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:228)
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:220)
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:215)
at
[jira] [Updated] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7466:
---
Attachment: (was: trunk-7466.txt)
> Unit Test Suite Breaks when Run in a Single JVM
> ---
>
> Key: CASSANDRA-7466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
> Environment: MacOS 10.9.3, IntelliJ IDEA 13.1.3, Java 1.7.0_51
>Reporter: Caleb William Rackliffe
>Assignee: Caleb William Rackliffe
>Priority: Minor
> Labels: unit-test
>
> Note: Instead of picking a version below, I'll simply note that I'm on
> {{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
> I pulled down the source and followed
> http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an
> IDEA project. Everything in the tutorial works as it should, but when I tried
> to run the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed
> a couple tests in, complaining that it couldn't find the {{system}} keyspace
> in {{build/test/cassandra/data}}.
> tl;dr static initialization makes it hard to run the unit tests in the same
> JVM
> The full story is that...
> 1.) When the first test in the suite is run, the {{system}} keyspace is
> created on disk and in the in-memory schema.
> 2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
> {{system}} keyspace directory (among other things) in {{defineSchema()}} with
> a call to {{SchemaLoader.prepareServer()}}.
> 3.) While these tests create the keyspaces they require, they do *not*
> recreate the system keyspace, and so they fail when they force a compaction
> or perform any other action that goes looking for it.
> You can run the suite with IDEA's class/method forking, and you get a little
> bit better results, but it still seems like this shouldn't be necessary.
> I guess there are two ways to fix it:
> 1.) We rebuild the system keyspace before for each test.
> 2.) We leave the system keyspace alone.
> I took a hack at #1 in the attached patch. It looks like it to fixes this
> specific problem, but I'm not super-believable in this codebase yet...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7466:
---
Environment: MacOS 10.9.3, IntelliJ IDEA 14, Java 1.8.0_65 (was: MacOS
10.9.3, IntelliJ IDEA 13.1.3, Java 1.7.0_51)
Reproduced In: 2.1.11
Description:
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed a couple
tests in, complaining that it couldn't find the {{system}} keyspace in
{{build/test/cassandra/data}}.
tl;dr static initialization makes it hard to run the unit tests in the same JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is created
on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with a
call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not* recreate
the system keyspace, and so they fail when they force a compaction or perform
any other action that goes looking for it.
You can run the suite with IDEA's class/method forking, and you get a little
bit better results, but it still seems like this shouldn't be necessary.
I guess there are two ways to fix it:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
was:
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed a couple
tests in, complaining that it couldn't find the {{system}} keyspace in
{{build/test/cassandra/data}}.
tl;dr static initialization makes it hard to run the unit tests in the same JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is created
on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with a
call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not* recreate
the system keyspace, and so they fail when they force a compaction or perform
any other action that goes looking for it.
You can run the suite with IDEA's class/method forking, and you get a little
bit better results, but it still seems like this shouldn't be necessary.
I guess there are two ways to fix it:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
> Unit Test Suite Breaks when Run in a Single JVM
> ---
>
> Key: CASSANDRA-7466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
> Environment: MacOS 10.9.3, IntelliJ IDEA 14, Java 1.8.0_65
>Reporter: Caleb William Rackliffe
>Assignee: Caleb William Rackliffe
>Priority: Minor
> Labels: unit-test
>
> I pulled down the source and followed
> http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an
> IDEA project. Everything in the tutorial works as it should, but when I tried
> to run the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed
> a couple tests in, complaining that it couldn't find the {{system}} keyspace
> in {{build/test/cassandra/data}}.
> tl;dr static initialization makes it hard to run the unit tests in the same
> JVM
> The full story is that...
> 1.) When the first test in the suite is run, the {{system}} keyspace is
> created on disk and in the in-memory schema.
> 2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
> {{system}} keyspace directory (among other things) in {{defineSchema()}} with
> a call to {{SchemaLoader.prepareServer()}}.
> 3.) While these tests create the keyspaces they require, they do *not*
> recreate the system keyspace, and so they fail when they force a compaction
> or perform any other action
[jira] [Updated] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7466:
---
Description:
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite fails a few
tests in, complaining variously about a hodgepodge of things like:
{noformat}
FSWriteError in
build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:135)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:381)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at org.apache.cassandra.SchemaLoader.cleanup(SchemaLoader.java:454)
at
org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:429)
at org.apache.cassandra.SchemaLoader.prepareServer(SchemaLoader.java:85)
at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:61)
at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.junit.runners.Suite.runChild(Suite.java:117)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.nio.file.NoSuchFileException:
build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1079)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:131)
{noformat}
...and...
{noformat}
org.apache.cassandra.exceptions.AlreadyExistsException: Cannot add existing
keyspace "Keyspace1"
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:228)
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:220)
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:215)
at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:70)
at
[jira] [Issue Comment Deleted] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7466:
---
Comment: was deleted
(was: Given the way I'm seeing {{cassandra-2.1}} behave, I think this ticket is
invalid. I can still only run groups of tests from IDEA in a run configuration
with class-level forking, but the failures appear to be different than I had
originally reported here. In any case, I don't have time to track them down at
the moment.
The new failures are a hodgepodge of things like:
{noformat}
FSWriteError in
build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:135)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:381)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
at org.apache.cassandra.SchemaLoader.cleanup(SchemaLoader.java:454)
at
org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:429)
at org.apache.cassandra.SchemaLoader.prepareServer(SchemaLoader.java:85)
at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:61)
at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.junit.runners.Suite.runChild(Suite.java:117)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.nio.file.NoSuchFileException:
build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1079)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:131)
{noformat}
...and...
{noformat}
org.apache.cassandra.exceptions.AlreadyExistsException: Cannot add existing
keyspace "Keyspace1"
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:228)
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:220)
at
org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:215)
at
[jira] [Commented] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038818#comment-15038818
]
Caleb William Rackliffe commented on CASSANDRA-7466:
I've updated the description to reflect what I currently see with a fresh copy
of {{cassandra-2.1}}.
> Unit Test Suite Breaks when Run in a Single JVM
> ---
>
> Key: CASSANDRA-7466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
> Environment: MacOS 10.9.3, IntelliJ IDEA 14, Java 1.8.0_65
>Reporter: Caleb William Rackliffe
>Assignee: Caleb William Rackliffe
>Priority: Minor
> Labels: unit-test
>
> I pulled down the source and followed
> http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an
> IDEA project. Everything in the tutorial works as it should, but when I tried
> to run the unit tests in {{test/unit/org.apache.cassandra}}, the suite fails
> a few tests in, complaining variously about a hodgepodge of things like:
> {noformat}
> FSWriteError in
> build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:135)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:381)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at org.apache.cassandra.SchemaLoader.cleanup(SchemaLoader.java:454)
> at
> org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:429)
> at org.apache.cassandra.SchemaLoader.prepareServer(SchemaLoader.java:85)
> at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:61)
> at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runners.Suite.runChild(Suite.java:117)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at
>
[jira] [Commented] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038822#comment-15038822
]
Caleb William Rackliffe commented on CASSANDRA-7466:
If nobody else can repro this, there's a work-around, even within IDEA, so I'm
fine with throwing it in the "won't fix" bin.
> Unit Test Suite Breaks when Run in a Single JVM
> ---
>
> Key: CASSANDRA-7466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
> Environment: MacOS 10.9.3, IntelliJ IDEA 14, Java 1.8.0_65
>Reporter: Caleb William Rackliffe
>Assignee: Caleb William Rackliffe
>Priority: Minor
> Labels: unit-test
>
> I pulled down the source and followed
> http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an
> IDEA project. Everything in the tutorial works as it should, but when I tried
> to run the unit tests in {{test/unit/org.apache.cassandra}}, the suite fails
> a few tests in, complaining variously about a hodgepodge of things like:
> {noformat}
> FSWriteError in
> build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:135)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:381)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:377)
> at org.apache.cassandra.SchemaLoader.cleanup(SchemaLoader.java:454)
> at
> org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.java:429)
> at org.apache.cassandra.SchemaLoader.prepareServer(SchemaLoader.java:85)
> at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:61)
> at org.apache.cassandra.SchemaLoader.loadSchema(SchemaLoader.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runners.Suite.runChild(Suite.java:117)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/data/cql_test_keyspace/table_1-0fd6a7109a1311e586ed079249e818e0/backups/cql_test_keyspace-table_1.some_index-ka-5-Summary.db
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at
>
[jira] [Created] (CASSANDRA-10739) Surface an InvalidQueryException for CQL Deletes on an Entire Partition Against Specified Columns
Caleb William Rackliffe created CASSANDRA-10739:
---
Summary: Surface an InvalidQueryException for CQL Deletes on an
Entire Partition Against Specified Columns
Key: CASSANDRA-10739
URL: https://issues.apache.org/jira/browse/CASSANDRA-10739
Project: Cassandra
Issue Type: Bug
Components: CQL, Local Write-Read Paths
Reporter: Caleb William Rackliffe
{noformat}
cqlsh:graphs> delete color from composite_pk where k1 = '1' and k2 = '1';
cqlsh:graphs> create table composite_with_clustering(k1 text, k2 text, c1 text,
color text, value float, primary key ((k1, k2), c1));
cqlsh:graphs> insert into composite_with_clustering(k1, k2, c1, value) values
('1','1', '1', 6);
cqlsh:graphs> insert into composite_with_clustering(k1, k2, c1, color) values
('1','1', '2', 'green');
cqlsh:graphs> delete color from composite_with_clustering where k1 = '1' and k2
= '1';
WriteTimeout: code=1100 [Coordinator node timed out waiting for replica nodes'
responses] message="Operation timed out - received only 0 responses."
info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
{noformat}
{{Clustering$Serializer}} clearly doesn't like this:
{noformat}
WARN [SharedPool-Worker-2] 2015-11-19 20:55:15,935
AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-2,5,main]: {}
java.lang.AssertionError: Invalid clustering for the table:
org.apache.cassandra.db.Clustering$2@3157dded
at
org.apache.cassandra.db.Clustering$Serializer.serialize(Clustering.java:136)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at
org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:159)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at
org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at
org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:599)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at
org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:291)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:279)
~[cassandra-all-3.0.0.710.jar:3.0.0.710]
{noformat}
If this isn't supported, there should probably be a more obvious error message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-7480) CommitLogTest.testCommitFailurePolicy_stop Fails w/ NPE
Caleb William Rackliffe created CASSANDRA-7480:
--
Summary: CommitLogTest.testCommitFailurePolicy_stop Fails w/ NPE
Key: CASSANDRA-7480
URL: https://issues.apache.org/jira/browse/CASSANDRA-7480
Project: Cassandra
Issue Type: Bug
Components: Core, Tests
Environment: java version 1.7.0_51
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
Apache Ant(TM) version 1.9.4 compiled on April 29 2014
Mac OS 10.9.3
(Darwin shiftbook.local 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17
23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64)
Reporter: Caleb William Rackliffe
1.) Check out trunk [~commit-tag-bot]
2.) run {{ant test}} from the project root
3.) Observe...
{{
Testsuite: org.apache.cassandra.db.CommitLogTest
Tests run: 14, Failures: 0, Errors: 1, Time elapsed: 1.891 sec
- Standard Output ---
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
- ---
Testcase: testCommitFailurePolicy_stop(org.apache.cassandra.db.CommitLogTest):
Caused an ERROR
null
java.lang.NullPointerException
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:160)
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:155)
at org.apache.cassandra.db.Mutation.add(Mutation.java:176)
at org.apache.cassandra.db.Mutation.add(Mutation.java:186)
at
org.apache.cassandra.db.CommitLogTest.testCommitFailurePolicy_stop(CommitLogTest.java:301)
Test org.apache.cassandra.db.CommitLogTest FAILED
}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7480) CommitLogTest.testCommitFailurePolicy_stop Fails w/ NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7480:
---
Description:
1.) Check out trunk [~commit-tag-bot]
2.) run {{ant test}} from the project root
3.) Observe...
{{Testsuite: org.apache.cassandra.db.CommitLogTest
Tests run: 14, Failures: 0, Errors: 1, Time elapsed: 1.891 sec
- Standard Output ---
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
- ---
Testcase: testCommitFailurePolicy_stop(org.apache.cassandra.db.CommitLogTest):
Caused an ERROR
null
java.lang.NullPointerException
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:160)
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:155)
at org.apache.cassandra.db.Mutation.add(Mutation.java:176)
at org.apache.cassandra.db.Mutation.add(Mutation.java:186)
at
org.apache.cassandra.db.CommitLogTest.testCommitFailurePolicy_stop(CommitLogTest.java:301)
Test org.apache.cassandra.db.CommitLogTest FAILED}}
was:
1.) Check out trunk [~commit-tag-bot]
2.) run {{ant test}} from the project root
3.) Observe...
{{
Testsuite: org.apache.cassandra.db.CommitLogTest
Tests run: 14, Failures: 0, Errors: 1, Time elapsed: 1.891 sec
- Standard Output ---
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
[jira] [Updated] (CASSANDRA-7480) CommitLogTest.testCommitFailurePolicy_stop Fails w/ NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7480:
---
Description:
1.) Check out trunk [~commit-tag-bot]
2.) run {{ant test}} from the project root
3.) Observe...
{noformat}
Testsuite: org.apache.cassandra.db.CommitLogTest
Tests run: 14, Failures: 0, Errors: 1, Time elapsed: 1.891 sec
- Standard Output ---
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
- ---
Testcase: testCommitFailurePolicy_stop(org.apache.cassandra.db.CommitLogTest):
Caused an ERROR
null
java.lang.NullPointerException
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:160)
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:155)
at org.apache.cassandra.db.Mutation.add(Mutation.java:176)
at org.apache.cassandra.db.Mutation.add(Mutation.java:186)
at
org.apache.cassandra.db.CommitLogTest.testCommitFailurePolicy_stop(CommitLogTest.java:301)
Test org.apache.cassandra.db.CommitLogTest FAILED
{noformat}
was:
1.) Check out trunk [~commit-tag-bot]
2.) run {{ant test}} from the project root
3.) Observe...
{{Testsuite: org.apache.cassandra.db.CommitLogTest
Tests run: 14, Failures: 0, Errors: 1, Time elapsed: 1.891 sec
- Standard Output ---
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
[jira] [Updated] (CASSANDRA-7480) CommitLogTest.testCommitFailurePolicy_stop Fails w/ NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7480:
---
Description:
1.) Check out trunk at commit b4a354f3e23b8a23acce70eb911dc58e7f57298c
2.) run {{ant test}} from the project root
3.) Observe...
{noformat}
Testsuite: org.apache.cassandra.db.CommitLogTest
Tests run: 14, Failures: 0, Errors: 1, Time elapsed: 1.891 sec
- Standard Output ---
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-3130605652588023504.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-7416815543415721780.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2864073117299213590.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-908098755907065048.log,
with invalid CRC. The end of segment marker should be zero.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2921422245890190390.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-2938149009734594039.log;
not enough room for a header
- ---
Testcase: testCommitFailurePolicy_stop(org.apache.cassandra.db.CommitLogTest):
Caused an ERROR
null
java.lang.NullPointerException
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:160)
at org.apache.cassandra.db.Mutation.addOrGet(Mutation.java:155)
at org.apache.cassandra.db.Mutation.add(Mutation.java:176)
at org.apache.cassandra.db.Mutation.add(Mutation.java:186)
at
org.apache.cassandra.db.CommitLogTest.testCommitFailurePolicy_stop(CommitLogTest.java:301)
Test org.apache.cassandra.db.CommitLogTest FAILED
{noformat}
was:
1.) Check out trunk [~commit-tag-bot]
2.) run {{ant test}} from the project root
3.) Observe...
{noformat}
Testsuite: org.apache.cassandra.db.CommitLogTest
Tests run: 14, Failures: 0, Errors: 1, Time elapsed: 1.891 sec
- Standard Output ---
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 Couldn't open /proc/stats
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:47 JNA link failure, one or more native method will be unavailable.
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
/var/folders/bg/r0bzhsj50rj2gxntn7ddmgt8gn/T/CommitLog-4-6714392903486597656.log;
not enough room for a header
WARN 00:44:48 Encountered bad header at position 16 of Commit log
[jira] [Created] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
Caleb William Rackliffe created CASSANDRA-7466:
--
Summary: Unit Test Suite Breaks when Run in a Single JVM
Key: CASSANDRA-7466
URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
Project: Cassandra
Issue Type: Bug
Components: Tests
Environment: MacOS 10.9.3, IntelliJ IDEA 13.1.3, Java 1.7.0_51
Reporter: Caleb William Rackliffe
Priority: Minor
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed a couple
tests in, complaining that it couldn't find the {{system}} keyspace in
{{build/test/cassandra/data.
tl;dr static initialization makes it hard to run the unit tests in the same JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is created
on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with a
call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not* recreate
the system keyspace, and so they fail when they force a compaction or perform
any other action that goes looking for it.
I guess there are two ways to fix this:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7466:
---
Attachment: trunk-7466.txt
Unit Test Suite Breaks when Run in a Single JVM
---
Key: CASSANDRA-7466
URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
Project: Cassandra
Issue Type: Bug
Components: Tests
Environment: MacOS 10.9.3, IntelliJ IDEA 13.1.3, Java 1.7.0_51
Reporter: Caleb William Rackliffe
Priority: Minor
Labels: test, test-fail, testcase, tests, testsuite
Attachments: trunk-7466.txt
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an
IDEA project. Everything in the tutorial works as it should, but when I tried
to run the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed
a couple tests in, complaining that it couldn't find the {{system}} keyspace
in {{build/test/cassandra/data.
tl;dr static initialization makes it hard to run the unit tests in the same
JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is
created on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with
a call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not*
recreate the system keyspace, and so they fail when they force a compaction
or perform any other action that goes looking for it.
I guess there are two ways to fix this:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7466:
---
Description:
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed a couple
tests in, complaining that it couldn't find the {{system}} keyspace in
{{build/test/cassandra/data}}.
tl;dr static initialization makes it hard to run the unit tests in the same JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is created
on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with a
call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not* recreate
the system keyspace, and so they fail when they force a compaction or perform
any other action that goes looking for it.
I guess there are two ways to fix this:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
was:
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed a couple
tests in, complaining that it couldn't find the {{system}} keyspace in
{{build/test/cassandra/data.
tl;dr static initialization makes it hard to run the unit tests in the same JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is created
on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with a
call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not* recreate
the system keyspace, and so they fail when they force a compaction or perform
any other action that goes looking for it.
I guess there are two ways to fix this:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
Unit Test Suite Breaks when Run in a Single JVM
---
Key: CASSANDRA-7466
URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
Project: Cassandra
Issue Type: Bug
Components: Tests
Environment: MacOS 10.9.3, IntelliJ IDEA 13.1.3, Java 1.7.0_51
Reporter: Caleb William Rackliffe
Priority: Minor
Labels: test, test-fail, testcase, tests, testsuite
Attachments: trunk-7466.txt
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an
IDEA project. Everything in the tutorial works as it should, but when I tried
to run the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed
a couple tests in, complaining that it couldn't find the {{system}} keyspace
in {{build/test/cassandra/data}}.
tl;dr static initialization makes it hard to run the unit tests in the same
JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is
created on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with
a call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not*
recreate the system keyspace, and so they fail when they force a compaction
or perform any other action that goes looking for it.
I guess there are two ways to fix this:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a
[jira] [Updated] (CASSANDRA-7466) Unit Test Suite Breaks when Run in a Single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb William Rackliffe updated CASSANDRA-7466:
---
Description:
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed a couple
tests in, complaining that it couldn't find the {{system}} keyspace in
{{build/test/cassandra/data}}.
tl;dr static initialization makes it hard to run the unit tests in the same JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is created
on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with a
call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not* recreate
the system keyspace, and so they fail when they force a compaction or perform
any other action that goes looking for it.
You can run the suite with IDEA's class/method forking, and you get a little
bit better results, but it still seems like this shouldn't be necessary.
I guess there are two ways to fix it:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
was:
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an IDEA
project. Everything in the tutorial works as it should, but when I tried to run
the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed a couple
tests in, complaining that it couldn't find the {{system}} keyspace in
{{build/test/cassandra/data}}.
tl;dr static initialization makes it hard to run the unit tests in the same JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is created
on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with a
call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not* recreate
the system keyspace, and so they fail when they force a compaction or perform
any other action that goes looking for it.
I guess there are two ways to fix this:
1.) We rebuild the system keyspace before for each test.
2.) We leave the system keyspace alone.
I took a hack at #1 in the attached patch. It looks like it to fixes this
specific problem, but I'm not super-believable in this codebase yet...
Unit Test Suite Breaks when Run in a Single JVM
---
Key: CASSANDRA-7466
URL: https://issues.apache.org/jira/browse/CASSANDRA-7466
Project: Cassandra
Issue Type: Bug
Components: Tests
Environment: MacOS 10.9.3, IntelliJ IDEA 13.1.3, Java 1.7.0_51
Reporter: Caleb William Rackliffe
Priority: Minor
Labels: test, test-fail, testcase, tests, testsuite
Attachments: trunk-7466.txt
Note: Instead of picking a version below, I'll simply note that I'm on
{{trunk}} at commit {{c027183ea4e901cf1d44e06704f6d78f84405bb4}}
I pulled down the source and followed
http://wiki.apache.org/cassandra/RunningCassandraInIDEA to import C* as an
IDEA project. Everything in the tutorial works as it should, but when I tried
to run the unit tests in {{test/unit/org.apache.cassandra}}, the suite failed
a couple tests in, complaining that it couldn't find the {{system}} keyspace
in {{build/test/cassandra/data}}.
tl;dr static initialization makes it hard to run the unit tests in the same
JVM
The full story is that...
1.) When the first test in the suite is run, the {{system}} keyspace is
created on disk and in the in-memory schema.
2.) Many subsequent tests, like {{BlacklistingCompactionsTest}}, remove the
{{system}} keyspace directory (among other things) in {{defineSchema()}} with
a call to {{SchemaLoader.prepareServer()}}.
3.) While these tests create the keyspaces they require, they do *not*
recreate the system keyspace, and so they fail when they force a compaction
or perform any other action that goes looking for it.
