[jira] [Commented] (CASSANDRA-12682) Silent data corruption and corruption propagation in Cassandra

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175926#comment-16175926
 ] 

Jeff Jirsa commented on CASSANDRA-12682:


[~aganesan] - thank you for the post. [~jasobrown] and I were actually 
discussing the acknowledgements in [your 
paper|https://www.usenix.org/system/files/conference/fast17/fast17-ganesan.pdf] 
today and it's a shame your ticket somehow went unnoticed. I'd like to blame it 
on the fact that it happened during a busy time of the year for everyone last 
year (immediately after the 2016 Cassandra Summit), but the real answer is that 
JIRA is high noise, and it's easy to miss tickets - for future reference, dev @ 
cassandra.apache.org is a much better place for feedback.

{quote}
 Also, the read repair or anti-entropy can propagate the corrupted data to 
other intact replicas when the corrupted value is lexically greater
{quote}

If the table is uncompressed and crc check chance is less than 1, yes. The 
default config in modern versions is compression enabled and crc check chance 
set to 1, so the default install SHOULD protect against that ON THE READ PATH.

{quote}
Why does Cassandra not use the CRC and digests to verify the integrity of data 
in the SStables on read? 
{quote}

It CAN for the compressed sstables, for uncompressed sstables we don't 
currently keep checksums in small enough data chunks to make it viable at high 
request rates (we'd have to amend the sstable format to embed checksums for the 
uncompressed sstables - which we could certainly do)

{quote}
Are the digest.crc32 and CRC.db files ever used?
{quote}

There exists a tool that allows you to check the whole-file checksum, though 
it's only used on operator demand (and it's probably likely that few operators 
really use it in practice)



> Silent data corruption and corruption propagation in Cassandra
> --
>
> Key: CASSANDRA-12682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12682
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Aishwarya Ganesan
>Priority: Critical
>  Labels: Correctness
> Fix For: 4.x
>
>
> Corruptions in Cassandra's SSTable data can be silently returned to users if 
> SSTable compression is disabled. 
> Cassandra maintains a digest.crc32 and CRC.db in the sstable directory but 
> fails to detect the corruptions to SSTable Data.db. Without this, Cassandra 
> is vulnerable to silent corruptions resulting from underlying problems in 
> disks and file systems atop them. Studies support the need for end to end 
> integrity:
> https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
> In a small test case where the underlying disk/FS corrupts a particular block 
> holding the user data, Cassandra can silently return corrupted user data on a 
> read request. Also, the read repair or anti-entropy can propagate the 
> corrupted data to other intact replicas when the corrupted value is lexically 
> greater. This is because a corruption doesn't change the timestamps and 
> timestamp conflicts are resolved by choosing the data with the highest value. 
> (We reproduced this scenario using our testing framework)
> Why does Cassandra not use the CRC and digests to verify the integrity of 
> data in the SStables on read? Are the digest.crc32 and CRC.db files ever used?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12682) Silent data corruption and corruption propagation in Cassandra

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12682:
---
Fix Version/s: 4.x

> Silent data corruption and corruption propagation in Cassandra
> --
>
> Key: CASSANDRA-12682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12682
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Aishwarya Ganesan
>  Labels: Correctness
> Fix For: 4.x
>
>
> Corruptions in Cassandra's SSTable data can be silently returned to users if 
> SSTable compression is disabled. 
> Cassandra maintains a digest.crc32 and CRC.db in the sstable directory but 
> fails to detect the corruptions to SSTable Data.db. Without this, Cassandra 
> is vulnerable to silent corruptions resulting from underlying problems in 
> disks and file systems atop them. Studies support the need for end to end 
> integrity:
> https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
> In a small test case where the underlying disk/FS corrupts a particular block 
> holding the user data, Cassandra can silently return corrupted user data on a 
> read request. Also, the read repair or anti-entropy can propagate the 
> corrupted data to other intact replicas when the corrupted value is lexically 
> greater. This is because a corruption doesn't change the timestamps and 
> timestamp conflicts are resolved by choosing the data with the highest value. 
> (We reproduced this scenario using our testing framework)
> Why does Cassandra not use the CRC and digests to verify the integrity of 
> data in the SStables on read? Are the digest.crc32 and CRC.db files ever used?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12682) Silent data corruption and corruption propagation in Cassandra

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12682:
---
Component/s: Core

> Silent data corruption and corruption propagation in Cassandra
> --
>
> Key: CASSANDRA-12682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12682
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Aishwarya Ganesan
>Priority: Critical
>  Labels: Correctness
> Fix For: 4.x
>
>
> Corruptions in Cassandra's SSTable data can be silently returned to users if 
> SSTable compression is disabled. 
> Cassandra maintains a digest.crc32 and CRC.db in the sstable directory but 
> fails to detect the corruptions to SSTable Data.db. Without this, Cassandra 
> is vulnerable to silent corruptions resulting from underlying problems in 
> disks and file systems atop them. Studies support the need for end to end 
> integrity:
> https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
> In a small test case where the underlying disk/FS corrupts a particular block 
> holding the user data, Cassandra can silently return corrupted user data on a 
> read request. Also, the read repair or anti-entropy can propagate the 
> corrupted data to other intact replicas when the corrupted value is lexically 
> greater. This is because a corruption doesn't change the timestamps and 
> timestamp conflicts are resolved by choosing the data with the highest value. 
> (We reproduced this scenario using our testing framework)
> Why does Cassandra not use the CRC and digests to verify the integrity of 
> data in the SStables on read? Are the digest.crc32 and CRC.db files ever used?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12682) Silent data corruption and corruption propagation in Cassandra

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12682:
---
Labels: Correctness  (was: )

> Silent data corruption and corruption propagation in Cassandra
> --
>
> Key: CASSANDRA-12682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12682
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Aishwarya Ganesan
>Priority: Critical
>  Labels: Correctness
> Fix For: 4.x
>
>
> Corruptions in Cassandra's SSTable data can be silently returned to users if 
> SSTable compression is disabled. 
> Cassandra maintains a digest.crc32 and CRC.db in the sstable directory but 
> fails to detect the corruptions to SSTable Data.db. Without this, Cassandra 
> is vulnerable to silent corruptions resulting from underlying problems in 
> disks and file systems atop them. Studies support the need for end to end 
> integrity:
> https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
> In a small test case where the underlying disk/FS corrupts a particular block 
> holding the user data, Cassandra can silently return corrupted user data on a 
> read request. Also, the read repair or anti-entropy can propagate the 
> corrupted data to other intact replicas when the corrupted value is lexically 
> greater. This is because a corruption doesn't change the timestamps and 
> timestamp conflicts are resolved by choosing the data with the highest value. 
> (We reproduced this scenario using our testing framework)
> Why does Cassandra not use the CRC and digests to verify the integrity of 
> data in the SStables on read? Are the digest.crc32 and CRC.db files ever used?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12682) Silent data corruption and corruption propagation in Cassandra

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12682:
---
Priority: Critical  (was: Major)

