[jira] [Commented] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056615#comment-17056615 ] Jacob Becker commented on CASSANDRA-15623: -- [~djoshi], [~jrwest], no problem submitting against trunk. Since my local (i.e. source) branches were named after the target branches, to avoid any possible confusion, I have created a *new* dedicated PR against trunk: https://github.com/apache/cassandra/pull/468 Please do your review using the [new PR|https://github.com/apache/cassandra/pull/468]. In case changes are accepted, the [original PR|https://github.com/apache/cassandra/pull/467] can serve as a backport to 3.11. To explain myself, I had initially submitted against 3.11 because: * I have been testing against that version; * I had assumed it was OK to submit against 3.11 since it was actually a bug fix; I will keep the clarified workflow in mind, thanks. > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Assignee: Jacob Becker >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-15623: --- Labels: pull-request-available (was: ) > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Assignee: Jacob Becker >Priority: Normal > Labels: pull-request-available > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056557#comment-17056557 ] David Capwell commented on CASSANDRA-15564: --- Pushed the change so IMessageFilters has inbound and outbound. > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 16.5h > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056553#comment-17056553
]
David Capwell commented on CASSANDRA-15564:
---
bq. I'm wondering whether we should stick to runInbound in builder, or we
should switch to `filters().inbound()` or something similar, where `filters()`
would return some interface that has `inbound` and `outbound`. This could even
leave most of the things more or less same implementation-wise.
Oh I think you mean
org.apache.cassandra.distributed.api.IMessageFilters should have a
inbound/outbound method which returns a builder. Do we still have those
methods on the builder? If so I could do the following
{code}
Builder inbound(boolean inbound);
default Builder inbound() {
return inbound(true);
}
default Builder outbound() {
return inbound(false);
}
default Builder verbs(int... verbs) {
return inbound().verbs(verbs);
}
default Builder allVerbs() {
return inbound().allVerbs();
}
{code}
> Refactor repair coordinator so errors are consistent
>
>
> Key: CASSANDRA-15564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15564
> Project: Cassandra
> Issue Type: Sub-task
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 16.5h
> Remaining Estimate: 0h
>
> This is to split the change in CASSANDRA-15399 so the refactor is isolated
> out.
> Currently the repair coordinator special cases the exit cases at each call
> site; this makes it so that errors can be inconsistent and there are cases
> where proper complete isn't done (proper notifications, and forgetting to
> update ActiveRepairService).
> [Circle
> CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15595) Many errors of "java.lang.AssertionError: Illegal bounds"
[
https://issues.apache.org/jira/browse/CASSANDRA-15595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056550#comment-17056550
]
Brandon Williams commented on CASSANDRA-15595:
--
If you can provide a simple reproduction, that will go a long way. Currently
I'm not able to reproduce and none of the tests are encountering it.
> Many errors of "java.lang.AssertionError: Illegal bounds"
> -
>
> Key: CASSANDRA-15595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15595
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Caching
>Reporter: Yakir Gibraltar
>Priority: Normal
> Fix For: 3.11.7
>
>
> Hi, i'm running cassandra 3.11.6 and getting on all hosts many errors of:
> {code}
> ERROR [ReadStage-6] 2020-02-24 13:53:34,528
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[ReadStage-6,5,main]
> java.lang.AssertionError: Illegal bounds [-2102982480..-2102982472); size:
> 2761628520
> at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:345)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at org.apache.cassandra.io.util.Memory.getLong(Memory.java:254)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.compress.CompressionMetadata.chunkFor(CompressionMetadata.java:234)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:114)
> ~[apache-cassandra-3.11.6.ja
> r:3.11.6]
> at org.apache.cassandra.cache.ChunkCache.load(ChunkCache.java:158)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at org.apache.cassandra.cache.ChunkCache.load(ChunkCache.java:39)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache$BoundedLocalLoadingCache.lambda$new$0(BoundedLocalCache.java:2949)
> ~[caffeine-2.2.6.jar:na]
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$15(BoundedLocalCache.java:1807)
> ~[caffeine-2.2.6.jar:na]
> at
> java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1853)
> ~[na:1.8.0-zing_19.12.102.0]
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:1805)
> ~[caffeine-2.2.6.jar:na]
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:1788)
> ~[caffeine-2.2.6.jar:na]
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:97)
> ~[caffeine-2.2.6.jar:na]
> at
> com.github.benmanes.caffeine.cache.LocalLoadingCache.get(LocalLoadingCache.java:66)
> ~[caffeine-2.2.6.jar:na]
> at
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.rebuffer(ChunkCache.java:236)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.rebuffer(ChunkCache.java:214)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:65)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:207)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:150)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.getFileDataInput(SSTableReader.java:1807)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.(AbstractSSTableIterator.java:103)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.db.columniterator.SSTableIterator.(SSTableIterator.java:49)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:72)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:65)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.db.StorageHook$1.makeRowIterator(StorageHook.java:100)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder(SinglePartitionReadCommand.java:982)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:693)
> ~[apache-cassandra-3.11.6.jar:3.11.6]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:670)
>
[jira] [Commented] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056538#comment-17056538 ] David Capwell commented on CASSANDRA-15564: --- bq. we also need to change the initialization order to make sure outbound message sending is wrapping fake messaging and not vice versa. done. bq. I'm wondering whether we should stick to runInbound in builder, or we should switch to `filters().inbound()` or something similar, where `filters()` would return some interface that has `inbound` and `outbound`. This could even leave most of the things more or less same implementation-wise. I don't follow, are you asking I rename runInbound to inbound and runOutbound to outbound? I feel like you are saying more but don't follow. bq. Should we add a test that ensures the order (in other words, any message first goes through outbound, and only then through inbound filter)? I was using the preview repair tests to do that but the test is racy if filters don't work which make the test pass... aka can't rely on it =(. Ill add a test > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 16.5h > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056534#comment-17056534 ] David Capwell commented on CASSANDRA-15564: --- [~ifesdjeen] [~jasonstack] replied to all feedback. > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 16.5h > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056525#comment-17056525
]
Brandon Williams commented on CASSANDRA-15614:
--
bq. keep the ticket open for the exploration of in-jvm better version later.
Let's use a new ticket for that.
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: test_resumable_bootstrap-CASSANDRA-15614.txt
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if we have a process to check, then check it.*
> *# Skip on Windows - stdout/stderr is
[jira] [Updated] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15614:
-
Since Version: 2.2.0 beta 1
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/2278fb50daaae262960811a636b3182e5d36d439
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks!
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: test_resumable_bootstrap-CASSANDRA-15614.txt
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if
[jira] [Updated] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15614:
-
Reviewers: Brandon Williams, Jordan West (was: Brandon Williams, Brandon
Williams, Jordan West)
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: test_resumable_bootstrap-CASSANDRA-15614.txt
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if we have a process to check, then check it.*
> *# Skip on Windows - stdout/stderr is cassandra.bat*
> *if not common.is_win() and
[jira] [Updated] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15614:
-
Reviewers: Brandon Williams, Jordan West, Brandon Williams (was: Brandon
Williams, Brandon Williams, Jordan West)
Brandon Williams, Jordan West, Brandon Williams
Status: Review In Progress (was: Patch Available)
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: test_resumable_bootstrap-CASSANDRA-15614.txt
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if we have a process to
[jira] [Updated] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15614:
-
Status: Ready to Commit (was: Review In Progress)
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: test_resumable_bootstrap-CASSANDRA-15614.txt
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if we have a process to check, then check it.*
> *# Skip on Windows - stdout/stderr is cassandra.bat*
> *if not common.is_win() and not output_read:*
> *if
[cassandra-dtest] branch master updated: Fix test_resumable_bootstrap
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new 2278fb5 Fix test_resumable_bootstrap
2278fb5 is described below
commit 2278fb50daaae262960811a636b3182e5d36d439
Author: Ekaterina Dimitrova
AuthorDate: Fri Mar 6 14:36:57 2020 -0500
Fix test_resumable_bootstrap
Patch by Ekaterina Dimitrova, reviewed by Jordan West and
brandonwilliams for CASSANDRA-15614
---
bootstrap_test.py | 63 ++-
1 file changed, 11 insertions(+), 52 deletions(-)
diff --git a/bootstrap_test.py b/bootstrap_test.py
index f866742..d22599f 100644
--- a/bootstrap_test.py
+++ b/bootstrap_test.py
@@ -336,50 +336,6 @@ class TestBootstrap(Tester):
assert_not_running(node3)
@since('2.2')
-def test_resumable_bootstrap(self):
-"""
-Test resuming bootstrap after data streaming failure
-"""
-cluster = self.cluster
-cluster.populate(2)
-
-node1 = cluster.nodes['node1']
-# set up byteman
-node1.byteman_port = '8100'
-node1.import_config_files()
-
-cluster.start(wait_other_notice=True)
-# kill stream to node3 in the middle of streaming to let it fail
-if cluster.version() < '4.0':
-node1.byteman_submit([self.byteman_submit_path_pre_4_0])
-else:
-node1.byteman_submit([self.byteman_submit_path_4_0])
-node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
'replication(factor=2)', '-rate', 'threads=50'])
-cluster.flush()
-
-# start bootstrapping node3 and wait for streaming
-node3 = new_node(cluster)
-node3.start(wait_other_notice=False)
-
-# let streaming fail as we expect
-node3.watch_log_for('Some data streaming failed')
-
-# bring back node3 and invoke nodetool bootstrap to resume
bootstrapping
-node3.nodetool('bootstrap resume')
-node3.wait_for_binary_interface()
-assert_bootstrap_state(self, node3, 'COMPLETED')
-
-# cleanup to guarantee each node will only have sstables of its ranges
-cluster.cleanup()
-
-logger.debug("Check data is present")
-# Let's check stream bootstrap completely transferred data
-stdout, stderr, _ = node3.stress(['read', 'n=1k', 'no-warmup',
'-schema', 'replication(factor=2)', '-rate', 'threads=8'])
-
-if stdout is not None:
-assert "FAILURE" not in stdout
-
-@since('2.2')
def test_bootstrap_with_reset_bootstrap_state(self):
"""Test bootstrap with resetting bootstrap progress"""
cluster = self.cluster
@@ -752,10 +708,13 @@ class TestBootstrap(Tester):
shutil.rmtree(commitlog_dir)
@since('2.2')
-def test_bootstrap_binary_disabled(self):
+def test_bootstrap_binary_disabled_resumable_bootstrap(self):
"""
Test binary while bootstrapping and streaming fails
@jira_ticket CASSANDRA-14526, CASSANDRA-14525
+Test resumable bootstrap
+In very rare cases this test might fail because the bootstrap
completes before the streaming failure
+@jira_ticket CASSANDRA-15614
"""
config = {'authenticator':
'org.apache.cassandra.auth.PasswordAuthenticator',
'authorizer':
'org.apache.cassandra.auth.CassandraAuthorizer',
@@ -786,8 +745,8 @@ class TestBootstrap(Tester):
node2.byteman_port = '8101' # set for when we add node3
node2.import_config_files()
node2.start(jvm_args=["-Dcassandra.ring_delay_ms=5000"],
wait_other_notice=True)
-self.assert_log_had_msg(node2, 'Some data streaming failed',
timeout=30)
-self.assert_log_had_msg(node2, 'Not starting client transports as
bootstrap has not completed', timeout=30)
+self.assert_log_had_msg(node2, 'Some data streaming failed')
+self.assert_log_had_msg(node2, 'Not starting client transports as
bootstrap has not completed')
try:
node2.nodetool('join')
@@ -811,8 +770,8 @@ class TestBootstrap(Tester):
node1.byteman_submit([self.byteman_submit_path_4_0])
node2.byteman_submit([self.byteman_submit_path_4_0])
node3.start(jvm_args=["-Dcassandra.write_survey=true",
"-Dcassandra.ring_delay_ms=5000"], wait_other_notice=True)
-self.assert_log_had_msg(node3, 'Some data streaming failed',
timeout=30)
-self.assert_log_had_msg(node3, "Not starting client transports in
write_survey mode as it's bootstrapping or auth is enabled", timeout=30)
+self.assert_log_had_msg(node3, 'Some data streaming failed')
+self.assert_log_had_msg(node3, "Not starting client transports in
write_survey mode as it's bootstrapping or auth is enabled")
[jira] [Commented] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056456#comment-17056456
]
Ekaterina Dimitrova commented on CASSANDRA-15614:
-
Thanks [~jrwest]
As we talked on slack, we will commit this one for now and keep the ticket open
for the exploration of in-jvm better version later. Thanks!
[~brandon.williams], can you, please commit this patch?
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: test_resumable_bootstrap-CASSANDRA-15614.txt
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if
[jira] [Commented] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056421#comment-17056421
]
Jordan West commented on CASSANDRA-15614:
-
Thanks for the diagnosis [~e.dimitrova]. Have you thought about converting the
test to in-jvm dtest? Perhaps, we could have more control and get rid of the
flakiness? It would also allow us to make better assertions about streaming
failure than just "is it in the logs". Then we could safely delete the
old/dtest versions.
I'd have to look at this test closer to think about ways to make it 100% solid
w/in dest. Unfortunately, from the dtest level I'm not sure we have the control
we need.
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: test_resumable_bootstrap-CASSANDRA-15614.txt
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
>
[jira] [Commented] (CASSANDRA-15584) 4.0 quality testing: Tooling - External Ecosystem
[ https://issues.apache.org/jira/browse/CASSANDRA-15584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056412#comment-17056412 ] Sumanth Pasupuleti commented on CASSANDRA-15584: I agree [~jrwest]. I am focusing on validating integration with Priam. > 4.0 quality testing: Tooling - External Ecosystem > - > > Key: CASSANDRA-15584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15584 > Project: Cassandra > Issue Type: Task >Reporter: Josh McKenzie >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-rc > > > Many users of Apache Cassandra employ open source tooling to automate > Cassandra configuration, runtime management, and repair scheduling. Prior to > release, we need to confirm that popular third-party tools such as Reaper, > Priam, etc. function properly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15582) 4.0 quality testing: metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056346#comment-17056346 ] Jordan West commented on CASSANDRA-15582: - Thanks [~djoshi] [~dcapwell]. I agree with [~dcapwell] that 1 & 2 should be requirements (and seem relatively low hanging in terms of work). Regarding #3, I think a prioritized list (coming from 1 & 2) would be a good start. Should we create JIRAs for at least the first two? > 4.0 quality testing: metrics > > > Key: CASSANDRA-15582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15582 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Romain Hardouin >Priority: Normal > Fix For: 4.0-rc > > > In past releases we've unknowingly broken metrics integrations and introduced > performance regressions in metrics collection and reporting. We strive in 4.0 > to not do that. Metrics should work well! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056278#comment-17056278
]
Ekaterina Dimitrova edited comment on CASSANDRA-15543 at 3/10/20, 7:27 PM:
---
Hi Kevin,
"In any case, I believe passing an immutable copy of the
{{failureReasonByEndpoint}} map to the constructor of
Read/WriteFailureException would reduce the chances for the {{number of
failures}} and the failure messages to be inconsistent."
Agree with you. I would personally expect 1 response from node1 where the
schema was altered and two failures with the two messages.
"In addition to that, there's the remaining question of the behavior of
ReadCallback when failures happen (do we fail fast? or do we wait for all
responses to come back/timeout?). Depending on the outcome of that, the test
that is flaky at the moment would need to be adjusted to expect 1 *or* 2
failures in the response."
Or we can say "as soon as it fails more than 0 times" and be safe?
This is my personal interpretation.
I believe [~ifesdjeen] would be the best person to confirm any details but for
test fix this would be enough I think to make it deterministic. I don't see a
bug but confusing responses to the user (same as you, as we discussed on Slack)
was (Author: e.dimitrova):
Hi Kevin,
"In any case, I believe passing an immutable copy of the
{{failureReasonByEndpoint}} map to the constructor of
Read/WriteFailureException would reduce the chances for the {{number of
failures}} and the failure messages to be inconsistent."
Agree with you. I would personally expect 1 response from node1 where the
schema was altered and two failures with the two messages.
"In addition to that, there's the remaining question of the behavior of
ReadCallback when failures happen (do we fail fast? or do we wait for all
responses to come back/timeout?). Depending on the outcome of that, the test
that is flaky at the moment would need to be adjusted to expect 1 *or* 2
failures in the response."
Or we can say "as soon as it fails more than 0 times" and be safe?
This is my personal interpretation.
I believe [~ifesdjeen] would be the best person to confirm any details but for
test fix this would be enough. I don't see a bug but confusing responses to the
user (same as you, as we discussed on Slack)
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056278#comment-17056278
]
Ekaterina Dimitrova edited comment on CASSANDRA-15543 at 3/10/20, 7:26 PM:
---
Hi Kevin,
"In any case, I believe passing an immutable copy of the
{{failureReasonByEndpoint}} map to the constructor of
Read/WriteFailureException would reduce the chances for the {{number of
failures}} and the failure messages to be inconsistent."
Agree with you. I would personally expect 1 response from node1 where the
schema was altered and two failures with the two messages.
"In addition to that, there's the remaining question of the behavior of
ReadCallback when failures happen (do we fail fast? or do we wait for all
responses to come back/timeout?). Depending on the outcome of that, the test
that is flaky at the moment would need to be adjusted to expect 1 *or* 2
failures in the response."
Or we can say "as soon as it fails more than 0 times" and be safe?
This is my personal interpretation.
I believe [~ifesdjeen] would be the best person to confirm any details but for
test fix this would be enough. I don't see a bug but confusing responses to the
user (same as you, as we discussed on Slack)
was (Author: e.dimitrova):
Hi Kevin,
"In any case, I believe passing an immutable copy of the
{{failureReasonByEndpoint}} map to the constructor of
Read/WriteFailureException would reduce the chances for the {{number of
failures}} and the failure messages to be inconsistent."
Agree with you. I would personally expect 1 response from node1 where the
schema was altered and two failures with the two messages.
"In addition to that, there's the remaining question of the behavior of
ReadCallback when failures happen (do we fail fast? or do we wait for all
responses to come back/timeout?). Depending on the outcome of that, the test
that is flaky at the moment would need to be adjusted to expect 1 *or* 2
failures in the response."
Or we can say "as soon as it fails more than 0 times" and be safe?
This is my personal interpretation.
I believe [~ifesdjeen] would be the best person to confirm any details.
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki edited comment on CASSANDRA-15453 at 3/10/20, 7:11 PM:
---
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
Attempt with cassandra-driver-core 3.6.0 failed
([log|https://gist.github.com/suztomo/20e16ad85b019b919f7b148eab652f30]).
Notables:
{noformat}
[junit-timeout] Testcase:
testGroupByWithRangeNamesQueryWithPaging(org.apache.cassandra.cql3.validation.operations.SelectGroupByTest):
Caused an ERROR
[junit-timeout] Can not use V5 protocol version. Newest supported protocol
version is: V4. For beta versions, use `allowBetaProtocolVersion` instead
[junit-timeout] Testcase:
testJavascriptUserType(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of 'cql_test_keyspace.function_43[type_41]' failed:
java.lang.RuntimeException: java.lang.NoClassDefFoundError: Could not
initialize class com.datastax.driver.core.Metadata
[junit-timeout] Testcase:
testJavascriptUTCollections(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of
'cql_test_keyspace.function_6[list>]' failed:
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
[junit-timeout] Testcase:
testNoArgs(org.apache.cassandra.tools.CompactionStressTest): Caused an ERROR
[junit-timeout] java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] Testcase:
testCustomIndexExpressionSyntax(org.apache.cassandra.index.CustomIndexTest):
FAILED
[junit-timeout] Query should be invalid but wrong error was thrown. Expected:
com.datastax.driver.core.exceptions.QueryValidationException, got:
java.lang.IllegalArgumentException. Query is: SELECT * FROM %s WHERE
expr(no_such_index, 'foo bar baz ') (values: [])
{noformat}
The older version used in trunk
- 3.6.0 on [Apr 10,
2018|https://github.com/apache/cassandra/commit/38b49904dd1c71fcb16abfbc205edfd6ce008b76]
- 3.4.0-SNAPSHOT on [Feb 1,
2018|https://github.com/apache/cassandra/blame/e8ff2f2b8ebb3990b99c81f839f6463bbff381f4/build.xml]
- 4.0.0-SNAPSHOT on [Nov 9,
2017|https://github.com/apache/cassandra/blame/59a4624d5f9b2c414b200e65b45beed9c5f4db52/build.xml]
- 3.0.1 on [May 23,
2016|https://github.com/apache/cassandra/blame/4de7a65ed9f3c97658a80dd64032ad6e82e9d58b/build.xml]
Attemtp with cassandra-driver-core 3.4.0 failed (). Notables:
{noformat}
[junit-timeout] Testcase: org.apache.cassandra.cql3.ViewTest: Caused an ERROR
[junit-timeout]
com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;
[junit-timeout] java.lang.NoSuchMethodError:
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki edited comment on CASSANDRA-15453 at 3/10/20, 7:10 PM:
---
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
Attempt with cassandra-driver-core 3.6.0 failed
([log|https://gist.github.com/suztomo/20e16ad85b019b919f7b148eab652f30]).
Notables:
{noformat}
[junit-timeout] Testcase:
testGroupByWithRangeNamesQueryWithPaging(org.apache.cassandra.cql3.validation.operations.SelectGroupByTest):
Caused an ERROR
[junit-timeout] Can not use V5 protocol version. Newest supported protocol
version is: V4. For beta versions, use `allowBetaProtocolVersion` instead
[junit-timeout] Testcase:
testJavascriptUserType(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of 'cql_test_keyspace.function_43[type_41]' failed:
java.lang.RuntimeException: java.lang.NoClassDefFoundError: Could not
initialize class com.datastax.driver.core.Metadata
[junit-timeout] Testcase:
testJavascriptUTCollections(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of
'cql_test_keyspace.function_6[list>]' failed:
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
[junit-timeout] Testcase:
testNoArgs(org.apache.cassandra.tools.CompactionStressTest): Caused an ERROR
[junit-timeout] java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] Testcase:
testCustomIndexExpressionSyntax(org.apache.cassandra.index.CustomIndexTest):
FAILED
[junit-timeout] Query should be invalid but wrong error was thrown. Expected:
com.datastax.driver.core.exceptions.QueryValidationException, got:
java.lang.IllegalArgumentException. Query is: SELECT * FROM %s WHERE
expr(no_such_index, 'foo bar baz ') (values: [])
{noformat}
The older version used in trunk
- 3.6.0 on [Apr 10,
2018|https://github.com/apache/cassandra/commit/38b49904dd1c71fcb16abfbc205edfd6ce008b76]
- 3.4.0-SNAPSHOT on [Feb 1,
2018|https://github.com/apache/cassandra/blame/e8ff2f2b8ebb3990b99c81f839f6463bbff381f4/build.xml]
- 4.0.0-SNAPSHOT on [Nov 9,
2017|https://github.com/apache/cassandra/blame/59a4624d5f9b2c414b200e65b45beed9c5f4db52/build.xml]
- 3.0.1 on [May 23,
2016|https://github.com/apache/cassandra/blame/4de7a65ed9f3c97658a80dd64032ad6e82e9d58b/build.xml]
Attemtp with cassandra-driver-core 3.4.0 failed (). Notables:
{noformat}
[junit-timeout] Testcase: org.apache.cassandra.cql3.ViewTest: Caused an ERROR
[junit-timeout]
com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;
[junit-timeout] java.lang.NoSuchMethodError:
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki edited comment on CASSANDRA-15453 at 3/10/20, 7:01 PM:
---
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
Attempt with cassandra-driver-core 3.6.0 failed
([log|https://gist.github.com/suztomo/20e16ad85b019b919f7b148eab652f30]).
Notables:
{noformat}
[junit-timeout] Testcase:
testGroupByWithRangeNamesQueryWithPaging(org.apache.cassandra.cql3.validation.operations.SelectGroupByTest):
Caused an ERROR
[junit-timeout] Can not use V5 protocol version. Newest supported protocol
version is: V4. For beta versions, use `allowBetaProtocolVersion` instead
[junit-timeout] Testcase:
testJavascriptUserType(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of 'cql_test_keyspace.function_43[type_41]' failed:
java.lang.RuntimeException: java.lang.NoClassDefFoundError: Could not
initialize class com.datastax.driver.core.Metadata
[junit-timeout] Testcase:
testJavascriptUTCollections(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of
'cql_test_keyspace.function_6[list>]' failed:
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
[junit-timeout] Testcase:
testNoArgs(org.apache.cassandra.tools.CompactionStressTest): Caused an ERROR
[junit-timeout] java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] Testcase:
testCustomIndexExpressionSyntax(org.apache.cassandra.index.CustomIndexTest):
FAILED
[junit-timeout] Query should be invalid but wrong error was thrown. Expected:
com.datastax.driver.core.exceptions.QueryValidationException, got:
java.lang.IllegalArgumentException. Query is: SELECT * FROM %s WHERE
expr(no_such_index, 'foo bar baz ') (values: [])
{noformat}
The older version used in trunk
- 3.6.0 on [Apr 10,
2018|https://github.com/apache/cassandra/commit/38b49904dd1c71fcb16abfbc205edfd6ce008b76]
- 3.4.0-SNAPSHOT on [Feb 1,
2018|https://github.com/apache/cassandra/blame/e8ff2f2b8ebb3990b99c81f839f6463bbff381f4/build.xml]
- 4.0.0-SNAPSHOT on [Nov 9,
2017|https://github.com/apache/cassandra/blame/59a4624d5f9b2c414b200e65b45beed9c5f4db52/build.xml]
- 3.0.1 on [May 23,
2016|https://github.com/apache/cassandra/blame/4de7a65ed9f3c97658a80dd64032ad6e82e9d58b/build.xml]
was (Author: suztomo):
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
[jira] [Commented] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056278#comment-17056278
]
Ekaterina Dimitrova commented on CASSANDRA-15543:
-
Hi Kevin,
"In any case, I believe passing an immutable copy of the
{{failureReasonByEndpoint}} map to the constructor of
Read/WriteFailureException would reduce the chances for the {{number of
failures}} and the failure messages to be inconsistent."
Agree with you. I would personally expect 1 response from node1 where the
schema was altered and two failures with the two messages.
"In addition to that, there's the remaining question of the behavior of
ReadCallback when failures happen (do we fail fast? or do we wait for all
responses to come back/timeout?). Depending on the outcome of that, the test
that is flaky at the moment would need to be adjusted to expect 1 *or* 2
failures in the response."
Or we can say "as soon as it fails more than 0 times" and be safe?
This is my personal interpretation.
I believe [~ifesdjeen] would be the best person to confirm any details.
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15550) Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest testFailSessionDuringTransferShouldNotReleaseReferences
[
https://issues.apache.org/jira/browse/CASSANDRA-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056258#comment-17056258
]
Dinesh Joshi commented on CASSANDRA-15550:
--
ok, finally got around to reviewing this on a *Tuesday* ;). The only feedback
is limit the number of retries to some finite value (like 3, 5 or 10) and abort
the test if streaming doesn't complete (abort) within those retries. You can
fix this on commit if you'd like.
> Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest
> testFailSessionDuringTransferShouldNotReleaseReferences
>
>
> Key: CASSANDRA-15550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15550
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.streaming.StreamTransferTaskTest.testFailSessionDuringTransferShouldNotReleaseReferences(StreamTransferTaskTest.java:181)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure was on java 11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15550) Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest testFailSessionDuringTransferShouldNotReleaseReferences
[
https://issues.apache.org/jira/browse/CASSANDRA-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15550:
-
Status: In Progress (was: Patch Available)
> Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest
> testFailSessionDuringTransferShouldNotReleaseReferences
>
>
> Key: CASSANDRA-15550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15550
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.streaming.StreamTransferTaskTest.testFailSessionDuringTransferShouldNotReleaseReferences(StreamTransferTaskTest.java:181)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure was on java 11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15550) Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest testFailSessionDuringTransferShouldNotReleaseReferences
[
https://issues.apache.org/jira/browse/CASSANDRA-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15550:
-
Status: Changes Suggested (was: Review In Progress)
> Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest
> testFailSessionDuringTransferShouldNotReleaseReferences
>
>
> Key: CASSANDRA-15550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15550
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.streaming.StreamTransferTaskTest.testFailSessionDuringTransferShouldNotReleaseReferences(StreamTransferTaskTest.java:181)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure was on java 11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15550) Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest testFailSessionDuringTransferShouldNotReleaseReferences
[
https://issues.apache.org/jira/browse/CASSANDRA-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15550:
-
Status: Patch Available (was: In Progress)
> Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest
> testFailSessionDuringTransferShouldNotReleaseReferences
>
>
> Key: CASSANDRA-15550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15550
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.streaming.StreamTransferTaskTest.testFailSessionDuringTransferShouldNotReleaseReferences(StreamTransferTaskTest.java:181)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure was on java 11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15550) Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest testFailSessionDuringTransferShouldNotReleaseReferences
[
https://issues.apache.org/jira/browse/CASSANDRA-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15550:
-
Reviewers: Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi)
Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi)
Status: Review In Progress (was: Patch Available)
> Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest
> testFailSessionDuringTransferShouldNotReleaseReferences
>
>
> Key: CASSANDRA-15550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15550
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.streaming.StreamTransferTaskTest.testFailSessionDuringTransferShouldNotReleaseReferences(StreamTransferTaskTest.java:181)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure was on java 11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15582) 4.0 quality testing: metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056254#comment-17056254 ] David Capwell commented on CASSANDRA-15582: --- In short diff metric names? Not ambitious enough for me ;) I’m finding that 3.x disk metrics are inaccurate (Marcus is looking at parts, when I get time I’ll fix other issues), Jordan pointed out the need to verify a performance changes impact on metric quality; for me there are a few things 1) diff metrics names (did we remove something? Change name is a remove) 2) diff metric signature (Used to return long but now string, used to take no arguments but now takes string, etc) 3) metric value accuracy #1 and #2 are a api compatibility test where as #3 is a metrics quality test. For #3 I care less about new metrics than metrics people use in prod (new metrics should be tested as well but don’t break users if wrong), so #3 may need feedback on what metrics people monitor > 4.0 quality testing: metrics > > > Key: CASSANDRA-15582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15582 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Romain Hardouin >Priority: Normal > Fix For: 4.0-rc > > > In past releases we've unknowingly broken metrics integrations and introduced > performance regressions in metrics collection and reporting. We strive in 4.0 > to not do that. Metrics should work well! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056242#comment-17056242 ] Dinesh Joshi commented on CASSANDRA-15539: -- [~ifesdjeen] i went through the patches and they seem ok so overall I am +1 on it. I don't have strong opinions on the way these patches are being orchestrated for review. If there are minor issues that need to be addressed lets fix them here. However, I am also ok fixing them as follow on patches to this ticket. Rebasing 4 branches in sync is very cumbersome. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15582) 4.0 quality testing: metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056213#comment-17056213 ] Dinesh Joshi edited comment on CASSANDRA-15582 at 3/10/20, 6:16 PM: Here's the outline of my plan. We should enumerate all metrics being published in 3.0 and 3.11. We should verify if those metrics are present in 4.0 and if we deviate from that list (and we will), we should document the difference. Ideally, we should have some automated way of pulling all the metrics out so we can detect changes in the list of published metrics in an automated way. Since we publish all metrics via JMX, I think it is doable. Does this sound too ambitious? One of the issues to watch out for is that we publish some metrics when certain features are used. This means we should try to trigger all code paths that are known to publish specific metrics. was (Author: djoshi3): Here's the outline of my plan. We should enumerate all metrics being published in 3.0 and 3.11. We should verify if those metrics are present in 4.0 and if we deviate from that list (and we will), we should document the difference. Ideally, we should have some automated way of pulling all the metrics out so we can detect changes in the list of published metrics in an automated way. Since we publish all metrics via JMX, I think it is doable. Does this sound too ambitious? > 4.0 quality testing: metrics > > > Key: CASSANDRA-15582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15582 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Romain Hardouin >Priority: Normal > Fix For: 4.0-rc > > > In past releases we've unknowingly broken metrics integrations and introduced > performance regressions in metrics collection and reporting. We strive in 4.0 > to not do that. Metrics should work well! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15582) 4.0 quality testing: metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056213#comment-17056213 ] Dinesh Joshi commented on CASSANDRA-15582: -- Here's the outline of my plan. We should enumerate all metrics being published in 3.0 and 3.11. We should verify if those metrics are present in 4.0 and if we deviate from that list (and we will), we should document the difference. Ideally, we should have some automated way of pulling all the metrics out so we can detect changes in the list of published metrics in an automated way. Since we publish all metrics via JMX, I think it is doable. Does this sound too ambitious? > 4.0 quality testing: metrics > > > Key: CASSANDRA-15582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15582 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Romain Hardouin >Priority: Normal > Fix For: 4.0-rc > > > In past releases we've unknowingly broken metrics integrations and introduced > performance regressions in metrics collection and reporting. We strive in 4.0 > to not do that. Metrics should work well! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15629) Fix flakey testSendSmall - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15629:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flakey testSendSmall - org.apache.cassandra.net.ConnectionTest
> --
>
> Key: CASSANDRA-15629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15629
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> processed count values don't match expected:<10> but was:<9>
> junit.framework.AssertionFailedError: processed count values don't match
> expected:<10> but was:<9>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSendSmall$11(ConnectionTest.java:305)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
> at
> org.apache.cassandra.net.ConnectionTest.testSendSmall(ConnectionTest.java:277)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15630) Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15630:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
> ---
>
> Key: CASSANDRA-15630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15630
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> processed count values don't match expected:<90> but was:<89>
> junit.framework.AssertionFailedError: processed count values don't match
> expected:<90> but was:<89>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSerializeError$24(ConnectionTest.java:494)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:240)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:260)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:238)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:227)
> at
> org.apache.cassandra.net.ConnectionTest.testSerializeError(ConnectionTest.java:435){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15628) Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15628:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
> --
>
> Key: CASSANDRA-15628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15628
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> received count values don't match expected:<10> but was:<9>
> junit.framework.AssertionFailedError: received count values don't match
> expected:<10> but was:<9>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:212)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSendLarge$15(ConnectionTest.java:359)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
> at
> org.apache.cassandra.net.ConnectionTest.testSendLarge(ConnectionTest.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056175#comment-17056175 ] Dinesh Joshi edited comment on CASSANDRA-15623 at 3/10/20, 5:42 PM: [~plastikat] thanks for your patch. I can take a look at it this week. BTW, I see you've submitted a patch against 3.11. 3.11 is in bugfix only mode so your patch should be against trunk. was (Author: djoshi3): [~plastikat] thanks for your patch. I can take a look at it this week. > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Assignee: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15623: - Reviewers: Dinesh Joshi, Jordan West, Dinesh Joshi (was: Dinesh Joshi, Jordan West) Dinesh Joshi, Jordan West, Dinesh Joshi Status: Review In Progress (was: Patch Available) [~plastikat] thanks for your patch. I can take a look at it this week. > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi reassigned CASSANDRA-15623: Assignee: Jacob Becker > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Assignee: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki edited comment on CASSANDRA-15453 at 3/10/20, 5:26 PM:
---
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
Attempt with cassandra-driver-core 3.6.0 failed
([log|https://gist.github.com/suztomo/20e16ad85b019b919f7b148eab652f30]).
Notables:
{noformat}
[junit-timeout] Testcase:
testGroupByWithRangeNamesQueryWithPaging(org.apache.cassandra.cql3.validation.operations.SelectGroupByTest):
Caused an ERROR
[junit-timeout] Can not use V5 protocol version. Newest supported protocol
version is: V4. For beta versions, use `allowBetaProtocolVersion` instead
[junit-timeout] Testcase:
testJavascriptUserType(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of 'cql_test_keyspace.function_43[type_41]' failed:
java.lang.RuntimeException: java.lang.NoClassDefFoundError: Could not
initialize class com.datastax.driver.core.Metadata
[junit-timeout] Testcase:
testJavascriptUTCollections(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of
'cql_test_keyspace.function_6[list>]' failed:
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
[junit-timeout] Testcase:
testNoArgs(org.apache.cassandra.tools.CompactionStressTest): Caused an ERROR
[junit-timeout] java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] Testcase:
testCustomIndexExpressionSyntax(org.apache.cassandra.index.CustomIndexTest):
FAILED
[junit-timeout] Query should be invalid but wrong error was thrown. Expected:
com.datastax.driver.core.exceptions.QueryValidationException, got:
java.lang.IllegalArgumentException. Query is: SELECT * FROM %s WHERE
expr(no_such_index, 'foo bar baz ') (values: [])
{noformat}
was (Author: suztomo):
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder'
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki edited comment on CASSANDRA-15453 at 3/10/20, 5:25 PM:
---
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
Attempt with cassandra-driver-core 3.6.0 failed
([log|https://gist.github.com/suztomo/20e16ad85b019b919f7b148eab652f30]):
{noformat}
[junit-timeout] Testcase:
testGroupByWithRangeNamesQueryWithPaging(org.apache.cassandra.cql3.validation.operations.SelectGroupByTest):
Caused an ERROR
[junit-timeout] Can not use V5 protocol version. Newest supported protocol
version is: V4. For beta versions, use `allowBetaProtocolVersion` instead
[junit-timeout] Testcase:
testJavascriptUserType(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of 'cql_test_keyspace.function_43[type_41]' failed:
java.lang.RuntimeException: java.lang.NoClassDefFoundError: Could not
initialize class com.datastax.driver.core.Metadata
[junit-timeout] Testcase:
testJavascriptUTCollections(org.apache.cassandra.cql3.validation.entities.UFPureScriptTest):
Caused an ERROR
[junit-timeout] execution of
'cql_test_keyspace.function_6[list>]' failed:
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
[junit-timeout] Testcase:
testNoArgs(org.apache.cassandra.tools.CompactionStressTest): Caused an ERROR
[junit-timeout] java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.apache.cassandra.stress.CompactionStress
[junit-timeout] Testcase:
testCustomIndexExpressionSyntax(org.apache.cassandra.index.CustomIndexTest):
FAILED
[junit-timeout] Query should be invalid but wrong error was thrown. Expected:
com.datastax.driver.core.exceptions.QueryValidationException, got:
java.lang.IllegalArgumentException. Query is: SELECT * FROM %s WHERE
expr(no_such_index, 'foo bar baz ') (values: [])
{noformat}
was (Author: suztomo):
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki edited comment on CASSANDRA-15453 at 3/10/20, 4:58 PM:
---
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453
917464e|https://github.com/suztomo/cassandra/commit/917464eb3fe666be8c00672b905741befea8a66e]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
was (Author: suztomo):
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453|https://github.com/suztomo/cassandra/tree/CASSANDRA-15453]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki edited comment on CASSANDRA-15453 at 3/10/20, 4:53 PM:
---
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453|https://github.com/suztomo/cassandra/tree/CASSANDRA-15453]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
While cassandra-driver-core version 3.0.1-shaded has references to the removed
methods, 3.6.0-shaded does not have references.
{noformat}
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
/tmp/cassandra-driver-core-3.6.0-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
suztomo@suxtomo24:~/cassandra/lib$ javap -v -cp
cassandra-driver-core-3.0.1-shaded.jar
'com.datastax.driver.core.policies.Policies$Builder' |grep firstNonNull
#67 = Utf8 firstNonNull
#69 = NameAndType#67:#68 //
firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#70 = Methodref #66.#69 //
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
28: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
41: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
54: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
67: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
80: invokestatic #70 // Method
com/google/common/base/Objects.firstNonNull:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
{noformat}
was (Author: suztomo):
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453|https://github.com/suztomo/cassandra/tree/CASSANDRA-15453]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
[jira] [Commented] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056126#comment-17056126
]
Tomo Suzuki commented on CASSANDRA-15453:
-
I tried upgrading the Guava version to 28.0 in 3.11 branch
([suztomo/CASSANDRA-15453|https://github.com/suztomo/cassandra/tree/CASSANDRA-15453]).
The test failure revealed that cassandra-driver-core is not compatible with
the Guava version on {{NoSuchMethodError:
com.google.common.base.Objects.firstNonNull}}
([log|https://gist.github.com/suztomo/3af9dd38b82335b2f0c1813595c6e536]).
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15629) Fix flakey testSendSmall - org.apache.cassandra.net.ConnectionTest
Yifan Cai created CASSANDRA-15629:
-
Summary: Fix flakey testSendSmall -
org.apache.cassandra.net.ConnectionTest
Key: CASSANDRA-15629
URL: https://issues.apache.org/jira/browse/CASSANDRA-15629
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Yifan Cai
The test fails sometimes with the following error message and trace.
{code:java}
processed count values don't match expected:<10> but was:<9>
junit.framework.AssertionFailedError: processed count values don't match
expected:<10> but was:<9>
at
org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
at
org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
at
org.apache.cassandra.net.ConnectionTest.lambda$testSendSmall$11(ConnectionTest.java:305)
at
org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
at org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
at
org.apache.cassandra.net.ConnectionTest.testSendSmall(ConnectionTest.java:277)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15630) Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
Yifan Cai created CASSANDRA-15630:
-
Summary: Fix flakey testSerializeError -
org.apache.cassandra.net.ConnectionTest
Key: CASSANDRA-15630
URL: https://issues.apache.org/jira/browse/CASSANDRA-15630
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Yifan Cai
The test fails sometimes with the following error message and trace.
{code:java}
processed count values don't match expected:<90> but was:<89>
junit.framework.AssertionFailedError: processed count values don't match
expected:<90> but was:<89>
at
org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
at
org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
at
org.apache.cassandra.net.ConnectionTest.lambda$testSerializeError$24(ConnectionTest.java:494)
at
org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:240)
at org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:260)
at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:238)
at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:227)
at
org.apache.cassandra.net.ConnectionTest.testSerializeError(ConnectionTest.java:435){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15628) Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
Yifan Cai created CASSANDRA-15628:
-
Summary: Fix flakey testSendLarge -
org.apache.cassandra.net.ConnectionTest
Key: CASSANDRA-15628
URL: https://issues.apache.org/jira/browse/CASSANDRA-15628
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Yifan Cai
The test fails sometimes with the following error message and trace.
{code:java}
received count values don't match expected:<10> but was:<9>
junit.framework.AssertionFailedError: received count values don't match
expected:<10> but was:<9>
at
org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:212)
at
org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
at
org.apache.cassandra.net.ConnectionTest.lambda$testSendLarge$15(ConnectionTest.java:359)
at
org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
at org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
at
org.apache.cassandra.net.ConnectionTest.testSendLarge(ConnectionTest.java:312)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15624) Avoid lazy initializing shut down instances when trying to send them messages
[
https://issues.apache.org/jira/browse/CASSANDRA-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15624:
Fix Version/s: 4.0-alpha
> Avoid lazy initializing shut down instances when trying to send them messages
> -
>
> Key: CASSANDRA-15624
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15624
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We currently use {{to.broadcastAddressAndPort()}} when figuring out if we
> should send a message to an instance, if that instance has been shut down it
> will get re-initialized but not startup:ed which makes the tests fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15624) Avoid lazy initializing shut down instances when trying to send them messages
[
https://issues.apache.org/jira/browse/CASSANDRA-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15624:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Low Hanging Fruit
Component/s: Test/dtest
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Avoid lazy initializing shut down instances when trying to send them messages
> -
>
> Key: CASSANDRA-15624
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15624
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Marcus Eriksson
>Priority: Normal
>
> We currently use {{to.broadcastAddressAndPort()}} when figuring out if we
> should send a message to an instance, if that instance has been shut down it
> will get re-initialized but not startup:ed which makes the tests fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15625) Nodetool toppartitions error
[ https://issues.apache.org/jira/browse/CASSANDRA-15625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-15625: Status: Awaiting Feedback (was: Triage Needed) [~james1] The stacktrace suggests that a read or write touched a 1 mb key in the app300 table during the sampling period, which shouldn't be possible with the schema you defined. Is this reproducible in a completely clean db? I'm not sure if it's coincidental that the final argument you've passed to the nodetool command matches the partition key from the insert statement, but that argument is the duration in millis for which to sample reads/writes (i.e. 500s in this case). > Nodetool toppartitions error > > > Key: CASSANDRA-15625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15625 > Project: Cassandra > Issue Type: Bug >Reporter: Antonio >Assignee: Alex Lumpov >Priority: Normal > > c* version :3.0.15 > here's my test table： > CREATE TABLE app300.test ( > a bigint PRIMARY KEY, > b text, > c text > ) > INSERT INTO app300.test(a ,b, c ) VALUES (50, 'test1', 'test1'); > when i use topartition ：nodetool toppartitions app300 test 50，get error > error: Expected 8 or 0 byte long (1048576) > -- StackTrace -- > org.apache.cassandra.serializers.MarshalException: Expected 8 or 0 byte long > (1048576) > at > org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42) > at > org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:128) > at > org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1579) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > but when i flush this table， topartition can work > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056048#comment-17056048 ] Jacob Becker commented on CASSANDRA-15623: -- [~jrwest], thanks, renamed both PR and commit message. It would be nice if this information was initially available to contributors in item 6 of the [following list|http://cassandra.apache.org/doc/latest/development/patches.html#creating-a-patch], because I personally have a habit to prefix commit messages with a ticket number, but I initially tried to closely follow the recommendations. > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055687#comment-17055687 ] Jacob Becker edited comment on CASSANDRA-15623 at 3/10/20, 3:06 PM: [~jrwest], as discussed, here comes the patch: https://github.com/apache/cassandra/pull/467 I assume you do not do any (direct) merges at GitHub, but at least to be clear on the target branch, I think an MR there is still useful. In case you are fine with the changes, I guess I could *port* the fix to other branches (simply merging will not do. files are too different, even for neighboring branches) and create the respective PRs, though in this case I would expect you to tell me a list of branches you would like to port to. was (Author: plastikat): [~jrwest], as discussed, here comes the patch: https://github.com/apache/cassandra/pull/467 I assume you do not do any (direct) merges at GitHub, but at least to be clear on the target branch, I think an MR there is still useful. In case you are fine with the changes, I guess I could *port* the fix to other branches (simply merging will not do. files are too different, even for neighboring branches) and create the respective MRs, though in this case I would expect you to tell me a list of branches you would like to port to. > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14520) ClosedChannelException handled as FSError
[ https://issues.apache.org/jira/browse/CASSANDRA-14520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Gallardo reassigned CASSANDRA-14520: -- Assignee: Kevin Gallardo > ClosedChannelException handled as FSError > - > > Key: CASSANDRA-14520 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14520 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Blake Eggleston >Assignee: Kevin Gallardo >Priority: Urgent > Fix For: 4.0 > > > After the messaging service netty refactor, I’ve seen a few instances where a > closed socket causes a ClosedChannelException (an IOException subclass) to be > thrown. The exception is caught by ChannelProxy, interpreted as a disk error, > and is then re-thrown as an FSError, causing the node to be shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14520) ClosedChannelException handled as FSError
[ https://issues.apache.org/jira/browse/CASSANDRA-14520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056029#comment-17056029 ] Kevin Gallardo commented on CASSANDRA-14520: Will start investigating this > ClosedChannelException handled as FSError > - > > Key: CASSANDRA-14520 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14520 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Blake Eggleston >Assignee: Kevin Gallardo >Priority: Urgent > Fix For: 4.0 > > > After the messaging service netty refactor, I’ve seen a few instances where a > closed socket causes a ClosedChannelException (an IOException subclass) to be > thrown. The exception is caught by ChannelProxy, interpreted as a disk error, > and is then re-thrown as an FSError, causing the node to be shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15623: Authors: Jacob Becker Test and Documentation Plan: Manual testing Status: Patch Available (was: Open) Thanks [~plastikat]. I've marked this JIRA as patch submitted. I will review it this week. I'm not super familiar with the cqlsh code so it may take me a little longer to verify the assumptions are correct. [~djoshi] would you be interested in helping here as well? Also, [~plastikat], if you rewrite your commit message in your PR as "CASSANDRA-15623: [message]" then JIRA will automatically detect it. > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: On Jenkins jobs, fix the cleaning post-task command on `/tmp` (argument to find's `-type` option)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new 663b6e8 On Jenkins jobs, fix the cleaning post-task command on `/tmp`
(argument to find's `-type` option)
663b6e8 is described below
commit 663b6e8825cc756ffd544848fbd2b5dade0ce5e7
Author: mck
AuthorDate: Tue Mar 10 11:14:48 2020 +0100
On Jenkins jobs, fix the cleaning post-task command on `/tmp` (argument to
find's `-type` option)
---
jenkins-dsl/cassandra_job_dsl_seed.groovy | 68 ---
1 file changed, 27 insertions(+), 41 deletions(-)
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index cf6eabf..84fce32 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -126,12 +126,10 @@ job('Cassandra-template-artifacts') {
}
postBuildTask {
task('.', '''
-echo "Cleaning project…";
-ant realclean;
-echo "Reporting disk usage…";
-df -h ; du -hs `pwd` ; du -hs ../* ;
+echo "Cleaning project…"; ant realclean;
+echo "Reporting disk usage…"; df -h ; du -hs `pwd` ; du -hs
../* ;
echo "Cleaning tmp…";
-find /tmp -type -f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
+find /tmp -type f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
''')
}
}
@@ -187,13 +185,11 @@ job('Cassandra-template-test') {
postBuildTask {
task('.', '''
echo "Finding job process orphans…"; if pgrep -af
${JOB_BASE_NAME}; then pkill -9 -f ${JOB_BASE_NAME}; fi;
-echo "Cleaning project…";
-ant realclean;
-echo "Reporting disk usage…";
-df -h ; du -hs `pwd` ; du -hs ../* ;
+echo "Cleaning project…"; ant realclean;
+echo "Reporting disk usage…"; df -h ; du -hs `pwd` ; du -hs
../* ;
echo "Cleaning tmp…";
-find /tmp -type -f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
-''')
+find /tmp -type f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
+''')
}
}
}
@@ -248,13 +244,11 @@ job('Cassandra-template-dtest') {
postBuildTask {
task('.', '''
echo "Finding job process orphans…"; if pgrep -af
${JOB_BASE_NAME}; then pkill -9 -f ${JOB_BASE_NAME}; fi;
-echo "Cleaning project…";
-ant realclean;
-echo "Reporting disk usage…";
-df -h ; du -hs `pwd` ; du -hs ../* ;
+echo "Cleaning project…"; ant realclean;
+echo "Reporting disk usage…"; df -h ; du -hs `pwd` ; du -hs
../* ;
echo "Cleaning tmp…";
-find /tmp -type -f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
-''')
+find /tmp -type f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
+''')
}
}
}
@@ -314,13 +308,11 @@ matrixJob('Cassandra-template-cqlsh-tests') {
postBuildTask {
task('.', '''
echo "Finding job process orphans…"; if pgrep -af
${JOB_BASE_NAME}; then pkill -9 -f ${JOB_BASE_NAME}; fi;
-echo "Cleaning project…";
-ant realclean;
-echo "Reporting disk usage…";
-df -h ; du -hs `pwd` ; du -hs ../* ;
+echo "Cleaning project…"; ant realclean;
+echo "Reporting disk usage…"; df -h ; du -hs `pwd` ; du -hs
../* ;
echo "Cleaning tmp…";
-find /tmp -type -f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
-''')
+find /tmp -type f -atime +3 -user jenkins -and -not -exec
fuser -s {} ';' -and -delete 2>/dev/null
+''')
}
}
}
@@ -573,13 +565,11 @@ testTargets.each {
postBuildTask {
task('.', '''
echo "Finding job process orphans…"; if pgrep -af
${JOB_BASE_NAME}; then pkill -9 -f ${JOB_BASE_NAME}; fi;
-echo "Cleaning project…";
-ant realclean;
-echo "Reporting disk usage…";
-df -h ; du -hs `pwd` ; du -hs ../* ;
+echo "Cleaning project…"; ant realclean;
+echo "Reporting disk usage…"; df -h ; du -hs `pwd` ; du
-hs ../* ;
echo
[jira] [Commented] (CASSANDRA-15557) Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
[
https://issues.apache.org/jira/browse/CASSANDRA-15557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055793#comment-17055793
]
Aleksey Yeschenko commented on CASSANDRA-15557:
---
Schema DDL statements aren't really meant to be prepared, as they don't even
support bound variables, and there is no benefit to doing so, so I'm not sure
how much of an issue this is. But I guess one still could do that, sure.
> Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest
> testDropListAndAddListWithSameName
> ---
>
> Key: CASSANDRA-15557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15557
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ryan Svihla
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests
> {code}
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2
> (mycollection of type list), expected but got <[first element]>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
> at
> org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055721#comment-17055721 ] Nicolas Chauvet commented on CASSANDRA-15273: - It would be appropriate to introduce systemd support for 4.0 instead See also: https://issues.apache.org/jira/browse/CASSANDRA-13148 https://github.com/apache/cassandra/pull/398 > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Aleksandr Yatskin >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > Attachments: > 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch > > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055709#comment-17055709 ] Jacob Becker commented on CASSANDRA-15623: -- BTW, to make reviewing a bit easier for you, I can additionally tell that the original condition was quite redundant in the first place: at the [following line|https://github.com/apache/cassandra/blob/b7146676f68c0e0431faa825cc8b70c06fe31090/bin/cqlsh.py#L2283] of the `read_options` function we check certain options to disable a TTY, then the [original condition|https://github.com/apache/cassandra/blob/b7146676f68c0e0431faa825cc8b70c06fe31090/bin/cqlsh.py#L2433] was doing the inverse to see if we are in a "batch mode". > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang reassigned CASSANDRA-15369:
Assignee: ZhaoYang
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055705#comment-17055705 ] ZhaoYang commented on CASSANDRA-15564: -- [~dcapwell] I have finished my review, thanks for the patch! I left some comments on the PR, otherwise LGTM. > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 50m > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15623) When running CQLSH with STDIN input, exit with error status code if script fails
[ https://issues.apache.org/jira/browse/CASSANDRA-15623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055687#comment-17055687 ] Jacob Becker commented on CASSANDRA-15623: -- [~jrwest], as discussed, here comes the patch: https://github.com/apache/cassandra/pull/467 I assume you do not do any (direct) merges at GitHub, but at least to be clear on the target branch, I think an MR there is still useful. In case you are fine with the changes, I guess I could *port* the fix to other branches (simply merging will not do. files are too different, even for neighboring branches) and create the respective MRs, though in this case I would expect you to tell me a list of branches you would like to port to. > When running CQLSH with STDIN input, exit with error status code if script > fails > > > Key: CASSANDRA-15623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15623 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Jacob Becker >Priority: Normal > > Assuming CASSANDRA-6344 is in place for years and considering that scripts > submitted with the `-e` option behave in a similar fashion, it is very > surprising that scripts submitted to STDIN (i.e. piped in) always exit with a > zero code, regardless of errors. I believe this should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15557) Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
[
https://issues.apache.org/jira/browse/CASSANDRA-15557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055682#comment-17055682
]
Ryan Svihla edited comment on CASSANDRA-15557 at 3/10/20, 8:15 AM:
---
I borrowed the code from 15303 and updated the PR. Some notes:
* There is an additional fix in there which is related to comparison of
relations. This doesn't appear to be related to either Jira, but it makes sense
at a glance, either way [~jasonstack] added it and he can comment
* Made ClientState.getTimestatmp() static and call it directly instead of
FBUtilities.timestampMicros()
But I'm also ok with someone first merging in 15303, then I can do another PR
based on that code base just with the changes that use
ClientState.getTimetamp() instead of FBUtilities.timestampMicros().
was (Author: rssvihla):
I borrowed the code from 15303 and updated the PR. Some notes:
* There is an additional fix in there which is related to comparison of
relations. This doesn't appear to be related to either Jira, but it makes sense
at a glance, either way [~jasonstack] added it and he can comment
* Made ClientState.getTimestatmp() static and call it directly instead of
FBUtilities.timestampMicros()
But I'm also ok with someone first merging in 15303, then I can do another PR
based on that code base just with the changes that use
ClientState.getTimetamp() instead of FBUtilities.timestampMicros().
> Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest
> testDropListAndAddListWithSameName
> ---
>
> Key: CASSANDRA-15557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15557
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ryan Svihla
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests
> {code}
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2
> (mycollection of type list), expected but got <[first element]>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
> at
> org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15557) Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
[
https://issues.apache.org/jira/browse/CASSANDRA-15557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055682#comment-17055682
]
Ryan Svihla commented on CASSANDRA-15557:
-
I borrowed the code from 15303 and updated the PR. Some notes:
* There is an additional fix in there which is related to comparison of
relations. This doesn't appear to be related to either Jira, but it makes sense
at a glance, either way [~jasonstack] added it and he can comment
* Made ClientState.getTimestatmp() static and call it directly instead of
FBUtilities.timestampMicros()
But I'm also ok with someone first merging in 15303, then I can do another PR
based on that code base just with the changes that use
ClientState.getTimetamp() instead of FBUtilities.timestampMicros().
> Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest
> testDropListAndAddListWithSameName
> ---
>
> Key: CASSANDRA-15557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15557
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ryan Svihla
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests
> {code}
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2
> (mycollection of type list), expected but got <[first element]>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
> at
> org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14365) Commit log replay failure for static columns with collections in clustering keys
[
https://issues.apache.org/jira/browse/CASSANDRA-14365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-14365:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
(was: 2.2.x)
4.0-alpha
3.11.7
3.0.21
2.2.17
Source Control Link:
https://github.com/apache/cassandra/commit/ae326eed2aa8f9c761fc7a0a872ce8172fde2f0f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as ae326eed2aa8f9c761fc7a0a872ce8172fde2f0f
> Commit log replay failure for static columns with collections in clustering
> keys
>
>
> Key: CASSANDRA-14365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14365
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Vincent White
>Assignee: Vincent White
>Priority: Normal
> Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha
>
>
> In the old storage engine, static cells with a collection as part of the
> clustering key fail to validate because a 0 byte collection (like in the cell
> name of a static cell) isn't valid.
> To reproduce:
> 1.
> {code:java}
> CREATE TABLE test.x (
> id int,
> id2 frozen>,
> st int static,
> PRIMARY KEY (id, id2)
> );
> INSERT INTO test.x (id, st) VALUES (1, 2);
> {code}
> 2.
> Kill the cassandra process
> 3.
> Restart cassandra to replay the commitlog
> Outcome:
> {noformat}
> ERROR [main] 2018-04-05 04:58:23,741 JVMStabilityInspector.java:99 - Exiting
> due to error while processing commit log during initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation3825739904516830950dat. This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
> enough bytes to read a set
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:638)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:565)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:517)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:397)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:143)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:284)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:533)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:642)
> [main/:na]
> {noformat}
> I haven't investigated if there are other more subtle issues caused by these
> cells failing to validate other places in the code, but I believe the fix for
> this is to check for 0 byte length collections and accept them as valid as we
> do with other types.
> I haven't had a chance for any extensive testing but this naive patch seems
> to have the desired affect.
> ||Patch||
> |[2.2
> PoC|https://github.com/vincewhite/cassandra/commits/zero_length_collection]|
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit af097240bca91b2ff52788bf1828bb9c4d405a4a
Merge: d9b38a1 ae326ee
Author: Mick Semb Wever
AuthorDate: Tue Mar 10 08:59:59 2020 +0100
Merge branch 'cassandra-2.2' into cassandra-3.0
CHANGES.txt| 1 +
.../cassandra/serializers/MapSerializer.java | 4 ++
.../cassandra/serializers/SetSerializer.java | 4 ++
.../cassandra/db/commitlog/CommitLogTest.java | 44 +-
4 files changed, 52 insertions(+), 1 deletion(-)
diff --cc CHANGES.txt
index 77b9fdf,246627b..9a10106
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,6 -1,5 +1,7 @@@
-2.2.17
+3.0.21
+ * Run evictFromMembership in GossipStage (CASSANDRA-15592)
+Merged from 2.2:
+ * Fix Commit log replays when static column clustering keys are collections
(CASSANDRA-14365)
* Fix Red Hat init script on newer systemd versions (CASSANDRA-15273)
* Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567)
diff --cc test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
index b8f68ed,c883cbd..479a090
--- a/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
+++ b/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
@@@ -41,9 -39,12 +41,10 @@@ import org.junit.runners.Parameterized.
import org.apache.cassandra.SchemaLoader;
import org.apache.cassandra.Util;
+ import org.apache.cassandra.config.CFMetaData;
import org.apache.cassandra.config.DatabaseDescriptor;
-import org.apache.cassandra.config.KSMetaData;
import org.apache.cassandra.config.ParameterizedClass;
-import org.apache.cassandra.config.Schema;
-import org.apache.cassandra.cql3.ColumnIdentifier;
+import org.apache.cassandra.config.Config.DiskFailurePolicy;
import org.apache.cassandra.db.*;
import
org.apache.cassandra.db.commitlog.CommitLogReplayer.CommitLogReplayException;
import org.apache.cassandra.db.compaction.CompactionManager;
@@@ -71,8 -67,9 +72,9 @@@ public class CommitLogTes
{
private static final String KEYSPACE1 = "CommitLogTest";
private static final String KEYSPACE2 = "CommitLogTestNonDurable";
-private static final String CF1 = "Standard1";
-private static final String CF2 = "Standard2";
-private static final String CF3 = "Custom1";
+private static final String STANDARD1 = "Standard1";
+private static final String STANDARD2 = "Standard2";
++private static final String CUSTOM1 = "Custom1";
public CommitLogTest(ParameterizedClass commitLogCompression)
{
@@@ -98,20 -95,28 +100,30 @@@
@BeforeClass
public static void defineSchema() throws ConfigurationException
{
+// Disable durable writes for system keyspaces to prevent system
mutations, e.g. sstable_activity,
+// to end up in CL segments and cause unexpected results in this test
wrt counting CL segments,
+// see CASSANDRA-12854
+KeyspaceParams.DEFAULT_LOCAL_DURABLE_WRITES = false;
+
SchemaLoader.prepareServer();
++
+ CFMetaData custom = CFMetaData.compile(String.format("CREATE TABLE
\"%s\" (" +
+ "k int," +
+ "c1
frozen>," +
+ "c2
frozen>," +
+ "s int static," +
+ "PRIMARY KEY (k,
c1, c2)" +
- ");",
CF3),KEYSPACE1);
++ ");", CUSTOM1),
KEYSPACE1);
++
SchemaLoader.createKeyspace(KEYSPACE1,
-SimpleStrategy.class,
-KSMetaData.optsWithRF(1),
-SchemaLoader.standardCFMD(KEYSPACE1, CF1),
-SchemaLoader.standardCFMD(KEYSPACE1, CF2),
+KeyspaceParams.simple(1),
+SchemaLoader.standardCFMD(KEYSPACE1,
STANDARD1, 0, AsciiType.instance, BytesType.instance),
- SchemaLoader.standardCFMD(KEYSPACE1,
STANDARD2, 0, AsciiType.instance, BytesType.instance));
++SchemaLoader.standardCFMD(KEYSPACE1,
STANDARD2, 0, AsciiType.instance, BytesType.instance),
+ custom);
SchemaLoader.createKeyspace(KEYSPACE2,
-false,
-true,
-SimpleStrategy.class,
-KSMetaData.optsWithRF(1),
-
[cassandra] branch cassandra-2.2 updated: Fix Commit log replays when static column clustering keys are collections
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-2.2
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-2.2 by this push:
new ae326ee Fix Commit log replays when static column clustering keys are
collections
ae326ee is described below
commit ae326eed2aa8f9c761fc7a0a872ce8172fde2f0f
Author: Vincent White
AuthorDate: Thu Apr 5 04:23:28 2018 +
Fix Commit log replays when static column clustering keys are collections
patch by Vincent White; reviewed by Mick Semb Wever for CASSANDRA-14365
---
CHANGES.txt| 1 +
.../cassandra/serializers/MapSerializer.java | 6 ++-
.../cassandra/serializers/SetSerializer.java | 4 ++
.../cassandra/db/commitlog/CommitLogTest.java | 47 +-
4 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 44b4abe..246627b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.17
+ * Fix Commit log replays when static column clustering keys are collections
(CASSANDRA-14365)
* Fix Red Hat init script on newer systemd versions (CASSANDRA-15273)
* Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567)
diff --git a/src/java/org/apache/cassandra/serializers/MapSerializer.java
b/src/java/org/apache/cassandra/serializers/MapSerializer.java
index 66831a3..70cd944 100644
--- a/src/java/org/apache/cassandra/serializers/MapSerializer.java
+++ b/src/java/org/apache/cassandra/serializers/MapSerializer.java
@@ -72,6 +72,10 @@ public class MapSerializer extends
CollectionSerializer>
{
try
{
+if (bytes.remaining() == 0)
+{
+return;
+}
ByteBuffer input = bytes.duplicate();
int n = readCollectionSize(input, version);
for (int i = 0; i < n; i++)
@@ -84,7 +88,7 @@ public class MapSerializer extends
CollectionSerializer>
}
catch (BufferUnderflowException e)
{
-throw new MarshalException("Not enough bytes to read a set");
+throw new MarshalException("Not enough bytes to read a map");
}
}
diff --git a/src/java/org/apache/cassandra/serializers/SetSerializer.java
b/src/java/org/apache/cassandra/serializers/SetSerializer.java
index 4aaf36a..0ed14d3 100644
--- a/src/java/org/apache/cassandra/serializers/SetSerializer.java
+++ b/src/java/org/apache/cassandra/serializers/SetSerializer.java
@@ -62,6 +62,10 @@ public class SetSerializer extends
CollectionSerializer>
{
try
{
+if (bytes.remaining() == 0)
+{
+return;
+}
ByteBuffer input = bytes.duplicate();
int n = readCollectionSize(input, version);
for (int i = 0; i < n; i++)
diff --git a/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
b/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
index 9b63885..c883cbd 100644
--- a/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
+++ b/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
@@ -39,14 +39,18 @@ import org.junit.runners.Parameterized.Parameters;
import org.apache.cassandra.SchemaLoader;
import org.apache.cassandra.Util;
+import org.apache.cassandra.config.CFMetaData;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.config.KSMetaData;
import org.apache.cassandra.config.ParameterizedClass;
+import org.apache.cassandra.config.Schema;
+import org.apache.cassandra.cql3.ColumnIdentifier;
import org.apache.cassandra.db.*;
import
org.apache.cassandra.db.commitlog.CommitLogReplayer.CommitLogReplayException;
import org.apache.cassandra.db.compaction.CompactionManager;
import org.apache.cassandra.db.composites.CellName;
import org.apache.cassandra.db.composites.CellNameType;
+import org.apache.cassandra.db.composites.CellNames;
import org.apache.cassandra.db.filter.NamesQueryFilter;
import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.io.compress.DeflateCompressor;
@@ -65,6 +69,7 @@ public class CommitLogTest
private static final String KEYSPACE2 = "CommitLogTestNonDurable";
private static final String CF1 = "Standard1";
private static final String CF2 = "Standard2";
+private static final String CF3 = "Custom1";
public CommitLogTest(ParameterizedClass commitLogCompression)
{
@@ -91,11 +96,19 @@ public class CommitLogTest
public static void defineSchema() throws ConfigurationException
{
SchemaLoader.prepareServer();
+CFMetaData custom = CFMetaData.compile(String.format("CREATE TABLE
\"%s\" (" +
+ "k int," +
+
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit ea3d4407b4d3f6f1e88097ec5e53879b3a354fd5
Merge: cb83fbf b714667
Author: Mick Semb Wever
AuthorDate: Tue Mar 10 09:04:01 2020 +0100
Merge branch 'cassandra-3.11' into trunk
CHANGES.txt| 1 +
.../cassandra/serializers/MapSerializer.java | 4 ++
.../cassandra/serializers/SetSerializer.java | 4 ++
.../cassandra/db/commitlog/CommitLogTest.java | 51 --
4 files changed, 57 insertions(+), 3 deletions(-)
diff --cc test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
index 25e2f30,895cfd0..1e3f622
--- a/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
+++ b/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
@@@ -19,6 -19,6 +19,7 @@@
package org.apache.cassandra.db.commitlog;
import java.io.*;
++import java.math.BigInteger;
import java.nio.ByteBuffer;
import java.util.*;
import java.util.concurrent.Callable;
@@@ -29,9 -29,9 +30,9 @@@ import java.util.zip.CRC32
import java.util.zip.Checksum;
import com.google.common.collect.Iterables;
++import com.google.common.io.Files;
import org.junit.*;
--import com.google.common.io.Files;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
@@@ -68,19 -65,19 +69,25 @@@ import org.apache.cassandra.utils.Kille
import org.apache.cassandra.utils.Pair;
import org.apache.cassandra.utils.vint.VIntCoding;
--import org.junit.After;
import static org.apache.cassandra.utils.ByteBufferUtil.bytes;
++
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;
++import org.apache.cassandra.db.marshal.IntegerType;
++import org.apache.cassandra.db.marshal.MapType;
++import org.apache.cassandra.db.marshal.SetType;
++import org.apache.cassandra.db.marshal.UTF8Type;
++
+@Ignore
@RunWith(Parameterized.class)
-public class CommitLogTest
+public abstract class CommitLogTest
{
-private static final String KEYSPACE1 = "CommitLogTest";
+protected static final String KEYSPACE1 = "CommitLogTest";
private static final String KEYSPACE2 = "CommitLogTestNonDurable";
-private static final String STANDARD1 = "Standard1";
+protected static final String STANDARD1 = "Standard1";
private static final String STANDARD2 = "Standard2";
+ private static final String CUSTOM1 = "Custom1";
private static JVMStabilityInspector.Killer oldKiller;
private static KillerForTests testKiller;
@@@ -111,6 -108,15 +118,14 @@@
KeyspaceParams.DEFAULT_LOCAL_DURABLE_WRITES = false;
SchemaLoader.prepareServer();
+
-CFMetaData custom = CFMetaData.compile(String.format("CREATE TABLE
\"%s\" (" +
- "k int," +
- "c1
frozen>," +
- "c2
frozen>," +
- "s int static," +
- "PRIMARY KEY (k,
c1, c2)" +
- ");", CUSTOM1),
KEYSPACE1);
++TableMetadata.Builder custom =
++TableMetadata.builder(KEYSPACE1, CUSTOM1)
++ .addPartitionKeyColumn("k", IntegerType.instance)
++ .addClusteringColumn("c1",
MapType.getInstance(UTF8Type.instance, UTF8Type.instance, false))
++ .addClusteringColumn("c2",
SetType.getInstance(UTF8Type.instance, false))
++ .addStaticColumn("s", IntegerType.instance);
+
SchemaLoader.createKeyspace(KEYSPACE1,
KeyspaceParams.simple(1),
SchemaLoader.standardCFMD(KEYSPACE1,
STANDARD1, 0, AsciiType.instance, BytesType.instance),
@@@ -900,5 -930,33 +918,32 @@@
{
testOutOfOrderFlushRecovery(recycleSegments, true);
}
+
+ @Test
+ public void testRecoveryWithCollectionClusteringKeysStatic() throws
Exception
+ {
+
+ ColumnFamilyStore cfs =
Keyspace.open(KEYSPACE1).getColumnFamilyStore(CUSTOM1);
-RowUpdateBuilder rb = new RowUpdateBuilder(cfs.metadata, 0, 1);
++RowUpdateBuilder rb = new RowUpdateBuilder(cfs.metadata(), 0,
BigInteger.ONE);
+
-rb.add("s", 2);
++rb.add("s", BigInteger.valueOf(2));
+
+ Mutation rm = rb.build();
+ CommitLog.instance.add(rm);
+
+ int replayed = 0;
+
+ try
+ {
+
System.setProperty(CommitLogReplayer.IGNORE_REPLAY_ERRORS_PROPERTY, "true");
+ replayed =
[cassandra] branch trunk updated (cb83fbf -> ea3d440)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from cb83fbf Fix CRLF and trailing whitespace on messaging doc new ae326ee Fix Commit log replays when static column clustering keys are collections new af09724 Merge branch 'cassandra-2.2' into cassandra-3.0 new b714667 Merge branch 'cassandra-3.0' into cassandra-3.11 new ea3d440 Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/serializers/MapSerializer.java | 4 ++ .../cassandra/serializers/SetSerializer.java | 4 ++ .../cassandra/db/commitlog/CommitLogTest.java | 51 -- 4 files changed, 57 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (1900510 -> b714667)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1900510 Merge branch 'cassandra-3.0' into cassandra-3.11 new ae326ee Fix Commit log replays when static column clustering keys are collections new af09724 Merge branch 'cassandra-2.2' into cassandra-3.0 new b714667 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/serializers/MapSerializer.java | 4 ++ .../cassandra/serializers/SetSerializer.java | 4 ++ .../cassandra/db/commitlog/CommitLogTest.java | 43 +- 4 files changed, 51 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit b7146676f68c0e0431faa825cc8b70c06fe31090
Merge: 1900510 af09724
Author: Mick Semb Wever
AuthorDate: Tue Mar 10 09:02:10 2020 +0100
Merge branch 'cassandra-3.0' into cassandra-3.11
CHANGES.txt| 1 +
.../cassandra/serializers/MapSerializer.java | 4 ++
.../cassandra/serializers/SetSerializer.java | 4 ++
.../cassandra/db/commitlog/CommitLogTest.java | 43 +-
4 files changed, 51 insertions(+), 1 deletion(-)
diff --cc CHANGES.txt
index 967675f,9a10106..c596be9
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,7 -1,7 +1,8 @@@
-3.0.21
+3.11.7
+Merged from 3.0:
* Run evictFromMembership in GossipStage (CASSANDRA-15592)
Merged from 2.2:
+ * Fix Commit log replays when static column clustering keys are collections
(CASSANDRA-14365)
* Fix Red Hat init script on newer systemd versions (CASSANDRA-15273)
* Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567)
diff --cc test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
index 215ad6c,479a090..895cfd0
--- a/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
+++ b/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
@@@ -77,14 -74,17 +77,15 @@@ public class CommitLogTes
private static final String KEYSPACE2 = "CommitLogTestNonDurable";
private static final String STANDARD1 = "Standard1";
private static final String STANDARD2 = "Standard2";
+ private static final String CUSTOM1 = "Custom1";
-public CommitLogTest(ParameterizedClass commitLogCompression)
-{
-DatabaseDescriptor.setCommitLogCompression(commitLogCompression);
-}
+private static JVMStabilityInspector.Killer oldKiller;
+private static KillerForTests testKiller;
-@Before
-public void setUp() throws IOException
+public CommitLogTest(ParameterizedClass commitLogCompression,
EncryptionContext encryptionContext)
{
-CommitLog.instance.resetUnsafe(true);
+DatabaseDescriptor.setCommitLogCompression(commitLogCompression);
+DatabaseDescriptor.setEncryptionContext(encryptionContext);
}
@Parameters()
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (d9b38a1 -> af09724)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d9b38a1 Merge branch 'cassandra-2.2' into cassandra-3.0 new ae326ee Fix Commit log replays when static column clustering keys are collections new af09724 Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/serializers/MapSerializer.java | 4 ++ .../cassandra/serializers/SetSerializer.java | 4 ++ .../cassandra/db/commitlog/CommitLogTest.java | 44 +- 4 files changed, 52 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14365) Commit log replay failure for static columns with collections in clustering keys
[
https://issues.apache.org/jira/browse/CASSANDRA-14365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-14365:
---
Status: Ready to Commit (was: Review In Progress)
> Commit log replay failure for static columns with collections in clustering
> keys
>
>
> Key: CASSANDRA-14365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14365
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Vincent White
>Assignee: Vincent White
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> In the old storage engine, static cells with a collection as part of the
> clustering key fail to validate because a 0 byte collection (like in the cell
> name of a static cell) isn't valid.
> To reproduce:
> 1.
> {code:java}
> CREATE TABLE test.x (
> id int,
> id2 frozen>,
> st int static,
> PRIMARY KEY (id, id2)
> );
> INSERT INTO test.x (id, st) VALUES (1, 2);
> {code}
> 2.
> Kill the cassandra process
> 3.
> Restart cassandra to replay the commitlog
> Outcome:
> {noformat}
> ERROR [main] 2018-04-05 04:58:23,741 JVMStabilityInspector.java:99 - Exiting
> due to error while processing commit log during initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation3825739904516830950dat. This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: org.apache.cassandra.serializers.MarshalException: Not
> enough bytes to read a set
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:638)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:565)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:517)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:397)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:143)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:284)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:533)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:642)
> [main/:na]
> {noformat}
> I haven't investigated if there are other more subtle issues caused by these
> cells failing to validate other places in the code, but I believe the fix for
> this is to check for 0 byte length collections and accept them as valid as we
> do with other types.
> I haven't had a chance for any extensive testing but this naive patch seems
> to have the desired affect.
> ||Patch||
> |[2.2
> PoC|https://github.com/vincewhite/cassandra/commits/zero_length_collection]|
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
