[jira] [Commented] (CASSANDRA-14160) maxPurgeableTimestamp should traverse tables in order of minTimestamp
[
https://issues.apache.org/jira/browse/CASSANDRA-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324826#comment-16324826
]
Jeff Jirsa commented on CASSANDRA-14160:
Hey [~josnyder], the code looks sane, but it also doesn't compile (or rather,
the existing unit tests for the {{OverlapIterator}} no longer compile). Any
chance you can address that?
> maxPurgeableTimestamp should traverse tables in order of minTimestamp
> -
>
> Key: CASSANDRA-14160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14160
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Josh Snyder
>Assignee: Josh Snyder
> Labels: performance
> Fix For: 4.x
>
>
> In maxPurgeableTimestamp, we iterate over the bloom filters of each
> overlapping SSTable. Of the bloom filter hits, we take the SSTable with the
> lowest minTimestamp. If we kept the SSTables in sorted order of minTimestamp,
> then we could short-circuit the operation at the first bloom filter hit,
> reducing cache pressure (or worse, I/O) and CPU time.
> I've written (but not yet benchmarked) [some
> code|https://github.com/hashbrowncipher/cassandra/commit/29859a4a2e617f6775be49448858bc59fdafab44]
> to demonstrate this possibility.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14160) maxPurgeableTimestamp should traverse tables in order of minTimestamp
[ https://issues.apache.org/jira/browse/CASSANDRA-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324804#comment-16324804 ] Jeff Jirsa commented on CASSANDRA-14160: Pushed the patch to one of my github branches, running CI [here|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-14160] > maxPurgeableTimestamp should traverse tables in order of minTimestamp > - > > Key: CASSANDRA-14160 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14160 > Project: Cassandra > Issue Type: Bug > Components: Compaction >Reporter: Josh Snyder >Assignee: Josh Snyder > Labels: performance > Fix For: 4.x > > > In maxPurgeableTimestamp, we iterate over the bloom filters of each > overlapping SSTable. Of the bloom filter hits, we take the SSTable with the > lowest minTimestamp. If we kept the SSTables in sorted order of minTimestamp, > then we could short-circuit the operation at the first bloom filter hit, > reducing cache pressure (or worse, I/O) and CPU time. > I've written (but not yet benchmarked) [some > code|https://github.com/hashbrowncipher/cassandra/commit/29859a4a2e617f6775be49448858bc59fdafab44] > to demonstrate this possibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.
[
https://issues.apache.org/jira/browse/CASSANDRA-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324494#comment-16324494
]
Jason Brown commented on CASSANDRA-13528:
-
This patch works and code is fine, but I kinda like the version that printed
like this:
{quote}
Cluster Information:
Snitch: org.apache.cassandra.locator.SimpleSnitch
DynamicEndPointSnitch: enabled
{quote}
This is better because operators can choose to configure the
{{endpoint_snitch}} in the yaml, and to output that as a "Subsnitch" from
{{nodetool describecluster}} is little confusing as it's not what they
configured. Calling it Subsnitch is the correct wrt the src code, it's not
operator-friendly.
Which branches should we apply this change to? I'm thinking 3.11 and trunk. Any
strong argument for 3.0?
> nodetool describeclusters shows different snitch info as to what is
> configured.
> ---
>
> Key: CASSANDRA-13528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13528
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Paul Villacorta
>Assignee: Lerh Chuan Low
>Priority: Minor
> Labels: lhf
> Attachments: 13528-trunk.txt, Screen Shot 2017-05-12 at 14.15.04.png
>
>
> I couldn't find any similar issue as this one so I'm creating one.
> I noticed that doing nodetool describecluster shows a different Snitch
> Information as to what is being set in the configuration file.
> My setup is hosted in AWS and I am using Ec2Snitch.
> cassandra@cassandra3$ nodetool describecluster
> Cluster Information:
> Name: testv3
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> fc6e8656-ee7a-341b-9782-b569d1fd1a51:
> [10.0.3.61,10.0.3.62,10.0.3.63]
> I checked via MX4J and it shows the same, I haven't verified tho using a
> different Snitch and I am using 2.2.6 above and 3.0.X
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.
[ https://issues.apache.org/jira/browse/CASSANDRA-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-13528: Reviewer: Jason Brown > nodetool describeclusters shows different snitch info as to what is > configured. > --- > > Key: CASSANDRA-13528 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13528 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Paul Villacorta >Assignee: Lerh Chuan Low >Priority: Minor > Labels: lhf > Attachments: 13528-trunk.txt, Screen Shot 2017-05-12 at 14.15.04.png > > > I couldn't find any similar issue as this one so I'm creating one. > I noticed that doing nodetool describecluster shows a different Snitch > Information as to what is being set in the configuration file. > My setup is hosted in AWS and I am using Ec2Snitch. > cassandra@cassandra3$ nodetool describecluster > Cluster Information: > Name: testv3 > Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch > Partitioner: org.apache.cassandra.dht.Murmur3Partitioner > Schema versions: > fc6e8656-ee7a-341b-9782-b569d1fd1a51: > [10.0.3.61,10.0.3.62,10.0.3.63] > I checked via MX4J and it shows the same, I haven't verified tho using a > different Snitch and I am using 2.2.6 above and 3.0.X -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.
[ https://issues.apache.org/jira/browse/CASSANDRA-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324462#comment-16324462 ] Jason Brown commented on CASSANDRA-13528: - I can review this. > nodetool describeclusters shows different snitch info as to what is > configured. > --- > > Key: CASSANDRA-13528 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13528 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Paul Villacorta >Assignee: Lerh Chuan Low >Priority: Minor > Labels: lhf > Attachments: 13528-trunk.txt, Screen Shot 2017-05-12 at 14.15.04.png > > > I couldn't find any similar issue as this one so I'm creating one. > I noticed that doing nodetool describecluster shows a different Snitch > Information as to what is being set in the configuration file. > My setup is hosted in AWS and I am using Ec2Snitch. > cassandra@cassandra3$ nodetool describecluster > Cluster Information: > Name: testv3 > Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch > Partitioner: org.apache.cassandra.dht.Murmur3Partitioner > Schema versions: > fc6e8656-ee7a-341b-9782-b569d1fd1a51: > [10.0.3.61,10.0.3.62,10.0.3.63] > I checked via MX4J and it shows the same, I haven't verified tho using a > different Snitch and I am using 2.2.6 above and 3.0.X -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14141) Enable CDC unittest
[
https://issues.apache.org/jira/browse/CASSANDRA-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324456#comment-16324456
]
Jason Brown commented on CASSANDRA-14141:
-
Yup, 100% agree, [~JoshuaMcKenzie] .
> Enable CDC unittest
> ---
>
> Key: CASSANDRA-14141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14141
> Project: Cassandra
> Issue Type: Test
> Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
> Labels: CDC, testing
> Fix For: 3.11.2, 4.0
>
>
> Follow up for CASSANDRA-14066
> 2 CDC unittests are skipped in the normal test run, it has to be {{$ ant
> test-cdc}} to run the cdc test.
> The fix enables them in normal {{$ ant test}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14157) [DTEST] [TRUNK] test_tracing_does_not_interfere_with_digest_calculation - cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
[
https://issues.apache.org/jira/browse/CASSANDRA-14157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe reassigned CASSANDRA-14157:
---
Assignee: Sam Tunnicliffe
> [DTEST] [TRUNK] test_tracing_does_not_interfere_with_digest_calculation -
> cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
> -
>
> Key: CASSANDRA-14157
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14157
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Sam Tunnicliffe
>
> test_tracing_does_not_interfere_with_digest_calculation -
> cql_tracing_test.TestCqlTracing failed it's assertion once today in a
> circleci run. the dtests were running against trunk.
> Although it has failed once so far, a quick read of the comments in the test
> seems to indicate that the assertion failing this way might mean that
> CASSANDRA-13964 didn't fully fix the issue.
> {code:python}
> if jmx.has_mbean(rr_count):
> # expect 0 digest mismatches
> > assert 0 == jmx.read_attribute(rr_count, 'Count')
> E AssertionError: assert 0 == 1
> E+ where 1 = 0x7f62d4156898>>('org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking',
> 'Count')
> E+where > =
> .read_attribute
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14141) Enable CDC unittest
[
https://issues.apache.org/jira/browse/CASSANDRA-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324260#comment-16324260
]
Jay Zhuang commented on CASSANDRA-14141:
bq. Just a quick note: I wouldn't remove or stop running the test-cdc target on
ci. The reason I kept these completely separate was to fully exercise the rest
of the testing infrastructure with cdc enabled to confirm no regression / data
loss in the CommitLog from the changed cdc code. Running the unit tests
specific to cdc on a regular ant test run is fine as a smoke test but shouldn't
serve as a replacement for running the entire test suite against the changed
logic.
+1
> Enable CDC unittest
> ---
>
> Key: CASSANDRA-14141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14141
> Project: Cassandra
> Issue Type: Test
> Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
> Labels: CDC, testing
> Fix For: 3.11.2, 4.0
>
>
> Follow up for CASSANDRA-14066
> 2 CDC unittests are skipped in the normal test run, it has to be {{$ ant
> test-cdc}} to run the cdc test.
> The fix enables them in normal {{$ ant test}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14141) Enable CDC unittest
[
https://issues.apache.org/jira/browse/CASSANDRA-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324257#comment-16324257
]
Joshua McKenzie commented on CASSANDRA-14141:
-
Just a quick note: I wouldn't remove or stop running the {{test-cdc}} target on
ci. The reason I kept these completely separate was to fully exercise the rest
of the testing infrastructure with cdc enabled to confirm no regression / data
loss in the CommitLog from the changed cdc code. Running the unit tests
specific to cdc on a regular {{ant test}} run is fine as a smoke test but
shouldn't serve as a replacement for running the entire test suite against the
changed logic.
> Enable CDC unittest
> ---
>
> Key: CASSANDRA-14141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14141
> Project: Cassandra
> Issue Type: Test
> Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
> Labels: CDC, testing
> Fix For: 3.11.2, 4.0
>
>
> Follow up for CASSANDRA-14066
> 2 CDC unittests are skipped in the normal test run, it has to be {{$ ant
> test-cdc}} to run the cdc test.
> The fix enables them in normal {{$ ant test}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14166) sstabledump tries to delete a file
[
https://issues.apache.org/jira/browse/CASSANDRA-14166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324236#comment-16324236
]
Jeff Jirsa commented on CASSANDRA-14166:
Somewhat related to CASSANDRA-11163 , but {{sstabledump}} especially really
shouldn't be making any changes.
> sstabledump tries to delete a file
> --
>
> Key: CASSANDRA-14166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14166
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Python_Max
>
> Directory /var/lib/cassandra/data// has cassandra:cassandra
> owner.
> An error happens when sstabledump executed on file in that directory by
> regular user:
> {code:java}
> $ sstabledump mc-56801-big-Data.db
> Exception in thread "main" FSWriteError in
> /var/lib/cassandra/data///mc-56801-big-Summary.db
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:142)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:159)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:935)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:920)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:788)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:731)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:516)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.openNoValidation(SSTableReader.java:396)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:191)
> Caused by: java.nio.file.AccessDeniedException:
> /var/lib/cassandra/data///mc-56801-big-Summary.db
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 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:1126)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:136)
> ... 8 more
> {code}
> I have changed bloom_filter_fp_chance for that table couple months ago, so I
> believe that's the reason why SSTableReader wants to recreate summary file.
> But when used in sstabledump it should not try to modify / delete any files.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.
[ https://issues.apache.org/jira/browse/CASSANDRA-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13528: --- Component/s: Tools > nodetool describeclusters shows different snitch info as to what is > configured. > --- > > Key: CASSANDRA-13528 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13528 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Paul Villacorta >Assignee: Lerh Chuan Low >Priority: Minor > Labels: lhf > Attachments: 13528-trunk.txt, Screen Shot 2017-05-12 at 14.15.04.png > > > I couldn't find any similar issue as this one so I'm creating one. > I noticed that doing nodetool describecluster shows a different Snitch > Information as to what is being set in the configuration file. > My setup is hosted in AWS and I am using Ec2Snitch. > cassandra@cassandra3$ nodetool describecluster > Cluster Information: > Name: testv3 > Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch > Partitioner: org.apache.cassandra.dht.Murmur3Partitioner > Schema versions: > fc6e8656-ee7a-341b-9782-b569d1fd1a51: > [10.0.3.61,10.0.3.62,10.0.3.63] > I checked via MX4J and it shows the same, I haven't verified tho using a > different Snitch and I am using 2.2.6 above and 3.0.X -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.
[ https://issues.apache.org/jira/browse/CASSANDRA-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13528: --- Status: Patch Available (was: Open) Marking patch-available so reviewers see it. > nodetool describeclusters shows different snitch info as to what is > configured. > --- > > Key: CASSANDRA-13528 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13528 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Paul Villacorta >Assignee: Lerh Chuan Low >Priority: Minor > Labels: lhf > Attachments: 13528-trunk.txt, Screen Shot 2017-05-12 at 14.15.04.png > > > I couldn't find any similar issue as this one so I'm creating one. > I noticed that doing nodetool describecluster shows a different Snitch > Information as to what is being set in the configuration file. > My setup is hosted in AWS and I am using Ec2Snitch. > cassandra@cassandra3$ nodetool describecluster > Cluster Information: > Name: testv3 > Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch > Partitioner: org.apache.cassandra.dht.Murmur3Partitioner > Schema versions: > fc6e8656-ee7a-341b-9782-b569d1fd1a51: > [10.0.3.61,10.0.3.62,10.0.3.63] > I checked via MX4J and it shows the same, I haven't verified tho using a > different Snitch and I am using 2.2.6 above and 3.0.X -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14156) [DTEST] [TRUNK] TestTopology.movement_test is flaky; fails assert "values not within 16.00% of the max: (851.41, 713.26)"
[
https://issues.apache.org/jira/browse/CASSANDRA-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14156:
Status: Patch Available (was: Open)
in 3.11 and trunk we need to run {{relocatesstables}} to move tokens to their
correct places, then we need to run a major compaction to make sure that there
are no overlapping tokens
https://github.com/krummas/cassandra-dtest/commits/marcuse/14156
> [DTEST] [TRUNK] TestTopology.movement_test is flaky; fails assert "values not
> within 16.00% of the max: (851.41, 713.26)"
> -
>
> Key: CASSANDRA-14156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14156
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Marcus Eriksson
>
> DTest* TestTopology.test_movement* is flaky. All of the testing so far (and
> thus all of the current known observed failures) have been when running
> against trunk. When the test fails, it always due to the assert_almost_equal
> assert.
> {code}
> AssertionError: values not within 16.00% of the max: (851.41, 713.26) ()
> {code}
> The following CircleCI runs are 2 examples with dtests runs that failed due
> to this test failing it's assert:
> [https://circleci.com/gh/mkjellman/cassandra/487]
> [https://circleci.com/gh/mkjellman/cassandra/526]
> *p.s.* assert_almost_equal has a comment "@params error Optional margin of
> error. Default 0.16". I don't see any obvious notes for why the default is
> this magical 16% number. It looks like it was committed as part of a big bulk
> commit by Sean McCarthy (who I can't find on JIRA). If anyone has any history
> on the magic 16% allowed delta please share!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14166) sstabledump tries to delete a file
[
https://issues.apache.org/jira/browse/CASSANDRA-14166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Python_Max updated CASSANDRA-14166:
---
Description:
Directory /var/lib/cassandra/data// has cassandra:cassandra
owner.
An error happens when sstabledump executed on file in that directory by regular
user:
{code:java}
$ sstabledump mc-56801-big-Data.db
Exception in thread "main" FSWriteError in
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:142)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:159)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:935)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:920)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:788)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:731)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:516)
at
org.apache.cassandra.io.sstable.format.SSTableReader.openNoValidation(SSTableReader.java:396)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:191)
Caused by: java.nio.file.AccessDeniedException:
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
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:1126)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:136)
... 8 more
{code}
I have changed bloom_filter_fp_chance for that table couple months ago, so I
believe that's the reason why SSTableReader wants to recreate summary file. But
when used in sstabledump it should not try to modify / delete any files.
was:
Directory /var/lib/cassandra/data// has cassandra:cassandra
owner.
An error happens when sstabledump executed on file in that directory by regular
user:
{quote}$ sstabledump mc-56801-big-Data.db
Exception in thread "main" FSWriteError in
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:142)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:159)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:935)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:920)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:788)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:731)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:516)
at
org.apache.cassandra.io.sstable.format.SSTableReader.openNoValidation(SSTableReader.java:396)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:191)
Caused by: java.nio.file.AccessDeniedException:
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
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:1126)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:136)
... 8 more
{quote}
I have changed bloom_filter_fp_chance for that table couple months ago, so I
believe that's the reason why SSTableReader wants to recreate summary file. But
when used in sstabledump it should not try to modify / delete any files.
> sstabledump tries to delete a file
> --
>
> Key: CASSANDRA-14166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14166
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Python_Max
>
> Directory /var/lib/cassandra/data// has cassandra:cassandra
> owner.
> An error happens when sstabledump executed on file in that directory by
> regular user:
> {code:java}
> $ sstabledump mc-56801-big-Data.db
> Exception in thread "main" FSWriteError in
>
[jira] [Updated] (CASSANDRA-14166) sstabledump tries to delete a file
[
https://issues.apache.org/jira/browse/CASSANDRA-14166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Python_Max updated CASSANDRA-14166:
---
Description:
Directory /var/lib/cassandra/data// has cassandra:cassandra
owner.
An error happens when sstabledump executed on file in that directory by regular
user:
{quote}$ sstabledump mc-56801-big-Data.db
Exception in thread "main" FSWriteError in
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:142)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:159)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:935)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:920)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:788)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:731)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:516)
at
org.apache.cassandra.io.sstable.format.SSTableReader.openNoValidation(SSTableReader.java:396)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:191)
Caused by: java.nio.file.AccessDeniedException:
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
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:1126)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:136)
... 8 more
{quote}
I have changed bloom_filter_fp_chance for that table couple months ago, so I
believe that's the reason why SSTableReader wants to recreate summary file. But
when used in sstabledump it should not try to modify / delete any files.
was:
Directory /var/lib/cassandra/data// has cassandra:cassandra
owner.
An error happens when sstabledump executed on file in that directory by regular
user:
$ sstabledump mc-56801-big-Data.db
Exception in thread "main" FSWriteError in
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:142)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:159)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:935)
at
org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:920)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:788)
at
org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:731)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:516)
at
org.apache.cassandra.io.sstable.format.SSTableReader.openNoValidation(SSTableReader.java:396)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:191)
Caused by: java.nio.file.AccessDeniedException:
/var/lib/cassandra/data///mc-56801-big-Summary.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
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:1126)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:136)
... 8 more
I have changed bloom_filter_fp_chance for that table couple months ago, so I
believe that's the reason why SSTableReader wants to recreate summary file. But
when used in sstabledump it should not try to modify / delete any files.
> sstabledump tries to delete a file
> --
>
> Key: CASSANDRA-14166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14166
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Python_Max
>
> Directory /var/lib/cassandra/data// has cassandra:cassandra
> owner.
> An error happens when sstabledump executed on file in that directory by
> regular user:
> {quote}$ sstabledump mc-56801-big-Data.db
> Exception in thread "main" FSWriteError in
> /var/lib/cassandra/data///mc-56801-big-Summary.db
> at
[jira] [Created] (CASSANDRA-14166) sstabledump tries to delete a file
Python_Max created CASSANDRA-14166: -- Summary: sstabledump tries to delete a file Key: CASSANDRA-14166 URL: https://issues.apache.org/jira/browse/CASSANDRA-14166 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Python_Max Directory /var/lib/cassandra/data// has cassandra:cassandra owner. An error happens when sstabledump executed on file in that directory by regular user: $ sstabledump mc-56801-big-Data.db Exception in thread "main" FSWriteError in /var/lib/cassandra/data///mc-56801-big-Summary.db at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:142) at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:159) at org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:935) at org.apache.cassandra.io.sstable.format.SSTableReader.saveSummary(SSTableReader.java:920) at org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:788) at org.apache.cassandra.io.sstable.format.SSTableReader.load(SSTableReader.java:731) at org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:516) at org.apache.cassandra.io.sstable.format.SSTableReader.openNoValidation(SSTableReader.java:396) at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:191) Caused by: java.nio.file.AccessDeniedException: /var/lib/cassandra/data///mc-56801-big-Summary.db at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) 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:1126) at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:136) ... 8 more I have changed bloom_filter_fp_chance for that table couple months ago, so I believe that's the reason why SSTableReader wants to recreate summary file. But when used in sstabledump it should not try to modify / delete any files. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14165) execute_prepared_cql3_query with LIKE not working
Alexandr Gorbachev created CASSANDRA-14165:
--
Summary: execute_prepared_cql3_query with LIKE not working
Key: CASSANDRA-14165
URL: https://issues.apache.org/jira/browse/CASSANDRA-14165
Project: Cassandra
Issue Type: Bug
Reporter: Alexandr Gorbachev
Hello ,
I have faced up with following issue.
Seems like LIKE is not supported by 'execute_prepared_cql3_query'.
Is it by desing or somehow it is possible to find a workaroud or to fix this
issue?
More details. Query looks like :
SELECT * FROM tabke WHERE a= ? AND b = ? AND c IN (?,?,?,?,?,?,?) AND column
LIKE ? ALLOW FILTERING;
Is not working.
If I send directly query in prepare statement.
So actully wihout passing parameters in preare statement, just like plain
query, then this is working:
SELECT * FROM tabke WHERE a= '1' AND b = '2' AND c IN ('3','4') AND column LIKE
'%A%' ALLOW FILTERING;
Thank you for help.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9630) Killing cassandra process results in unclosed connections
[ https://issues.apache.org/jira/browse/CASSANDRA-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-9630: Status: Ready to Commit (was: Patch Available) > Killing cassandra process results in unclosed connections > - > > Key: CASSANDRA-9630 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9630 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata, Streaming and Messaging >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Minor > Fix For: 3.11.x > > Attachments: apache-cassandra-3.0.8-SNAPSHOT.jar > > > After upgrading from Cassandra from 2.0.12 to 2.0.15, whenever we killed a > cassandra process (with SIGTERM), some other nodes maintained a connection > with the killed node in the CLOSE_WAIT state on port 7000 for about 5-20 > minutes. > So, when we started the killed node again, other nodes could not establish a > handshake because of the connections on the CLOSE_WAIT state, so they > remained on the DOWN state to each other until the initial connection expired. > The problem did not happen if I ran a nodetool disablegossip before killing > the node. > I was able to fix this issue by reverting the CASSANDRA-8336 commits > (including CASSANDRA-9238). After reverting this, cassandra now closes > connection correctly when killed with -TERM, but leaves connections on > CLOSE_WAIT state if I run nodetool disablethrift before killing the nodes. > I did not try to reproduce the problem in a clean environment. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9630) Killing cassandra process results in unclosed connections
[ https://issues.apache.org/jira/browse/CASSANDRA-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323944#comment-16323944 ] Robert Stupp commented on CASSANDRA-9630: - +1 it should fix the issue. > Killing cassandra process results in unclosed connections > - > > Key: CASSANDRA-9630 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9630 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata, Streaming and Messaging >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Minor > Fix For: 3.11.x > > Attachments: apache-cassandra-3.0.8-SNAPSHOT.jar > > > After upgrading from Cassandra from 2.0.12 to 2.0.15, whenever we killed a > cassandra process (with SIGTERM), some other nodes maintained a connection > with the killed node in the CLOSE_WAIT state on port 7000 for about 5-20 > minutes. > So, when we started the killed node again, other nodes could not establish a > handshake because of the connections on the CLOSE_WAIT state, so they > remained on the DOWN state to each other until the initial connection expired. > The problem did not happen if I ran a nodetool disablegossip before killing > the node. > I was able to fix this issue by reverting the CASSANDRA-8336 commits > (including CASSANDRA-9238). After reverting this, cassandra now closes > connection correctly when killed with -TERM, but leaves connections on > CLOSE_WAIT state if I run nodetool disablethrift before killing the nodes. > I did not try to reproduce the problem in a clean environment. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9630) Killing cassandra process results in unclosed connections
[ https://issues.apache.org/jira/browse/CASSANDRA-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-9630: Reviewer: Robert Stupp > Killing cassandra process results in unclosed connections > - > > Key: CASSANDRA-9630 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9630 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata, Streaming and Messaging >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Minor > Fix For: 3.11.x > > Attachments: apache-cassandra-3.0.8-SNAPSHOT.jar > > > After upgrading from Cassandra from 2.0.12 to 2.0.15, whenever we killed a > cassandra process (with SIGTERM), some other nodes maintained a connection > with the killed node in the CLOSE_WAIT state on port 7000 for about 5-20 > minutes. > So, when we started the killed node again, other nodes could not establish a > handshake because of the connections on the CLOSE_WAIT state, so they > remained on the DOWN state to each other until the initial connection expired. > The problem did not happen if I ran a nodetool disablegossip before killing > the node. > I was able to fix this issue by reverting the CASSANDRA-8336 commits > (including CASSANDRA-9238). After reverting this, cassandra now closes > connection correctly when killed with -TERM, but leaves connections on > CLOSE_WAIT state if I run nodetool disablethrift before killing the nodes. > I did not try to reproduce the problem in a clean environment. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14156) [DTEST] [TRUNK] TestTopology.movement_test is flaky; fails assert "values not within 16.00% of the max: (851.41, 713.26)"
[
https://issues.apache.org/jira/browse/CASSANDRA-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14156:
Summary: [DTEST] [TRUNK] TestTopology.movement_test is flaky; fails assert
"values not within 16.00% of the max: (851.41, 713.26)" (was: [DTEST] [TRUNK]
TestTopology.test_movement is flaky; fails assert "values not within 16.00% of
the max: (851.41, 713.26)")
> [DTEST] [TRUNK] TestTopology.movement_test is flaky; fails assert "values not
> within 16.00% of the max: (851.41, 713.26)"
> -
>
> Key: CASSANDRA-14156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14156
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Marcus Eriksson
>
> DTest* TestTopology.test_movement* is flaky. All of the testing so far (and
> thus all of the current known observed failures) have been when running
> against trunk. When the test fails, it always due to the assert_almost_equal
> assert.
> {code}
> AssertionError: values not within 16.00% of the max: (851.41, 713.26) ()
> {code}
> The following CircleCI runs are 2 examples with dtests runs that failed due
> to this test failing it's assert:
> [https://circleci.com/gh/mkjellman/cassandra/487]
> [https://circleci.com/gh/mkjellman/cassandra/526]
> *p.s.* assert_almost_equal has a comment "@params error Optional margin of
> error. Default 0.16". I don't see any obvious notes for why the default is
> this magical 16% number. It looks like it was committed as part of a big bulk
> commit by Sean McCarthy (who I can't find on JIRA). If anyone has any history
> on the magic 16% allowed delta please share!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14156) [DTEST] [TRUNK] TestTopology.test_movement is flaky; fails assert "values not within 16.00% of the max: (851.41, 713.26)"
[
https://issues.apache.org/jira/browse/CASSANDRA-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-14156:
---
Assignee: Marcus Eriksson
> [DTEST] [TRUNK] TestTopology.test_movement is flaky; fails assert "values not
> within 16.00% of the max: (851.41, 713.26)"
> -
>
> Key: CASSANDRA-14156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14156
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Marcus Eriksson
>
> DTest* TestTopology.test_movement* is flaky. All of the testing so far (and
> thus all of the current known observed failures) have been when running
> against trunk. When the test fails, it always due to the assert_almost_equal
> assert.
> {code}
> AssertionError: values not within 16.00% of the max: (851.41, 713.26) ()
> {code}
> The following CircleCI runs are 2 examples with dtests runs that failed due
> to this test failing it's assert:
> [https://circleci.com/gh/mkjellman/cassandra/487]
> [https://circleci.com/gh/mkjellman/cassandra/526]
> *p.s.* assert_almost_equal has a comment "@params error Optional margin of
> error. Default 0.16". I don't see any obvious notes for why the default is
> this magical 16% number. It looks like it was committed as part of a big bulk
> commit by Sean McCarthy (who I can't find on JIRA). If anyone has any history
> on the magic 16% allowed delta please share!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13762) Ensure views created during (or just before) range movements are properly built
[
https://issues.apache.org/jira/browse/CASSANDRA-13762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323891#comment-16323891
]
Andrés de la Peña commented on CASSANDRA-13762:
---
Overall the patch looks good to me. A few insignificant nits:
* The new {{StorageService.finishViewBootstrap}} method [triggers a view
build|https://github.com/pauloricardomg/cassandra/blob/c47cfb9f3299274f97e47610eb6329390dcacdc0/src/java/org/apache/cassandra/service/StorageService.java#L1550]
if the batchlog replay fails. It could be good to simulate this case in a
dtest, WDYT?
* The [second {{return}}
statement|https://github.com/pauloricardomg/cassandra/blob/c47cfb9f3299274f97e47610eb6329390dcacdc0/src/java/org/apache/cassandra/repair/SystemDistributedKeyspace.java#L314]
in {{SystemDistributedKeyspace.isViewBuilt}} seems unnecessary.
* The new unit test {{testhasBuiltAllViews}} should be named
{{testHasBuiltAllViews}}, and the create view statement could be splitted for
better readability.
* The [last {{if}} block
statement|https://github.com/pauloricardomg/cassandra-dtest/blob/fa280103530461447ec9b92e3ecf9f023a42f0fe/materialized_views_test.py#L1240-L1245]
of the new dtest method [doesn't use the log
marking|https://github.com/pauloricardomg/cassandra-dtest/blob/fa280103530461447ec9b92e3ecf9f023a42f0fe/materialized_views_test.py#L1243].
* I think it could be useful to extend [this dtest debug
message|https://github.com/pauloricardomg/cassandra-dtest/blob/fa280103530461447ec9b92e3ecf9f023a42f0fe/materialized_views_test.py#L1241]
with the reason of the restart, something like {{"Restart the cluster to
finish the stopped build"}}.
> Ensure views created during (or just before) range movements are properly
> built
> ---
>
> Key: CASSANDRA-13762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13762
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: materializedviews
> Attachments: trunk-13762-dtest.png, trunk-13762-testall.png
>
>
> CASSANDRA-13065 assumes the source node has its views built to skip running
> base mutations through the write path during range movements.
> It is possible that the source node has not finished building the view, or
> that a new view is created during a range movement, in which case the view
> may be wrongly marked as built on the destination node.
> The former problem was introduced by #13065, but even before that a view
> created during a range movement may not be correctly built on the destination
> node because the view builder will be triggered before it has finished
> streaming the source data, wrongly marking the view as built on that node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14069) Node stopped serving write requests when a table has a lot of sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-14069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323729#comment-16323729
]
Marcus Eriksson commented on CASSANDRA-14069:
-
[~slapukhov] do you have a node where you can reproduce this?
In 3.11 we have CASSANDRA-11571 - could you test with that patch applied to
3.0? Maybe that is enough to make perf acceptable
> Node stopped serving write requests when a table has a lot of sstables
> --
>
> Key: CASSANDRA-14069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14069
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Sergey Lapukhov
>Assignee: Sergey Lapukhov
> Attachments: CAS-14069.patch, afterPatch.svg, beforePatch.svg,
> create.cql, stack.txt
>
>
> Cluster was flooded with SSTables. A table had ~2 sstables. Write
> requests started failing.
> Steps to reproduce:
> * Create cluster with 3 nodes
> * Specify
>{noformat}
> memtable_heap_space_in_mb: 10
> {noformat}
> in cassandra.yaml
> * Create table standard1 in keyspace1 (for the cassandra-stress tool) with
> the script [^create.cql]. Please note
> {noformat} compaction = {'class': 'SizeTieredCompactionStrategy', 'enabled':
> 'false'} {noformat}
> i.e. compaction will be turned off for now.
> * Populate node with data:
> {noformat} cassandra-stress write n=10 -node 127.0.0.1 {noformat}
> * After node was populated, put both read and write pressure on it:
> {noformat} cassandra-stress read n=10 -node 127.0.0.1
> cassandra-stress write n=10 -node 127.0.0.1 {noformat}
> * While still under pressure, enable LeveledCompactionStrategy
> {code:java} echo "ALTER TABLE keyspace1.standard1 WITH compaction = {
> 'class' : 'LeveledCompactionStrategy', 'sstable_size_in_mb' : 1 }; DESC
> keyspace1.standard1; exit" | bin/cqlsh; {code}
> *Results:*
> Write requests failing.
> 'bin/nodetool cfstats' and 'bin/nodetool compactionstats' commands hanging,
> if issued from the node running cassandra-stress tool.
> If issued from another node:
> {noformat}
> $ bin/nodetool cfstats
> ...
> Table: standard1
> SSTable count: 22637
> SSTables in each level: [22651/4, 0, 0, 0, 0, 0, 0, 0, 0]
> ...
> {noformat}
> {noformat}
> $ bin/nodetool compactionstats
> pending tasks: 12656
> id compaction typekeyspace
> table completed totalunit progress
>935bbc00-d03b-11e7-a47d-2b44293495b8Compaction keyspace1
> standard15955601459557860 bytes100.00%
>a29ee660-d03b-11e7-a47d-2b44293495b8Compaction keyspace1
> standard180432114 742151655 bytes 10.84%
>9766e400-d03b-11e7-a47d-2b44293495b8Compaction keyspace1
> standard15889160458893215 bytes100.00%
>9cdc9880-d03b-11e7-a47d-2b44293495b8Compaction keyspace1
> standard12028944920290800 bytes 99.99%
>90f98910-d03b-11e7-a47d-2b44293495b8Compaction keyspace1
> standard15968982459695545 bytes 99.99%
>986ede20-d03b-11e7-a47d-2b44293495b8Compaction keyspace1
> standard14059859440598820 bytes100.00%
>9cd322a0-d03b-11e7-a47d-2b44293495b8Compaction keyspace1
> standard1607567396070 bytes 99.98%
> {noformat}
> Special note about 'bin/nodetool compactionstats' - picture above is quite
> typical for this issue. I.e. compaction tasks manage to make it through, but
> hinder near the full completion (around 99.9 %).
> Maybe the root of the problem is in this thread (see [^stack.txt]):
> {noformat}
> "CompactionExecutor:1748" #4649 daemon prio=1 os_prio=4
> tid=0x7f35a0096100 nid=0x65f6 runnable [0x7f3228bce000]
>java.lang.Thread.State: RUNNABLE
> at org.apache.cassandra.dht.AbstractBounds.(AbstractBounds.java:53)
> at org.apache.cassandra.dht.Bounds.(Bounds.java:42)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.overlapping(LeveledManifest.java:562)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.overlapping(LeveledManifest.java:549)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:624)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:378)
> - locked <0x00070d4c3bc8> (a
> org.apache.cassandra.db.compaction.LeveledManifest)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:105)
> - locked <0x00070d6cb2c8> (a
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy)
> at
>
[jira] [Created] (CASSANDRA-14164) Calling StorageService.loadNewSSTables function results in deadlock with compaction background task
Ignace Desimpel created CASSANDRA-14164: --- Summary: Calling StorageService.loadNewSSTables function results in deadlock with compaction background task Key: CASSANDRA-14164 URL: https://issues.apache.org/jira/browse/CASSANDRA-14164 Project: Cassandra Issue Type: Bug Components: Compaction, Tools Environment: code Reporter: Ignace Desimpel Priority: Blocker Fix For: 2.2.x, 3.0.x Attachments: Stack1.txt Tested on version 2.2.11 (but seems like trunck 3.x is still the same for the related code path), using nodetool refresh for restoring a snapshot Calling StorageService.loadNewSSTables function results in deadlock with compaction background task. because : >From StorageService class , function public void loadNewSSTables(String >ksName, String cfName) a call is made to ColumnFamilyStore class , function >public static synchronized void loadNewSSTables(String ksName, String cfName) >and then a call to Keyspace class, function public static Keyspace open(String >keyspaceName) getting to the function private static Keyspace open(String keyspaceName, Schema schema, boolean loadSSTables) finally trying to get a lock by synchronized (Keyspace.class) So inside the ColumnFamilyStore class lock, there is an attempt to get the lock on the Keyspace.class Now at the same time I have the thread OptionalTasks executing the ColumnFamilyStore.getBackgroundCompactionTaskSubmitter() task. The thread task is also calling Keyspace.open function, already progressed as far as getting the lock on Keyspace class. But then the call also initializes the column families and thus is calling on class ColumnFamilyStore the public static synchronized ColumnFamilyStore createColumnFamilyStore ... Result : the external call on loadNewSSTables blocks the internal compaction background task. So function 1 locks A and then B And function 2 locks B and then A leading to deadlock (due to incorrect order of locking objects) Regards, Ignace -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