> Silent data corruption and corruption propagation in Cassandra
> --
>
> Key: CASSANDRA-12682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12682
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Aishwarya Ganesan
>Priority: Critical
>  Labels: Correctness
> Fix For: 4.x
>
>
> Corruptions in Cassandra's SSTable data can be silently returned to users if 
> SSTable compression is disabled. 
> Cassandra maintains a digest.crc32 and CRC.db in the sstable directory but 
> fails to detect the corruptions to SSTable Data.db. Without this, Cassandra 
> is vulnerable to silent corruptions resulting from underlying problems in 
> disks and file systems atop them. Studies support the need for end to end 
> integrity:
> https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
> In a small test case where the underlying disk/FS corrupts a particular block 
> holding the user data, Cassandra can silently return corrupted user data on a 
> read request. Also, the read repair or anti-entropy can propagate the 
> corrupted data to other intact replicas when the corrupted value is lexically 
> greater. This is because a corruption doesn't change the timestamps and 
> timestamp conflicts are resolved by choosing the data with the highest value. 
> (We reproduced this scenario using our testing framework)
> Why does Cassandra not use the CRC and digests to verify the integrity of 
> data in the SStables on read? Are the digest.crc32 and CRC.db files ever used?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12682) Silent data corruption and corruption propagation in Cassandra

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12682:
---
Issue Type: Improvement  (was: Bug)

> Silent data corruption and corruption propagation in Cassandra
> --
>
> Key: CASSANDRA-12682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12682
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Aishwarya Ganesan
>Priority: Critical
>  Labels: Correctness
> Fix For: 4.x
>
>
> Corruptions in Cassandra's SSTable data can be silently returned to users if 
> SSTable compression is disabled. 
> Cassandra maintains a digest.crc32 and CRC.db in the sstable directory but 
> fails to detect the corruptions to SSTable Data.db. Without this, Cassandra 
> is vulnerable to silent corruptions resulting from underlying problems in 
> disks and file systems atop them. Studies support the need for end to end 
> integrity:
> https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
> In a small test case where the underlying disk/FS corrupts a particular block 
> holding the user data, Cassandra can silently return corrupted user data on a 
> read request. Also, the read repair or anti-entropy can propagate the 
> corrupted data to other intact replicas when the corrupted value is lexically 
> greater. This is because a corruption doesn't change the timestamps and 
> timestamp conflicts are resolved by choosing the data with the highest value. 
> (We reproduced this scenario using our testing framework)
> Why does Cassandra not use the CRC and digests to verify the integrity of 
> data in the SStables on read? Are the digest.crc32 and CRC.db files ever used?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12380) Cassandra doesn't start with IndexOutOfBoundsException exception

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175910#comment-16175910
 ] 

Jeff Jirsa commented on CASSANDRA-12380:


[~arokhin] - did you ever resolve this issue? Do you have any more information 
to help reproduce? If not, do you mind if we close it - it will be difficult to 
make any progress without additional information.


> Cassandra doesn't start with IndexOutOfBoundsException exception
> 
>
> Key: CASSANDRA-12380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12380
> Project: Cassandra
>  Issue Type: Bug
> Environment: Version 2.2.4
>Reporter: Artem Rokhin
>
> {code}
> 2016-08-02T10:31:35,260 [CompactionExecutor:1] ERROR 
> o.a.c.service.CassandraDaemon - Exception in thread 
> Thread[CompactionExecutor:1,1,main]
> org.apache.cassandra.io.FSReadError: java.lang.IndexOutOfBoundsException
>   at 
> org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:358)
>  ~[apache-cassandra-clientutil-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:359) 
> ~[apache-cassandra-clientutil-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:338)
>  ~[apache-cassandra-clientutil-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:365)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  ~[guava-16.0.jar:na]
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> ~[guava-16.0.jar:na]
>   at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:169)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:202)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  ~[guava-16.0.jar:na]
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> ~[guava-16.0.jar:na]
>   at 
> com.google.common.collect.Iterators$7.computeNext(Iterators.java:645) 
> ~[guava-16.0.jar:na]
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  ~[guava-16.0.jar:na]
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> ~[guava-16.0.jar:na]
>   at 
> org.apache.cassandra.db.ColumnIndex$Builder.buildForCompaction(ColumnIndex.java:166)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:125)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:136)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:116)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.append(MaxSSTableSizeWriter.java:67)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:184)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:74)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:247)
>  ~[apache-cassandra-2.2.4.jar:2.2.4]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_73]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_73]
>   at 
> 

[jira] [Commented] (CASSANDRA-10695) Thrift HSHA appears to not work in 2.1+ with high client thread counts in stress

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175903#comment-16175903
 ] 

Jeff Jirsa commented on CASSANDRA-10695:


[~aweisberg] - do you feel like this is still worth addressing?


> Thrift HSHA appears to not work in 2.1+ with high client thread counts in 
> stress
> 
>
> Key: CASSANDRA-10695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10695
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ariel Weisberg
> Attachments: cassandra.yaml
>
>
> In 2.2+ my stress runs make almost no progress. In 2.1 they make some 
> progress but this assertion is still in the log. Things are generally pretty 
> unstable. I was able to benchmark with the sync server at 500 threads without 
> issue.
> Where I ran into trouble was attempting to benchmark with 2000 threads. The 
> sync server crapped out due to thread counts and I didn't bother trying to 
> fiddle with it I switched to HSHA which worked at 500, but fails at 2000.
> My test configuration is an OS X laptop running 2.2 stress (sometimes trunk, 
> didn't seem to matter) and a quad core Linux desktop. I can reproduce this 
> the other way around as well.
> Stress command was
> {code}
> cassandra-stress write n=1900 -rate threads=2000 -mode thrift -node 
> 192.168.1.3
> {code}
> I will attach the YAML. Error was
> {code}
> java.lang.RuntimeException: java.lang.AssertionError: Invoke called in 
> invalid state: READY_TO_WRITE
>   at 
> com.lmax.disruptor.FatalExceptionHandler.handleEventException(FatalExceptionHandler.java:45)
>  ~[disruptor-3.0.1.jar:na]
>   at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:126) 
> ~[disruptor-3.0.1.jar:na]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_60]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
> Caused by: java.lang.AssertionError: Invoke called in invalid state: 
> READY_TO_WRITE
>   at com.thinkaurelius.thrift.Message.invoke(Message.java:306) 
> ~[thrift-server-0.3.7.jar:na]
>   at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90) 
> ~[thrift-server-0.3.7.jar:na]
>   at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
>  ~[thrift-server-0.3.7.jar:na]
>   at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
>  ~[thrift-server-0.3.7.jar:na]
>   at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112) 
> ~[disruptor-3.0.1.jar:na]
>   ... 3 common frames omitted
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-10659) Windows CassCI: Fail on timed-out tests

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175902#comment-16175902
 ] 

Jeff Jirsa commented on CASSANDRA-10659:


[~mambocab] / [~JoshuaMcKenzie] / [~philipthompson] - if any of you believe 
this should still be open, please let me know. Otherwise I'm inclined to close 
as won't-fix since cassci is no longer generally available , and I suspect any 
other more general test failures can be addressed elsewhere?


