[jira] [Commented] (CASSANDRA-14936) Anticompaction should throw exceptions on errors, not just log them
[ https://issues.apache.org/jira/browse/CASSANDRA-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723776#comment-16723776 ] Marcus Eriksson commented on CASSANDRA-14936: - bq. there's some stuff related to CASSANDRA-14935 in here as well Do you mean making anticompaction unstoppable? I added that to avoid cancelling ongoing anticompactions until we have CASSANDRA-14935 finished, it might be unnecessary since we should fix 14935 soon anyway, so I could remove those parts > Anticompaction should throw exceptions on errors, not just log them > --- > > Key: CASSANDRA-14936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14936 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Major > Fix For: 4.0 > > > Anticompaction currently catches any exceptions and just logs them instead of > rethrowing, this can cause us to overstream and leave sstables unrepaired. > This was made more likely to happen with CASSANDRA-14397 (before that > anticompactions could not be stopped at all). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14929) twcs sstables gets merged following node removal
[
https://issues.apache.org/jira/browse/CASSANDRA-14929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723708#comment-16723708
]
Varun Barala commented on CASSANDRA-14929:
--
1) SSTables timestamp is not judged based on the time when SSTable was flushed
instead it's judged based on inside partitions livenessInfo.
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java#L318]
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/metadata/StatsMetadata.java]
2) I tried to reproduce on local and found that it only merged the SStables
which are having identical partitions and SSTable came from the replicated node.
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/TimeWindowCompactionStrategy.java#L314]
Logs on local:-
{code:java}
DEBUG [CompactionExecutor:8] 2018-12-18 13:00:00,952
TimeWindowCompactionStrategy.java:299 - bucket size 2 >= 2 and not in current
bucket, compacting what's here:
[BigTableReader(path='/home/barala/.ccm/twcs/node2/data0/ks2/t1-cbfc3540027a11e9b8242167b8f53585/mc-4-big-Data.db'),
BigTableReader(path='/home/barala/.ccm/twcs/node2/data0/ks2/t1-cbfc3540027a11e9b8242167b8f53585/mc-10-big-Data.db')]
DEBUG [CompactionExecutor:8] 2018-12-18 13:00:00,953 CompactionTask.java:158 -
Compacting (c61ff290-0281-11e9-985b-b3987cee6cf4)
[/home/barala/.ccm/twcs/node2/data0/ks2/t1-cbfc3540027a11e9b8242167b8f53585/mc-4-big-Data.db:level=0,
/home/barala/.ccm/twcs/node2/data0/ks2/t1-cbfc3540027a11e9b8242167b8f53585/mc-10-big-Data.db:level=0,
]{code}
*mc-4* was on the local node and *mc-10* came from a replica node. Both will
fall under in the same bucket since both are having identical partitions.
{code:java}
DEBUG [NonPeriodicTasks:1] 2018-12-18 13:00:00,991 SSTable.java:107 - Deleting
sstable:
/home/barala/.ccm/twcs/node2/data0/ks2/t1-cbfc3540027a11e9b8242167b8f53585/mc-4-big
DEBUG [CompactionExecutor:8] 2018-12-18 13:00:00,991 CompactionTask.java:235 -
Compacted (c61ff290-0281-11e9-985b-b3987cee6cf4) 2 sstables to
[/home/barala/.ccm/twcs/node2/data0/ks2/t1-cbfc3540027a11e9b8242167b8f53585/mc-11-big,]
to level=0. 125 bytes to 75 (~60% of original) in 37ms = 0.001933MB/s. 4 total
partitions merged to 3. Partition merge counts were {1:2, 2:1, }{code}
IMO this is the expected behavior.
[~jjirsa] Could you please check once? If looks good then can be destructed!!
Thank You!
> twcs sstables gets merged following node removal
>
>
> Key: CASSANDRA-14929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14929
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: cassandra 3.0.17
>Reporter: Gil Ganz
>Priority: Major
> Labels: cassandra, compaction, twcs
>
> after removing a node from the cluster, a table that is defined as twcs, has
> sstables from different time windows merged together, making old and new data
> sit in the same sstable.
> CREATE KEYSPACE gil_test WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'DC1': '2'} AND durable_writes = true;
> CREATE TABLE gil_test.my_test (
> id int,
> creation_time timestamp,
> name text,
> PRIMARY KEY (id, creation_time)
> ) WITH CLUSTERING ORDER BY (creation_time ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = \{'compaction_window_unit': 'HOURS',
> 'compaction_window_size': '2', 'class': 'TimeWindowCompactionStrategy'}
> AND compression = \{'chunk_length_kb': '4', 'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 3600
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = 'NONE';
>
> 3 nodes cluster
> before removing node number 3 - directory listing
> drwxr-xr-x 2 cassandra cassandra 4096 Dec 10 20:28 backups
> -rw-r--r-- 1 cassandra cassandra 51 Dec 10 22:10 mc-16-big-CompressionInfo.db
> -rw-r--r-- 1 cassandra cassandra 2044 Dec 10 22:10 mc-16-big-Data.db
> -rw-r--r-- 1 cassandra cassandra 9 Dec 10 22:10 mc-16-big-Digest.crc32
> -rw-r--r-- 1 cassandra cassandra 64 Dec 10 22:10 mc-16-big-Filter.db
> -rw-r--r-- 1 cassandra cassandra 375 Dec 10 22:10 mc-16-big-Index.db
> -rw-r--r-- 1 cassandra cassandra 4805 Dec 10 22:10 mc-16-big-Statistics.db
> -rw-r--r-- 1 cassandra cassandra 56 Dec 10 22:10 mc-16-big-Summary.db
> -rw-r--r-- 1 cassandra cassandra 92 Dec 10 22:10 mc-16-big-TOC.txt
> -rw-r--r-- 1 cassandra cassandra 51 Dec 11 00:00 mc-31-big-CompressionInfo.db
> -rw-r--r-- 1 cassa
[jira] [Commented] (CASSANDRA-14936) Anticompaction should throw exceptions on errors, not just log them
[ https://issues.apache.org/jira/browse/CASSANDRA-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723464#comment-16723464 ] Blake Eggleston commented on CASSANDRA-14936: - This addresses this ticket fine, but it seems like there's some stuff related to CASSANDRA-14935 in here as well. Could you put that in a separate branch? > Anticompaction should throw exceptions on errors, not just log them > --- > > Key: CASSANDRA-14936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14936 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Major > Fix For: 4.0 > > > Anticompaction currently catches any exceptions and just logs them instead of > rethrowing, this can cause us to overstream and leave sstables unrepaired. > This was made more likely to happen with CASSANDRA-14397 (before that > anticompactions could not be stopped at all). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14939) fix some operational holes in incremental repair
Blake Eggleston created CASSANDRA-14939: --- Summary: fix some operational holes in incremental repair Key: CASSANDRA-14939 URL: https://issues.apache.org/jira/browse/CASSANDRA-14939 Project: Cassandra Issue Type: Bug Reporter: Blake Eggleston Assignee: Blake Eggleston Incremental repair has a few operational rough spots that make it more difficult to fully automate and operate at scale than it should be. * Visibility into whether pending repair data exists for a given token range. * Ability to force promotion/demotion of data for completed sessions instead of waiting for compaction. * Get the most recent repairedAt timestamp for a given token range. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14702) Cassandra Write failed even when the required nodes to Ack(consistency) are up.
[ https://issues.apache.org/jira/browse/CASSANDRA-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-14702: --- Priority: Minor (was: Blocker) > Cassandra Write failed even when the required nodes to Ack(consistency) are > up. > --- > > Key: CASSANDRA-14702 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14702 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Rohit Singh >Priority: Minor > > Hi, > We have following configuration in our project for cassandra. > Total nodes in Cluster-5 > Replication Factor- 3 > Consistency- LOCAL_QUORUM > We get the writetimeout exception from cassandra even when 2 nodes are up and > why does stack trace says that 3 replica were required when consistency is 2? > Below is the exception we got:- > com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout > during write query at consistency LOCAL_QUORUM (3 replica were required but > only 2 acknowledged the write) > at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:59) > at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:37) > at com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:289) > at com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:269) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14702) Cassandra Write failed even when the required nodes to Ack(consistency) are up.
[ https://issues.apache.org/jira/browse/CASSANDRA-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa resolved CASSANDRA-14702. Resolution: Not A Problem This is almost certainly not a bug - having RF=3 and 3 nodes down in the cluster is likely to cause issues, but there's insufficient information here to conclude that it's even remotely concerning. It's definitely not a blocker. > Cassandra Write failed even when the required nodes to Ack(consistency) are > up. > --- > > Key: CASSANDRA-14702 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14702 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Rohit Singh >Priority: Blocker > > Hi, > We have following configuration in our project for cassandra. > Total nodes in Cluster-5 > Replication Factor- 3 > Consistency- LOCAL_QUORUM > We get the writetimeout exception from cassandra even when 2 nodes are up and > why does stack trace says that 3 replica were required when consistency is 2? > Below is the exception we got:- > com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout > during write query at consistency LOCAL_QUORUM (3 replica were required but > only 2 acknowledged the write) > at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:59) > at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:37) > at com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:289) > at com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:269) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722988#comment-16722988
]
Marcus Eriksson commented on CASSANDRA-14806:
-
2.2:
code: https://github.com/krummas/cassandra/commits/stefan/14806-2.2
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-2.2
reference run (unpatched 2.2):
https://circleci.com/workflow-run/bf69001c-756b-4c43-a754-652066dca07f
3.0
code: https://github.com/krummas/cassandra/commits/stefan/14806-3.0
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-3.0
3.11
code: code: https://github.com/krummas/cassandra/commits/stefan/14806-3.11
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-3.11
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722988#comment-16722988
]
Marcus Eriksson edited comment on CASSANDRA-14806 at 12/17/18 1:44 PM:
---
2.2:
code: https://github.com/krummas/cassandra/commits/stefan/14806-2.2
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-2.2
reference run (unpatched 2.2):
https://circleci.com/workflow-run/bf69001c-756b-4c43-a754-652066dca07f
3.0
code: https://github.com/krummas/cassandra/commits/stefan/14806-3.0
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-3.0
3.11
code: https://github.com/krummas/cassandra/commits/stefan/14806-3.11
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-3.11
was (Author: krummas):
2.2:
code: https://github.com/krummas/cassandra/commits/stefan/14806-2.2
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-2.2
reference run (unpatched 2.2):
https://circleci.com/workflow-run/bf69001c-756b-4c43-a754-652066dca07f
3.0
code: https://github.com/krummas/cassandra/commits/stefan/14806-3.0
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-3.0
3.11
code: code: https://github.com/krummas/cassandra/commits/stefan/14806-3.11
test runs:
https://circleci.com/gh/krummas/workflows/cassandra/tree/stefan%2F14806-3.11
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14938) Use a stub IndexRegistry when initialised in non-daemon mode
[
https://issues.apache.org/jira/browse/CASSANDRA-14938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14938:
Reviewers: Marcus Eriksson
> Use a stub IndexRegistry when initialised in non-daemon mode
>
>
> Key: CASSANDRA-14938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14938
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL, Testing
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 4.0
>
>
> Offline processing of FQL logs for workload analysis or replay testing would
> benefit from being able to use C* as a library for parsing and preparation of
> the recorded CQL queries. One thing which makes this difficult is that
> preparing CQL statements involves validating any index restrictions via the
> {{IndexRegistry}} which means instantiating a {{ColumnFamilyStore}}, which
> has several side effects that are troublesome in an offline environment.
> In the FQL processing use case this validation is unnecessary and I imagine
> this is true for most, if not all, offline tools. In these cases, we could
> use a stub {{IndexRegistry}} which enables validation to succeed, but which
> doesn't provide any real functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
