[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] [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
]
Aleksey Yeschenko updated CASSANDRA-7466:
-
Reviewer: Branimir Lambov (was: Aleksey Yeschenko)
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
Assignee: Caleb William Rackliffe
Priority: Minor
Labels: unit-test
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.
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
]
Jonathan Ellis updated CASSANDRA-7466:
--
Reviewer: Aleksey Yeschenko (was: Joshua McKenzie)
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
Assignee: Caleb William Rackliffe
Priority: Minor
Labels: unit-test
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.
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.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
]
Jonathan Ellis updated CASSANDRA-7466:
--
Reviewer: Joshua McKenzie
Assignee: Caleb William Rackliffe (was: Ryan McGuire)
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
Assignee: Caleb William Rackliffe
Priority: Minor
Labels: unit-test
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.
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.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
]
Michael Shuler updated CASSANDRA-7466:
--
Labels: unit-test (was: test test-fail testcase tests testsuite)
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: unit-test
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.
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.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
]
Michael Shuler updated CASSANDRA-7466:
--
Assignee: Ryan McGuire
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
Assignee: Ryan McGuire
Priority: Minor
Labels: unit-test
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.
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.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.