> Windows CassCI: Fail on timed-out tests
> ---
>
> Key: CASSANDRA-10659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10659
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Jim Witschey
>
> On our Windows CassCI environments, it looks like some dtests are prone to 
> hanging, e.g.:
> https://cassci.datastax.com/view/Dev/view/josh-mckenzie/job/josh-mckenzie-10641_windows-dtest_win32/1/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/131/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/129/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/128/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/126/
> http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest_win32/125/
> Ideally these tests wouldn't hang, but regardless, we should figure out a way 
> to make them fail, rather than timing out Jenkins and botching the rest of 
> the test run.
> The built-in [{{nosetests}} {{multiprocess}} 
> plugin|http://nose.readthedocs.org/en/latest/plugins/multiprocess.html] would 
> solve this problem for us -- we could run the tests with {{nosetests 
> --processes=1 --process-timeout=X}} and it would stop the test and fail if 
> the test took too long. However, it's broken on Windows. I've filed [a quick 
> issue on the {{nose}} GitHub|https://github.com/nose-devs/nose/issues/966], 
> but in the meantime, we should figure out how to avoid this.
> Possible solutions:
> # [~philipthompson] had a script that would shell out to {{nosetests}} for 
> each test and kill that process if it took too long. If I understand 
> correctly, that script is broken, or assumes things that are no longer true. 
> We can revamp it if we want.
> # We could make a patch for {{nose}} to fix the {{multiprocess}} plugin.
> # We could hack in some of {{multiprocessing}}'s functionality into the 
> {{dtest}} suite itself.
> 3. may be the best workaround for this problem -- our timeouts aren't caused 
> just when a tests runs long, but when Jenkins doesn't get any output on 
> stdout from a hanging test. We may be able to monitor stdout from a second 
> process and fail the test before Jenkins would time out.
> Pinging [~JoshuaMcKenzie] as this is a Windows issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-10588) Large number of tables increases the cpu usage during idle time

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa resolved CASSANDRA-10588.

Resolution: Won't Fix

This is likely inherent to the design, but even if it's not, there's no 
indication it's a bug. After 2 years, without a concrete bug or proposal, I am 
closing this as won't-fix. If you believe this is really actionable, please 
re-open.

> Large number of tables increases the cpu usage during idle time
> ---
>
> Key: CASSANDRA-10588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10588
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Xu Zhongxing
>Priority: Minor
>
> When the database is empty, the idle time cpu usage of Cassandra is around 
> 2%. But after I created 1500 tables, the cpu usage increases to 10%.
> I checked with top -H and jstack and found two metric-meter-tick threads both 
> consumes around 5% cpu.
> If I remove all 1500 tables, the cpu usage decreases.
> Is this a problem or is an inherent design property of Cassandra?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-10327) Performance regression in 2.2

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa resolved CASSANDRA-10327.

Resolution: Won't Fix

Seems unlikely we'll be addressing a 2.2 regression anymore, especially with a 
suspect 2.1 test. I'm reasonably sure you won't mind, [~benedict] , but if I'm 
wrong and you do care, please let me know.


> Performance regression in 2.2
> -
>
> Key: CASSANDRA-10327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10327
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benedict
> Fix For: 2.2.x
>
>
> Related to CASSANDRA-10326, one of the read-only workloads _appears_ to show 
> a regression in 2.2, however it is possible this is simply down to a 
> different compaction result (this shouldn't be very likely given the use of 
> LCS, though, and that we wait for compaction to acquiesce, and while the 
> different is not consistent across both runs, it is consistently worse).
> The query is looking up the last item of a partition.
> [run1|http://cstar.datastax.com/graph?stats=f0a17292-5a13-11e5-847a-42010af0688f=op_rate=3_user=1_aggregates=true=0=155.43=0=13777.5]
> [run2|http://cstar.datastax.com/graph?stats=e250-5a13-11e5-ae0d-42010af0688f=op_rate=3_user=1_aggregates=true=0=74.36=0=34078]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-5152) CQLSH prompt doesn't properly accept input characters on OSX

[Manish Maheshwari (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175840#comment-16175840
 ] 

Manish Maheshwari commented on CASSANDRA-5152:
--

Even with readline it didnt work for me - I had to use virtualenv 

{code}
virtualenv -p /usr/bin/python2.7 cqlsh_dir
cd cqlsh_dir
source ./bin/activate
cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> use test;
cqlsh:test>
{code}


> CQLSH prompt doesn't properly accept input characters on OSX
> 
>
> Key: CASSANDRA-5152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5152
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: OSX Mountain Lion
>Reporter: Akshay Rao
>Assignee: Aleksey Yeschenko
>
> In the terminal for OSX Mountain Lion, I execute 'cqlsh'.  When I try to type 
> the 't' letter, nothing appears on the screen.  All other keys work, and no 
> other shell application is affected in this manner.  This is not an issue for 
> Cassandra 1.1.6 - just started happening when I downloaded Cassandra 1.2.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-8274) Node fails to rejoin cluster on EC2 if private IP is changed

[Joseph Clark (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175788#comment-16175788
 ] 

Joseph Clark commented on CASSANDRA-8274:
-

Unfortunately I'm no longer set up to reproduce this issue.

> Node fails to rejoin cluster on EC2 if private IP is changed
> 
>
> Key: CASSANDRA-8274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8274
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
> Environment: Amazon EC2
>Reporter: Joseph Clark
>Priority: Minor
> Fix For: 3.11.x
>
>
> Nodes in Amazon AWS EC2 Classic (not a VPC) may be assigned a new private IP 
> if the node is stopped and then started again. In this case we have puppet 
> update the configured listen_address to the new private IP. However, once the 
> cassandra service starts, it is unable to communicate with the existing 
> nodes(single region) and vice versa.
> 'nodetool status' shows that each node believes that it is 'UN' and the other 
> node is 'DN'.
> 'nodetool gossipinfo' on the node that remained running shows the *old* 
> private IP listed as the 'INTERNAL_IP' of the node that was stopped and 
> restarted. 
> The situation is resolved by restarting the cassandra service on the node 
> that remained running. Once it has restarted, the INTERNAL_IP is correctly 
> updated to the new private IP. 'nodetool status' shows that both nodes are up 
> and the cluster appears to function normally.
> This appears to me to be the root cause of 
> https://issues.apache.org/jira/browse/CASSANDRA-7292. -Possibly 
> https://issues.apache.org/jira/browse/CASSANDRA-8072 as well, but I am not 
> convinced they are actually duplicates.-



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-9783) 2.1-offheap compaction dtests fail

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175739#comment-16175739
 ] 

Jeff Jirsa commented on CASSANDRA-9783:
---

I suspect this is no longer an issue - you ok if we close it [~snazy] ? 


> 2.1-offheap compaction dtests fail
> --
>
> Key: CASSANDRA-9783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9783
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>
> All compaction dtests fail because the generated files are too large 
> (assertion failure). See 
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/117/testReport/
> The tests work fine in non-offheap configuration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-6925) /etc/init.d/cassandra clobbers pid file

[Michael Shuler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Shuler resolved CASSANDRA-6925.
---
Resolution: Fixed

This was fixed.

> /etc/init.d/cassandra clobbers pid file
> ---
>
> Key: CASSANDRA-6925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6925
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
> Environment: Cassandra:
> Datastax cassandra20-2.0.5-1.noarch.rpm
> OS:
> CentOS 6.4
> Linux fqdn 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13 UTC 2013 
> x86_64 x86_64 x86_64 GNU/Linux
> JDK:
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
>Reporter: Craig Brown
>Priority: Minor
>
> Preconditions:
> Cassandra service is running successfully.
> Cassandra service is erroneously started when already running via:
> service cassandra start
> /var/run/cassandra/cassandra.pid is overwritten with new pid.  The original 
> cassandra process continues to run.  The recorded pid is not running. 
> Because the recorded pid is incorrect, its impossible to stop cassandra via:
> service cassandra stop
> Before starting cassandra, the script should ensure that its not already 
> running.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-8274) Node fails to rejoin cluster on EC2 if private IP is changed

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175724#comment-16175724
 ] 

Jeff Jirsa commented on CASSANDRA-8274:
---

Is this still an issue, or has it been resolved in the past 3 years?


> Node fails to rejoin cluster on EC2 if private IP is changed
> 
>
> Key: CASSANDRA-8274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8274
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
> Environment: Amazon EC2
>Reporter: Joseph Clark
>Priority: Minor
> Fix For: 3.11.x
>
>
> Nodes in Amazon AWS EC2 Classic (not a VPC) may be assigned a new private IP 
> if the node is stopped and then started again. In this case we have puppet 
> update the configured listen_address to the new private IP. However, once the 
> cassandra service starts, it is unable to communicate with the existing 
> nodes(single region) and vice versa.
> 'nodetool status' shows that each node believes that it is 'UN' and the other 
> node is 'DN'.
> 'nodetool gossipinfo' on the node that remained running shows the *old* 
> private IP listed as the 'INTERNAL_IP' of the node that was stopped and 
> restarted. 
> The situation is resolved by restarting the cassandra service on the node 
> that remained running. Once it has restarted, the INTERNAL_IP is correctly 
> updated to the new private IP. 'nodetool status' shows that both nodes are up 
> and the cluster appears to function normally.
> This appears to me to be the root cause of 
> https://issues.apache.org/jira/browse/CASSANDRA-7292. -Possibly 
> https://issues.apache.org/jira/browse/CASSANDRA-8072 as well, but I am not 
> convinced they are actually duplicates.-



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-7723) sstable2json (and possibly other command-line tools) hang if no write permission to the commitlogs

[Chris Lohfink (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175718#comment-16175718
 ] 

Chris Lohfink commented on CASSANDRA-7723:
--

sstableloader, sstabledump and sstablemetadata do not have this problem. The 
other sstable tools still do. Not running as same user as the C* service is 
currently dangerous for most of the offline tools.

> sstable2json (and possibly other command-line tools) hang if no write 
> permission to the commitlogs
> --
>
> Key: CASSANDRA-7723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7723
> Project: Cassandra
>  Issue Type: Bug
>Reporter: J.B. Langston
>Priority: Minor
>
> sstable2json (and potentially other command-line tools that call 
> DatabaseDescriptor.loadSchemas) will hang if the user running them doesn't 
> have write permission on the commit logs.  loadSchemas calls 
> Schema.updateVersion, which causes a mutation to the system tables, then it 
> just spins forever trying to acquire a commit log segment.  See this thread 
> dump: https://gist.github.com/markcurtis1970/837e770d1cad5200943c. The tools 
> should recognize this and present an understandable error message.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-7723) sstable2json (and possibly other command-line tools) hang if no write permission to the commitlogs

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-7723:
--
Labels:   (was: PendingClose Unresponsive)

> sstable2json (and possibly other command-line tools) hang if no write 
> permission to the commitlogs
> --
>
> Key: CASSANDRA-7723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7723
> Project: Cassandra
>  Issue Type: Bug
>Reporter: J.B. Langston
>Priority: Minor
>
> sstable2json (and potentially other command-line tools that call 
> DatabaseDescriptor.loadSchemas) will hang if the user running them doesn't 
> have write permission on the commit logs.  loadSchemas calls 
> Schema.updateVersion, which causes a mutation to the system tables, then it 
> just spins forever trying to acquire a commit log segment.  See this thread 
> dump: https://gist.github.com/markcurtis1970/837e770d1cad5200943c. The tools 
> should recognize this and present an understandable error message.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-7723) sstable2json (and possibly other command-line tools) hang if no write permission to the commitlogs

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-7723:
--
Labels: PendingClose Unresponsive  (was: )

> sstable2json (and possibly other command-line tools) hang if no write 
> permission to the commitlogs
> --
>
> Key: CASSANDRA-7723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7723
> Project: Cassandra
>  Issue Type: Bug
>Reporter: J.B. Langston
>Priority: Minor
>
> sstable2json (and potentially other command-line tools that call 
> DatabaseDescriptor.loadSchemas) will hang if the user running them doesn't 
> have write permission on the commit logs.  loadSchemas calls 
> Schema.updateVersion, which causes a mutation to the system tables, then it 
> just spins forever trying to acquire a commit log segment.  See this thread 
> dump: https://gist.github.com/markcurtis1970/837e770d1cad5200943c. The tools 
> should recognize this and present an understandable error message.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-6925) /etc/init.d/cassandra clobbers pid file

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175709#comment-16175709
 ] 

Jeff Jirsa commented on CASSANDRA-6925:
---

[~jcbrown] / [~mshuler] is this still an issue, or can it be resolved? 

> /etc/init.d/cassandra clobbers pid file
> ---
>
> Key: CASSANDRA-6925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6925
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
> Environment: Cassandra:
> Datastax cassandra20-2.0.5-1.noarch.rpm
> OS:
> CentOS 6.4
> Linux fqdn 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13 UTC 2013 
> x86_64 x86_64 x86_64 GNU/Linux
> JDK:
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
>Reporter: Craig Brown
>Priority: Minor
>
> Preconditions:
> Cassandra service is running successfully.
> Cassandra service is erroneously started when already running via:
> service cassandra start
> /var/run/cassandra/cassandra.pid is overwritten with new pid.  The original 
> cassandra process continues to run.  The recorded pid is not running. 
> Because the recorded pid is incorrect, its impossible to stop cassandra via:
> service cassandra stop
> Before starting cassandra, the script should ensure that its not already 
> running.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-6542) nodetool removenode hangs

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175707#comment-16175707
 ] 

Jeff Jirsa commented on CASSANDRA-6542:
---

[~elubow] - do you believe this is still a problem 3.5 years later? 

> nodetool removenode hangs
> -
>
> Key: CASSANDRA-6542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6542
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Ubuntu 12, 1.2.11 DSE
>Reporter: Eric Lubow
>
> Running *nodetool removenode $host-id* doesn't actually remove the node from 
> the ring.  I've let it run anywhere from 5 minutes to 3 days and there are no 
> messages in the log about it hanging or failing, the command just sits there 
> running.  So the regular response has been to run *nodetool removenode 
> $host-id*, give it about 10-15 minutes and then run *nodetool removenode 
> force*.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

cassandra git commit: Fix broken build

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk f78def39d -> f1b7d6e8e


Fix broken build


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f1b7d6e8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f1b7d6e8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f1b7d6e8

Branch: refs/heads/trunk
Commit: f1b7d6e8eaec73c255a55ddd98b69c4db4334e9a
Parents: f78def3
Author: Aleksey Yeschenko 
Authored: Thu Sep 21 17:28:21 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 17:28:21 2017 +0100

--
 src/java/org/apache/cassandra/service/DataResolver.java | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f1b7d6e8/src/java/org/apache/cassandra/service/DataResolver.java
--
diff --git a/src/java/org/apache/cassandra/service/DataResolver.java 
b/src/java/org/apache/cassandra/service/DataResolver.java
index 1c609b2..b0741da 100644
--- a/src/java/org/apache/cassandra/service/DataResolver.java
+++ b/src/java/org/apache/cassandra/service/DataResolver.java
@@ -661,8 +661,7 @@ public class DataResolver extends ResponseResolver
 if (null != lastClustering)
 filter = filter.forPaging(metadata.comparator, 
lastClustering, false);
 
-return SinglePartitionReadCommand.create(command.isForThrift(),
- command.metadata(),
+return SinglePartitionReadCommand.create(command.metadata(),
  command.nowInSec(),
  
command.columnFilter(),
  command.rowFilter(),


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra

[Marcel Villet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Villet updated CASSANDRA-13891:
--
Description: 
Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
is passed, instead of just returning a NULL itself. Say I create a UDT and a 
table as follows:

create type type1
(
id int,
name text
);

create table table1
(
id int,
t FROZEN,

primary key (id)
);

And then try and insert a row as such:

{{insert into table1 (id, t) VALUES (1, fromJson(null));}}

I get the error: {{java.lang.NullPointerException}}

This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}

Programmatically, one does not always know when a UDT will be null, hence me 
expecting {{fromJson}} to just return NULL.


  was:
Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
is passed, instead of just returning a NULL itself. Say I create a UDT and a 
table as follows:

{{create type type1
(
id int,
name text
);

create table table1
(
id int,
t FROZEN,

primary key (id)
);}}

And then try and insert a row as such:

{{insert into table1 (id, t) VALUES (1, fromJson(null));}}

I get the error: {{java.lang.NullPointerException}}

This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}

Programmatically, one does not always know when a UDT will be null, hence me 
expecting {{fromJson}} to just return NULL.



> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Priority: Minor
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
> is passed, instead of just returning a NULL itself. Say I create a UDT and a 
> table as follows:
> create type type1
> (
> id int,
> name text
> );
>   
> create table table1
> (
> id int,
> t FROZEN,
>   
> primary key (id)
> );
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me 
> expecting {{fromJson}} to just return NULL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra

[Marcel Villet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Villet updated CASSANDRA-13891:
--
Description: 
Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
is passed, instead of just returning a NULL itself. Say I create a UDT and a 
table as follows:

create type type1
(
id int,
name text
);

create table table1
(
id int,
t FROZEN,

primary key (id)
);

And then try and insert a row as such:

{{insert into table1 (id, t) VALUES (1, fromJson(null));}}

I get the error: {{java.lang.NullPointerException}}

This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}

Programmatically, one does not always know when a UDT will be null, hence me 
expecting {{fromJson}} to just return NULL.


  was:
Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
is passed, instead of just returning a NULL itself. Say I create a UDT and a 
table as follows:

{{create type type1
(
id int,
name text
);

create table table1
(
id int,
t FROZEN,

primary key (id)
);}}

And then try and insert a row as such:

{{insert into table1 (id, t) VALUES (1, fromJson(null));}}

I get the error: {{java.lang.NullPointerException}}

This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}

Programmatically, one does not always know when a UDT will be null, hence me 
expecting {{fromJson}} to just return NULL.



> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Priority: Minor
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
> is passed, instead of just returning a NULL itself. Say I create a UDT and a 
> table as follows:
> create type type1
> (
> id int,
> name text
> );
>   
> create table table1
> (
> id int,
> t FROZEN,
>   
> primary key (id)
> );
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me 
> expecting {{fromJson}} to just return NULL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra

[Marcel Villet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Villet updated CASSANDRA-13891:
--
Description: 
Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
is passed, instead of just returning a NULL itself. Say I create a UDT and a 
table as follows:

{{create type type1
(
id int,
name text
);

create table table1
(
id int,
t FROZEN,

primary key (id)
);}}

And then try and insert a row as such:

{{insert into table1 (id, t) VALUES (1, fromJson(null));}}

I get the error: {{java.lang.NullPointerException}}

This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}

Programmatically, one does not always know when a UDT will be null, hence me 
expecting {{fromJson}} to just return NULL.


  was:
Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
is passed, instead of just returning a NULL itself. Say I create a UDT and a 
table as follows:

create type type1
(
id int,
name text
);

create table table1
(
id int,
t FROZEN,

primary key (id)
);

And then try and insert a row as such:

{{insert into table1 (id, t) VALUES (1, fromJson(null));}}

I get the error: {{java.lang.NullPointerException}}

This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}

Programmatically, one does not always know when a UDT will be null, hence me 
expecting {{fromJson}} to just return NULL.



> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Priority: Minor
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
> is passed, instead of just returning a NULL itself. Say I create a UDT and a 
> table as follows:
> {{create type type1
> (
> id int,
> name text
> );
>   
> create table table1
> (
> id int,
> t FROZEN,
>   
> primary key (id)
> );}}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me 
> expecting {{fromJson}} to just return NULL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra

[Marcel Villet (JIRA)]

Marcel Villet created CASSANDRA-13891:
-

 Summary: fromJson(null) throws java.lang.NullPointerException on 
Cassandra
 Key: CASSANDRA-13891
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
 Project: Cassandra
  Issue Type: Bug
  Components: CQL
 Environment: Cassandra 3.11
Reporter: Marcel Villet
Priority: Minor


Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL 
is passed, instead of just returning a NULL itself. Say I create a UDT and a 
table as follows:

{{create type type1
(
id int,
name text
);

create table table1
(
id int,
t FROZEN,

primary key (id)
);}}

And then try and insert a row as such:

{{insert into table1 (id, t) VALUES (1, fromJson(null));}}

I get the error: {{java.lang.NullPointerException}}

This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}

Programmatically, one does not always know when a UDT will be null, hence me 
expecting {{fromJson}} to just return NULL.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/de6f21f5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/de6f21f5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/de6f21f5

Branch: refs/heads/cassandra-3.11
Commit: de6f21f5877d39f99edf9ff1cafaf1de50855905
Parents: 85514ed 2b897d2
Author: Aleksey Yeschenko 
Authored: Thu Sep 21 17:02:15 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 17:02:15 2017 +0100

--
 src/java/org/apache/cassandra/service/DataResolver.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/de6f21f5/src/java/org/apache/cassandra/service/DataResolver.java
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[3/6] cassandra git commit: Pass original command.isForThrift() to SRP extra rows commands

[aleksey]

Pass original command.isForThrift() to SRP extra rows commands

ninja-patch by Aleksey Yeschenko; ninja-reviewed by Sam Tunnicliffe


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2b897d2d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2b897d2d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2b897d2d

Branch: refs/heads/trunk
Commit: 2b897d2ded8604c6340aed1fba3f7495ce36439b
Parents: 36bdc25
Author: Aleksey Yeschenko 
Authored: Thu Sep 21 17:01:14 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 17:01:14 2017 +0100

--
 src/java/org/apache/cassandra/service/DataResolver.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b897d2d/src/java/org/apache/cassandra/service/DataResolver.java
--
diff --git a/src/java/org/apache/cassandra/service/DataResolver.java 
b/src/java/org/apache/cassandra/service/DataResolver.java
index 9a98ee5..f1eedd1 100644
--- a/src/java/org/apache/cassandra/service/DataResolver.java
+++ b/src/java/org/apache/cassandra/service/DataResolver.java
@@ -634,7 +634,8 @@ public class DataResolver extends ResponseResolver
 if (null != lastClustering)
 filter = filter.forPaging(metadata.comparator, 
lastClustering, false);
 
-return SinglePartitionReadCommand.create(command.metadata(),
+return SinglePartitionReadCommand.create(command.isForThrift(),
+ command.metadata(),
  command.nowInSec(),
  
command.columnFilter(),
  command.rowFilter(),


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[aleksey]

Merge branch 'cassandra-3.11' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f78def39
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f78def39
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f78def39

Branch: refs/heads/trunk
Commit: f78def39d364960e17946ce72a6669fd68720ed6
Parents: 79e344f de6f21f
Author: Aleksey Yeschenko 
Authored: Thu Sep 21 17:02:27 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 17:02:27 2017 +0100

--
 src/java/org/apache/cassandra/service/DataResolver.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f78def39/src/java/org/apache/cassandra/service/DataResolver.java
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[1/6] cassandra git commit: Pass original command.isForThrift() to SRP extra rows commands

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 36bdc2531 -> 2b897d2de
  refs/heads/cassandra-3.11 85514ed9e -> de6f21f58
  refs/heads/trunk 79e344fc6 -> f78def39d


Pass original command.isForThrift() to SRP extra rows commands

ninja-patch by Aleksey Yeschenko; ninja-reviewed by Sam Tunnicliffe


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2b897d2d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2b897d2d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2b897d2d

Branch: refs/heads/cassandra-3.0
Commit: 2b897d2ded8604c6340aed1fba3f7495ce36439b
Parents: 36bdc25
Author: Aleksey Yeschenko 
Authored: Thu Sep 21 17:01:14 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 17:01:14 2017 +0100

--
 src/java/org/apache/cassandra/service/DataResolver.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b897d2d/src/java/org/apache/cassandra/service/DataResolver.java
--
diff --git a/src/java/org/apache/cassandra/service/DataResolver.java 
b/src/java/org/apache/cassandra/service/DataResolver.java
index 9a98ee5..f1eedd1 100644
--- a/src/java/org/apache/cassandra/service/DataResolver.java
+++ b/src/java/org/apache/cassandra/service/DataResolver.java
@@ -634,7 +634,8 @@ public class DataResolver extends ResponseResolver
 if (null != lastClustering)
 filter = filter.forPaging(metadata.comparator, 
lastClustering, false);
 
-return SinglePartitionReadCommand.create(command.metadata(),
+return SinglePartitionReadCommand.create(command.isForThrift(),
+ command.metadata(),
  command.nowInSec(),
  
command.columnFilter(),
  command.rowFilter(),


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/de6f21f5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/de6f21f5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/de6f21f5

Branch: refs/heads/trunk
Commit: de6f21f5877d39f99edf9ff1cafaf1de50855905
Parents: 85514ed 2b897d2
Author: Aleksey Yeschenko 
Authored: Thu Sep 21 17:02:15 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 17:02:15 2017 +0100

--
 src/java/org/apache/cassandra/service/DataResolver.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/de6f21f5/src/java/org/apache/cassandra/service/DataResolver.java
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[2/6] cassandra git commit: Pass original command.isForThrift() to SRP extra rows commands

[aleksey]

Pass original command.isForThrift() to SRP extra rows commands

ninja-patch by Aleksey Yeschenko; ninja-reviewed by Sam Tunnicliffe


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2b897d2d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2b897d2d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2b897d2d

Branch: refs/heads/cassandra-3.11
Commit: 2b897d2ded8604c6340aed1fba3f7495ce36439b
Parents: 36bdc25
Author: Aleksey Yeschenko 
Authored: Thu Sep 21 17:01:14 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 17:01:14 2017 +0100

--
 src/java/org/apache/cassandra/service/DataResolver.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b897d2d/src/java/org/apache/cassandra/service/DataResolver.java
--
diff --git a/src/java/org/apache/cassandra/service/DataResolver.java 
b/src/java/org/apache/cassandra/service/DataResolver.java
index 9a98ee5..f1eedd1 100644
--- a/src/java/org/apache/cassandra/service/DataResolver.java
+++ b/src/java/org/apache/cassandra/service/DataResolver.java
@@ -634,7 +634,8 @@ public class DataResolver extends ResponseResolver
 if (null != lastClustering)
 filter = filter.forPaging(metadata.comparator, 
lastClustering, false);
 
-return SinglePartitionReadCommand.create(command.metadata(),
+return SinglePartitionReadCommand.create(command.isForThrift(),
+ command.metadata(),
  command.nowInSec(),
  
command.columnFilter(),
  command.rowFilter(),


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13043) UnavailabeException caused by counter writes forwarded to leaders without complete cluster view

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174886#comment-16174886
 ] 

Aleksey Yeschenko commented on CASSANDRA-13043:
---

Agreed on both accounts. And unfortunately I'm just as uncomfortable with 
bootstrap/gossip myself to make a change there.

Will file a JIRA to start advertising {{RPC_READY}} for Thrift, at least, and 
unconditionally, potentially.

Thanks for your feedback.

> UnavailabeException caused by counter writes forwarded to leaders without 
> complete cluster view
> ---
>
> Key: CASSANDRA-13043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13043
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: Debian
>Reporter: Catalin Alexandru Zamfir
>Assignee: Stefano Ortolani
>Priority: Minor
> Fix For: 3.0.15, 3.11.1
>
> Attachments: 13043-3.0.patch, patch.diff
>
>
> In version 3.9 of Cassandra, we get the following exceptions on the 
> system.log whenever booting an agent. They seem to grow in number with each 
> reboot. Any idea where they come from or what can we do about them? Note that 
> the cluster is healthy (has sufficient live nodes).
> {noformat}
> 2/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-111,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_111]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_111]
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-118,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> 

[jira] [Comment Edited] (CASSANDRA-10404) Node to Node encryption transitional mode

[Stefan Podkowinski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174847#comment-16174847
 ] 

Stefan Podkowinski edited comment on CASSANDRA-10404 at 9/21/17 2:27 PM:
-

I had the following couple of questions/remarks while looking at the patch 
today:

# Assuming we have a 3.x cluster already running with ssl enabled and now start 
to bump the first node to 4.0. If we connect to {{storage_port}} by default in 
4.0, won't the upgraded node fail to start with a "Unable to gossip with any 
seeds" error?
# Do we want to add an option to disable the {{ssl_storage_port}}? E.g. by 
setting it to the same value as storage_port?
# {{doc/source/operating/security.rst}}: needs to be updated
# {{cassandra.yaml}}: comments for {{storage_port}} and {{ssl_storage_port}} 
not accurate anymore, as both can use  encryption now. We also should clearly 
describe the port as legacy port only used during upgrades. There should be a 
link to {{security.rst}} for further details.
# Some of the native transport and internode netty code has become redundant, 
e.g. {{Server.OptionalSecureInitializer}} and the new {{OptionalSslHandler}}. 
It's probably not in scope of this ticket, but should maybe addressed in 
another ticket at some point.
# Use of {{server_encryption}} in {{NettyFactory.OutboundInitializer}} could 
use some comments, especially on why we don't have to check all remaining 
options such as {{internode_encryption}} (already checked in 
{{MessagingService}})



was (Author: spo...@gmail.com):
I had the following couple of questions/remarks while looking at the patch 
today:

* Assuming we have a 3.x cluster already running with ssl enabled and now start 
to bump the first node to 4.0. If we connect to {{storage_port}} by default in 
4.0, won't the upgraded node fail to start with a "Unable to gossip with any 
seeds" error?
* Do we want to add an option to disable the {{ssl_storage_port}}? E.g. by 
setting it to the same value as storage_port?
* {{doc/source/operating/security.rst}}: needs to be updated
* {{cassandra.yaml}}: comments for {{storage_port}} and {{ssl_storage_port}} 
not accurate anymore, as both can use  encryption now. We also should clearly 
describe the port as legacy port only used during upgrades. There should be a 
link to {{security.rst}} for further details.
* Some of the native transport and internode netty code has become redundant, 
e.g. {{Server.OptionalSecureInitializer}} and the new {{OptionalSslHandler}}. 
It's probably not in scope of this ticket, but should maybe addressed in 
another ticket at some point.
* Use of {{server_encryption}} in {{NettyFactory.OutboundInitializer}} could 
use some comments, especially on why we don't have to check all remaining 
options such as {{internode_encryption}} (already checked in 
{{MessagingService}})


> Node to Node encryption transitional mode
> -
>
> Key: CASSANDRA-10404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Tom Lewis
>Assignee: Jason Brown
> Fix For: 4.x
>
>
> Create a transitional mode for encryption that allows encrypted and 
> unencrypted traffic node-to-node during a change over to encryption from 
> unencrypted. This alleviates downtime during the switch.
>  This is similar to CASSANDRA-10559 which is intended for client-to-node



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-10404) Node to Node encryption transitional mode

[Stefan Podkowinski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174847#comment-16174847
 ] 

Stefan Podkowinski commented on CASSANDRA-10404:


I had the following couple of questions/remarks while looking at the patch 
today:

* Assuming we have a 3.x cluster already running with ssl enabled and now start 
to bump the first node to 4.0. If we connect to {{storage_port}} by default in 
4.0, won't the upgraded node fail to start with a "Unable to gossip with any 
seeds" error?
* Do we want to add an option to disable the {{ssl_storage_port}}? E.g. by 
setting it to the same value as storage_port?
* {{doc/source/operating/security.rst}}: needs to be updated
* {{cassandra.yaml}}: comments for {{storage_port}} and {{ssl_storage_port}} 
not accurate anymore, as both can use  encryption now. We also should clearly 
describe the port as legacy port only used during upgrades. There should be a 
link to {{security.rst}} for further details.
* Some of the native transport and internode netty code has become redundant, 
e.g. {{Server.OptionalSecureInitializer}} and the new {{OptionalSslHandler}}. 
It's probably not in scope of this ticket, but should maybe addressed in 
another ticket at some point.
* Use of {{server_encryption}} in {{NettyFactory.OutboundInitializer}} could 
use some comments, especially on why we don't have to check all remaining 
options such as {{internode_encryption}} (already checked in 
{{MessagingService}})


> Node to Node encryption transitional mode
> -
>
> Key: CASSANDRA-10404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Tom Lewis
>Assignee: Jason Brown
> Fix For: 4.x
>
>
> Create a transitional mode for encryption that allows encrypted and 
> unencrypted traffic node-to-node during a change over to encryption from 
> unencrypted. This alleviates downtime during the switch.
>  This is similar to CASSANDRA-10559 which is intended for client-to-node



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13043) UnavailabeException caused by counter writes forwarded to leaders without complete cluster view

[Sylvain Lebresne (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174690#comment-16174690
 ] 

Sylvain Lebresne commented on CASSANDRA-13043:
--

To me, it sounds like the problem we have is that we move endpoints from 
'pending' to 'natural' endpoints too quickly after bootstrap, before the node 
is actually fully ready, and that this is what we should be fixing (basically, 
{{getLiveNaturalEndpoints}} shouldn't return node that are note truly ready, 
and not knowing the ring yet is not ready to me). Maybe counters are the only 
case where this is a problem today, but hand-fixing it only there feels like 
we'll run into other problems like that in the future. That being said, the 
whole boostrap/gossip-settling code is not the part I', the most confortable 
with so I don't know how easy fixing that is (or if it's even 
possible/reasonable to do in 3.x).

Other than that, I agree with you concern. If we want to stick with the current 
approach at least as far 3.x goes for simplicity, then maybe we can simply 
advertise rpc-ready at the end of {{CassandraDaemon.start}} but in all case? In 
fact, I'm not sure why we only set it for the native protocol, and that might 
simply be an oversight. At the very least, thrift is literally referred to 
"rpc" in the yaml, so not setting {{RPC_READY}} for it feels wrong. And going a 
step further, if you have explicitly asked to not start any of the client 
server, then it wouldn't be a lie to set {{RPC_READY}} at the end of 
{{start()}} in the sense of "every RPC servers you asked us to start is ready". 
Anyway, maybe someone rely on this being only set for the native protocol, I 
genuinely have no clue.

> UnavailabeException caused by counter writes forwarded to leaders without 
> complete cluster view
> ---
>
> Key: CASSANDRA-13043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13043
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: Debian
>Reporter: Catalin Alexandru Zamfir
>Assignee: Stefano Ortolani
>Priority: Minor
> Fix For: 3.0.15, 3.11.1
>
> Attachments: 13043-3.0.patch, patch.diff
>
>
> In version 3.9 of Cassandra, we get the following exceptions on the 
> system.log whenever booting an agent. They seem to grow in number with each 
> reboot. Any idea where they come from or what can we do about them? Note that 
> the cluster is healthy (has sufficient live nodes).
> {noformat}
> 2/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-111,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_111]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_111]
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> 

[jira] [Commented] (CASSANDRA-13043) UnavailabeException caused by counter writes forwarded to leaders without complete cluster view

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174601#comment-16174601
 ] 

Aleksey Yeschenko commented on CASSANDRA-13043:
---

Committed the dtest as 
[db1d058af51eafa36151a9eb818f5196bc632767|https://github.com/apache/cassandra-dtest/commit/db1d058af51eafa36151a9eb818f5196bc632767].

Having already committed the patch, I do have one concern. A node only 
advertises that it's rpc-ready if native protocol is enabled. Which won't 
always be true:

1. You might have a thrift-only user
2. You may have a setup with dedicated coordinator nodes, in which storage 
nodes don't even bother listening to clients, and have that disabled

Admittedly both of those are rare, but I'm worried that using {{RPC_READY}} as 
a proxy for 'has some view of the cluster' might break things for some niche 
use cases. [~slebresne], what would you do?

> UnavailabeException caused by counter writes forwarded to leaders without 
> complete cluster view
> ---
>
> Key: CASSANDRA-13043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13043
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: Debian
>Reporter: Catalin Alexandru Zamfir
>Assignee: Stefano Ortolani
>Priority: Minor
> Fix For: 3.0.15, 3.11.1
>
> Attachments: 13043-3.0.patch, patch.diff
>
>
> In version 3.9 of Cassandra, we get the following exceptions on the 
> system.log whenever booting an agent. They seem to grow in number with each 
> reboot. Any idea where they come from or what can we do about them? Note that 
> the cluster is healthy (has sufficient live nodes).
> {noformat}
> 2/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-111,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_111]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_111]
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-118,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  

cassandra-dtest git commit: Add test for CASSANDRA-13043

[aleksey]

Repository: cassandra-dtest
Updated Branches:
  refs/heads/master 163f82c2d -> db1d058af


Add test for CASSANDRA-13043


Project: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/commit/db1d058a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/tree/db1d058a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/diff/db1d058a

Branch: refs/heads/master
Commit: db1d058af51eafa36151a9eb818f5196bc632767
Parents: 163f82c
Author: Stefano Ortolani 
Authored: Thu Aug 31 17:25:15 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 21 12:10:17 2017 +0100

--
 byteman/election_counter_leader_favor_node2.btm | 14 +++
 byteman/gossip_alive_callback_sleep.btm | 13 ++
 counter_tests.py| 42 
 3 files changed, 69 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/db1d058a/byteman/election_counter_leader_favor_node2.btm
--
diff --git a/byteman/election_counter_leader_favor_node2.btm 
b/byteman/election_counter_leader_favor_node2.btm
new file mode 100644
index 000..f3d1ac3
--- /dev/null
+++ b/byteman/election_counter_leader_favor_node2.btm
@@ -0,0 +1,14 @@
+#
+# Cheat during the leader election for a counter mutation and favour node 2, 
127.0.0.2
+#
+# Note that this happens only if the node is known to be available.
+#
+RULE election counter leader cheat
+CLASS org.apache.cassandra.service.StorageProxy
+METHOD findSuitableEndpoint
+AT EXIT
+BIND isthere:boolean = 
$localEndpoints.contains(java.net.InetAddress.getByName("127.0.0.2"));
+if isthere
+DO
+return java.net.InetAddress.getByName("127.0.0.2");
+ENDRULE

http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/db1d058a/byteman/gossip_alive_callback_sleep.btm
--
diff --git a/byteman/gossip_alive_callback_sleep.btm 
b/byteman/gossip_alive_callback_sleep.btm
new file mode 100644
index 000..2621b74
--- /dev/null
+++ b/byteman/gossip_alive_callback_sleep.btm
@@ -0,0 +1,13 @@
+#
+# Slow down how fast a node builds a view on the cluster by postponing when 
gossip settles.
+#
+# Note that this happens only if the node is known to be available.
+#
+RULE slow down falure detector
+CLASS org.apache.cassandra.gms.Gossiper
+METHOD realMarkAlive
+AT ENTRY
+IF TRUE
+DO
+   Thread.sleep(2000);
+ENDRULE
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/db1d058a/counter_tests.py
--
diff --git a/counter_tests.py b/counter_tests.py
index c377060..da2ed09 100644
--- a/counter_tests.py
+++ b/counter_tests.py
@@ -74,6 +74,48 @@ class TestCounters(Tester):
 session = self.patient_cql_connection(node1, 
consistency_level=ConsistencyLevel.ALL)
 assert_one(session, "SELECT COUNT(*) FROM test.test", [1000])
 
+def counter_leader_with_partial_view_test(self):
+"""
+Test leader election with a starting node.
+
+Testing that nodes do not elect as mutation leader a node with a 
partial view on the cluster.
+Note that byteman rules can be syntax checked via the following 
command:
+sh ./bin/bytemancheck.sh -cp 
~/path_to/apache-cassandra-3.0.14-SNAPSHOT.jar ~/path_to/rule.btm
+
+@jira_ticket CASSANDRA-13043
+"""
+cluster = self.cluster
+
+cluster.populate(3, use_vnodes=True, install_byteman=True)
+nodes = cluster.nodelist()
+# Have node 1 and 3 cheat a bit during the leader election for a 
counter mutation; note that cheating
+# takes place iff there is an actual chance for node 2 to be picked.
+
nodes[0].update_startup_byteman_script('./byteman/election_counter_leader_favor_node2.btm')
+
nodes[2].update_startup_byteman_script('./byteman/election_counter_leader_favor_node2.btm')
+cluster.start(wait_for_binary_proto=True)
+session = self.patient_cql_connection(nodes[0])
+create_ks(session, 'ks', 3)
+create_cf(session, 'cf', validation="CounterColumnType", columns={'c': 
'counter'})
+
+# Now stop the node and restart but first install a rule to slow down 
how fast node 2 will update the list
+# nodes that are alive
+nodes[1].stop(wait=True, wait_other_notice=False)
+
nodes[1].update_startup_byteman_script('./byteman/gossip_alive_callback_sleep.btm')
+nodes[1].start(no_wait=True, wait_other_notice=False)
+
+# Until node 2 is fully alive try to force other nodes to pick him as 
mutation leader.
+# If CASSANDRA-13043 is fixed, they will not. Otherwise they 

[jira] [Comment Edited] (CASSANDRA-13885) Allow to run full repairs in 3.0 without additional cost of anti-compaction

[Marcus Eriksson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174313#comment-16174313
 ] 

Marcus Eriksson edited comment on CASSANDRA-13885 at 9/21/17 6:07 AM:
--

-You can run repair with {{-st  -et }} to avoid 
anticompaction in 3.0- uh maybe not, seems you need to figure out the actual 
tokens for each node


was (Author: krummas):
You can run repair with {{-st  -et }} to avoid 
anticompaction in 3.0

> Allow to run full repairs in 3.0 without additional cost of anti-compaction
> ---
>
> Key: CASSANDRA-13885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13885
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Thomas Steinmaurer
>
> This ticket is basically the result of the discussion in Cassandra user list: 
> https://www.mail-archive.com/user@cassandra.apache.org/msg53562.html
> I was asked to open a ticket by Paulo Motta to think about back-porting 
> running full repairs without the additional cost of anti-compaction.
> Basically there is no way in 3.0 to run full repairs from several nodes 
> concurrently without troubles caused by (overlapping?) anti-compactions. 
> Coming from 2.1 this is a major change from an operational POV, basically 
> breaking any e.g. cron job based solution kicking off -pr based repairs on 
> several nodes concurrently.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org