[jira] [Assigned] (CASSANDRA-11114) Document which type conversions are allowed

[Giampaolo (JIRA)]

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

Giampaolo reassigned CASSANDRA-4:
-

Assignee: Giampaolo

> Document which type conversions are allowed
> ---
>
> Key: CASSANDRA-4
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL, Documentation and Website
>Reporter: Sylvain Lebresne
>Assignee: Giampaolo
>Priority: Minor
>  Labels: doc-impacting, lhf
>
> We allow only some type conversion through {{ALTER TABLE}} and type casts, 
> the ones that don't break stuff, but we don't currently document which ones 
> those are. We should add it to 
> http://cassandra.apache.org/doc/cql3/CQL-3.0.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11709) Lock contention when large number of dead nodes come back within short time

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11709:

Assignee: Joel Knighton

> Lock contention when large number of dead nodes come back within short time
> ---
>
> Key: CASSANDRA-11709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11709
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Joel Knighton
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster. 
> We were trying to simulate a data center failure, by disabling the gossip on 
> all the nodes in one data center. After ~20mins, I re-enabled the gossip on 
> those nodes, was doing 5 nodes in each batch, and sleep 5 seconds between the 
> batch.
> After that, I saw the latency of read/write requests increased a lot, and 
> client requests started to timeout.
> On the node, I can see there are huge number of pending tasks in GossipStage. 
> =
> 2016-05-02_23:55:08.99515 WARN  23:55:08 Gossip stage has 36337 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:09.36009 INFO  23:55:09 Node 
> /2401:db00:2020:717a:face:0:41:0 state jump to normal
> 2016-05-02_23:55:09.99057 INFO  23:55:09 Node 
> /2401:db00:2020:717a:face:0:43:0 state jump to normal
> 2016-05-02_23:55:10.09742 WARN  23:55:10 Gossip stage has 36421 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:10.91860 INFO  23:55:10 Node 
> /2401:db00:2020:717a:face:0:45:0 state jump to normal
> 2016-05-02_23:55:11.20100 WARN  23:55:11 Gossip stage has 36558 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:11.57893 INFO  23:55:11 Node 
> /2401:db00:2030:612a:face:0:49:0 state jump to normal
> 2016-05-02_23:55:12.23405 INFO  23:55:12 Node /2401:db00:2020:7189:face:0:7:0 
> state jump to normal
> 
> And I took jstack of the node, I found the read/write threads are blocked by 
> a lock,
>  read thread ==
> "Thrift:7994" daemon prio=10 tid=0x7fde91080800 nid=0x5255 waiting for 
> monitor entry [0x7fde6f8a1000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at 
> org.apache.cassandra.locator.TokenMetadata.cachedOnlyTokenMap(TokenMetadata.java:546)
> - waiting to lock <0x7fe4faef4398> (a 
> org.apache.cassandra.locator.TokenMetadata)
> at 
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:111)
> at 
> org.apache.cassandra.service.StorageService.getLiveNaturalEndpoints(StorageService.java:3155)
> at 
> org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1526)
> at 
> org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1521)
> at 
> org.apache.cassandra.service.AbstractReadExecutor.getReadExecutor(AbstractReadExecutor.java:155)
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1328)
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1270)
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1195)
> at 
> org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:118)
> at 
> org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:275)
> at 
> org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:457)
> at 
> org.apache.cassandra.thrift.CassandraServer.getSliceInternal(CassandraServer.java:346)
> at 
> org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:325)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$get_slice.getResult(Cassandra.java:3659)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$get_slice.getResult(Cassandra.java:3643)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at 
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:205)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> =  writer ===
> "Thrift:7668" daemon prio=10 tid=0x7fde90d91000 nid=0x50e9 waiting for 
> monitor entry [0x7fde78bbc000]
>java.lang.Thread.State: BLOCKED (on object 

[jira] [Resolved] (CASSANDRA-11707) Cassandra not starting

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie resolved CASSANDRA-11707.
-
Resolution: Invalid

> Cassandra not starting
> --
>
> Key: CASSANDRA-11707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: DSE 4.8.5 (Cassandra 2.1.3.1311)
>Reporter: Chandan Kumar
>
> Seeing this Error in the system.log on start one of the nodes of the cluster:
> ERROR [main] 2016-05-03 19:55:40,294  CassandraDaemon.java:581 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.io.EOFException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:99)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:204)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:363) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:336) 
> ~[dse-core-4.8.5.jar:4.8.5]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.DseModule.main(DseModule.java:74) 
> [dse-core-4.8.5.jar:4.8.5]
> Caused by: java.io.EOFException: null
>   at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:86)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   ... 6 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9766) Bootstrap outgoing streaming speeds are much slower than during repair

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9766:
-

Thanks for the modifications.

It LGTM now, I just have two small suggestions and some nits:

* In {{ColumnIndex}} a method to reset the properties that change would have 
been enough, no need to pass in every time {{header, dataFile, 
descriptor.version, observers}} and probably not even 
{{getRowIndexEntrySerializer().indexInfoSerializer()}}. This way these fields 
can return to be final.  
* In BTW, {{columnIndexWriter}} can be created in the constructor so it too can 
be final. 
* Nit: {{indexSamples}} in {{ColumnIndex}} can be final.
* Nit: unused import in {{CompressedInputStream}}: {{java.util.zip.Checksum}}
* Nit: we can restore {{import java.util.\*}} in BTreeSet.java and {{import 
java.util.concurrent.\*}} in BufferPool.java

CI looks good as well:
* the 3 failing dtests also fail on trunk
* the failing utests are all timeouts except for one which also fails on trunk. 
The tests with timeout pass locally and there are timeouts on trunk too.


> Bootstrap outgoing streaming speeds are much slower than during repair
> --
>
> Key: CASSANDRA-9766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9766
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Streaming and Messaging
> Environment: Cassandra 2.1.2. more details in the pdf attached 
>Reporter: Alexei K
>Assignee: T Jake Luciani
>  Labels: performance
> Fix For: 3.x
>
> Attachments: problem.pdf
>
>
> I have a cluster in Amazon cloud , its described in detail in the attachment. 
> What I've noticed is that we during bootstrap we never go above 12MB/sec 
> transmission speeds and also those speeds flat line almost like we're hitting 
> some sort of a limit ( this remains true for other tests that I've ran) 
> however during the repair we see much higher,variable sending rates. I've 
> provided network charts in the attachment as well . Is there an explanation 
> for this? Is something wrong with my configuration, or is it a possible bug?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11709) Lock contention when large number of dead nodes come back within short time

[Dikang Gu (JIRA)]

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

Dikang Gu updated CASSANDRA-11709:
--
Description: 
We have a few hundreds nodes across 3 data centers, and we are doing a few 
millions writes per second into the cluster. 

We were trying to simulate a data center failure, by disabling the gossip on 
all the nodes in one data center. After ~20mins, I re-enabled the gossip on 
those nodes, was doing 5 nodes in each batch, and sleep 5 seconds between the 
batch.

After that, I saw the latency of read/write requests increased a lot, and 
client requests started to timeout.

On the node, I can see there are huge number of pending tasks in GossipStage. 

=
2016-05-02_23:55:08.99515 WARN  23:55:08 Gossip stage has 36337 pending tasks; 
skipping status check (no nodes will be marked down)
2016-05-02_23:55:09.36009 INFO  23:55:09 Node /2401:db00:2020:717a:face:0:41:0 
state jump to normal
2016-05-02_23:55:09.99057 INFO  23:55:09 Node /2401:db00:2020:717a:face:0:43:0 
state jump to normal
2016-05-02_23:55:10.09742 WARN  23:55:10 Gossip stage has 36421 pending tasks; 
skipping status check (no nodes will be marked down)
2016-05-02_23:55:10.91860 INFO  23:55:10 Node /2401:db00:2020:717a:face:0:45:0 
state jump to normal
2016-05-02_23:55:11.20100 WARN  23:55:11 Gossip stage has 36558 pending tasks; 
skipping status check (no nodes will be marked down)
2016-05-02_23:55:11.57893 INFO  23:55:11 Node /2401:db00:2030:612a:face:0:49:0 
state jump to normal
2016-05-02_23:55:12.23405 INFO  23:55:12 Node /2401:db00:2020:7189:face:0:7:0 
state jump to normal


And I took jstack of the node, I found the read/write threads are blocked by a 
lock,

 read thread ==

"Thrift:7994" daemon prio=10 tid=0x7fde91080800 nid=0x5255 waiting for 
monitor entry [0x7fde6f8a1000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.cassandra.locator.TokenMetadata.cachedOnlyTokenMap(TokenMetadata.java:546)
- waiting to lock <0x7fe4faef4398> (a 
org.apache.cassandra.locator.TokenMetadata)
at 
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:111)
at 
org.apache.cassandra.service.StorageService.getLiveNaturalEndpoints(StorageService.java:3155)
at 
org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1526)
at 
org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1521)
at 
org.apache.cassandra.service.AbstractReadExecutor.getReadExecutor(AbstractReadExecutor.java:155)
at 
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1328)
at 
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1270)
at 
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1195)
at 
org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:118)
at 
org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:275)
at 
org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:457)
at 
org.apache.cassandra.thrift.CassandraServer.getSliceInternal(CassandraServer.java:346)
at 
org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:325)
at 
org.apache.cassandra.thrift.Cassandra$Processor$get_slice.getResult(Cassandra.java:3659)
at 
org.apache.cassandra.thrift.Cassandra$Processor$get_slice.getResult(Cassandra.java:3643)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at 
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:205)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)


=  writer ===
"Thrift:7668" daemon prio=10 tid=0x7fde90d91000 nid=0x50e9 waiting for 
monitor entry [0x7fde78bbc000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.cassandra.locator.TokenMetadata.cachedOnlyTokenMap(TokenMetadata.java:546)
- waiting to lock <0x7fe4faef4398> (a 
org.apache.cassandra.locator.TokenMetadata)
at 
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:111)
at 
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:3137)
at 
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:771)
at 
org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:538)
at 

[jira] [Created] (CASSANDRA-11709) Lock contention when large number of dead nodes come back within short time

[Dikang Gu (JIRA)]

Dikang Gu created CASSANDRA-11709:
-

 Summary: Lock contention when large number of dead nodes come back 
within short time
 Key: CASSANDRA-11709
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11709
 Project: Cassandra
  Issue Type: Bug
Reporter: Dikang Gu
 Fix For: 2.2.x, 3.x


We have a few hundreds nodes across 3 data centers, and we are doing a few 
millions writes per second into the cluster. 

We were trying to simulate a data center failure, by disabling the gossip on 
all the nodes in one data center. After ~20mins, I re-enabled the gossip on 
those nodes, was doing 5 nodes in each batch, and sleep 5 seconds between the 
batch.

After that, I saw the latency of read/write requests increased a lot, and 
client requests started to timeout.

On the node, I can see there are huge number of pending tasks in GossipStage. 
And I took jstack of the node, I found the read/write threads are blocked by a 
lock,

 read thread ==

"Thrift:7994" daemon prio=10 tid=0x7fde91080800 nid=0x5255 waiting for 
monitor entry [0x7fde6f8a1000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.cassandra.locator.TokenMetadata.cachedOnlyTokenMap(TokenMetadata.java:546)
- waiting to lock <0x7fe4faef4398> (a 
org.apache.cassandra.locator.TokenMetadata)
at 
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:111)
at 
org.apache.cassandra.service.StorageService.getLiveNaturalEndpoints(StorageService.java:3155)
at 
org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1526)
at 
org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1521)
at 
org.apache.cassandra.service.AbstractReadExecutor.getReadExecutor(AbstractReadExecutor.java:155)
at 
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1328)
at 
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1270)
at 
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1195)
at 
org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:118)
at 
org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:275)
at 
org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:457)
at 
org.apache.cassandra.thrift.CassandraServer.getSliceInternal(CassandraServer.java:346)
at 
org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:325)
at 
org.apache.cassandra.thrift.Cassandra$Processor$get_slice.getResult(Cassandra.java:3659)
at 
org.apache.cassandra.thrift.Cassandra$Processor$get_slice.getResult(Cassandra.java:3643)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at 
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:205)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)


=  writer ===
"Thrift:7668" daemon prio=10 tid=0x7fde90d91000 nid=0x50e9 waiting for 
monitor entry [0x7fde78bbc000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.cassandra.locator.TokenMetadata.cachedOnlyTokenMap(TokenMetadata.java:546)
- waiting to lock <0x7fe4faef4398> (a 
org.apache.cassandra.locator.TokenMetadata)
at 
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:111)
at 
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:3137)
at 
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:771)
at 
org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:538)
at 
org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:613)
at 
org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1101)
at 
org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1083)
at 
org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:976)
at 
org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3996)
at 
org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3980)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
  

[jira] [Created] (CASSANDRA-11708) sstableloader not work with ssl options

[Bin Chen (JIRA)]

Bin Chen created CASSANDRA-11708:


 Summary: sstableloader not work with ssl options
 Key: CASSANDRA-11708
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11708
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Bin Chen
Priority: Minor


My cassandra server start with client_encryption_options.
{code}
client_encryption_options:
enabled: true
keystore: /path/to/keystore.node0
keystore_password: cassandra
require_client_auth: true
truststore: /path/to/truststore.node0
truststore_password: cassandra
{code}
when I use sstableloader with -ts/-tspw/-ks/-kspw, I get
{code}
All host(s) tried for query failed (tried: localhost/127.0.0.1:9042 
(com.datastax.driver.core.TransportException: [localhost/127.0.0.1:9042] 
Channel has been closed))
com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried 
for query failed (tried: localhost/127.0.0.1:9042 
(com.datastax.driver.core.TransportException: [localhost/127.0.0.1:9042] 
Channel has been closed))
{code}

after looked at the code, I found only one way to active ssl is use -f with a 
configuration yaml file which has 
{code}
client_encryption_options:
enabled: true
{code}

so I think it's a bug, better to active ssl when I set -ts and -tspw.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11707) Cassandra not starting

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa edited comment on CASSANDRA-11707 at 5/4/16 3:00 AM:


This jira is for bugs, improvements, and other cassandra-related changes. This 
is almost certainly not a bug in cassandra, but an error in your environment 
(data loss, data corruption, unclean shutdown, etc). You could probably recover 
by removing the commitlogs on disk, but that has the potential for data loss 
depending on your consistency level.  You're running DSE - if you have a DSE 
support contract, contact Datastax. If you don't have a DSE contract, consider 
using the user mailing list, stackoverflow, or the IRC channel for support.


was (Author: jjirsa):
This jira is for bugs, improvements, and other cassandra-related changes. This 
is almost certainly not a bug in cassandra, but an error in your environment 
(data loss, data corruption, unclean shutdown, etc).

You're running DSE - if you have a DSE support contract, contact Datastax. If 
you don't have a DSE contract, consider using the user mailing list, 
stackoverflow, or the IRC channel for support.

> Cassandra not starting
> --
>
> Key: CASSANDRA-11707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: DSE 4.8.5 (Cassandra 2.1.3.1311)
>Reporter: Chandan Kumar
>
> Seeing this Error in the system.log on start one of the nodes of the cluster:
> ERROR [main] 2016-05-03 19:55:40,294  CassandraDaemon.java:581 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.io.EOFException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:99)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:204)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:363) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:336) 
> ~[dse-core-4.8.5.jar:4.8.5]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.DseModule.main(DseModule.java:74) 
> [dse-core-4.8.5.jar:4.8.5]
> Caused by: java.io.EOFException: null
>   at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:86)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   ... 6 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11707) Cassandra not starting

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-11707:


This jira is for bugs, improvements, and other cassandra-related changes. This 
is almost certainly not a bug in cassandra, but an error in your environment 
(data loss, data corruption, unclean shutdown, etc).

You're running DSE - if you have a DSE support contract, contact Datastax. If 
you don't have a DSE contract, consider using the user mailing list, 
stackoverflow, or the IRC channel for support.

> Cassandra not starting
> --
>
> Key: CASSANDRA-11707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: DSE 4.8.5 (Cassandra 2.1.3.1311)
>Reporter: Chandan Kumar
>
> Seeing this Error in the system.log on start one of the nodes of the cluster:
> ERROR [main] 2016-05-03 19:55:40,294  CassandraDaemon.java:581 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.io.EOFException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:99)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:204)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:363) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:336) 
> ~[dse-core-4.8.5.jar:4.8.5]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.DseModule.main(DseModule.java:74) 
> [dse-core-4.8.5.jar:4.8.5]
> Caused by: java.io.EOFException: null
>   at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:86)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   ... 6 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11483) Enhance sstablemetadata

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-11483:
---

I went down path a little of having old and new output... it gets kinda ugly. 
To the point it may be less horrible code wise to just make this a new tool. 
Its already pretty bad with the colors and unicode being either or.

I guess I am more in favor currently of updating the dtests instead. Which 
would be good anyway to test all the new flags. If thats Ok I can make the 
dtest patch. If we really want to support the old format (in which I assume 
would be default), Id rather just see this pushed to 4.0 or whatever version it 
would be Ok to change the output of the tool.

> Enhance sstablemetadata
> ---
>
> Key: CASSANDRA-11483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11483
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 3.x
>
> Attachments: CASSANDRA-11483.txt, CASSANDRA-11483v2.txt, 
> CASSANDRA-11483v3.txt, CASSANDRA-11483v4.txt, Screen Shot 2016-04-03 at 
> 11.40.32 PM.png
>
>
> sstablemetadata provides quite a bit of useful information but theres a few 
> hiccups I would like to see addressed:
> * Does not use client mode
> * Units are not provided (or anything for that matter). There is data in 
> micros, millis, seconds as durations and timestamps from epoch. But there is 
> no way to tell what one is without a non-trival code dive
> * in general pretty frustrating to parse



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11707) Cassandra not starting

[Chandan Kumar (JIRA)]

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

Chandan Kumar updated CASSANDRA-11707:
--
Environment: DSE 4.8.5 (Cassandra 2.1.3.1311)

> Cassandra not starting
> --
>
> Key: CASSANDRA-11707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: DSE 4.8.5 (Cassandra 2.1.3.1311)
>Reporter: Chandan Kumar
>
> Seeing this Error in the system.log on start one of the nodes of the cluster:
> ERROR [main] 2016-05-03 19:55:40,294  CassandraDaemon.java:581 - Exception 
> encountered during startup
> java.lang.RuntimeException: java.io.EOFException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:99)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:204)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:363) 
> ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:336) 
> ~[dse-core-4.8.5.jar:4.8.5]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   at com.datastax.bdp.DseModule.main(DseModule.java:74) 
> [dse-core-4.8.5.jar:4.8.5]
> Caused by: java.io.EOFException: null
>   at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:86)
>  ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
>   ... 6 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11707) Cassandra not starting

[Chandan Kumar (JIRA)]

Chandan Kumar created CASSANDRA-11707:
-

 Summary: Cassandra not starting
 Key: CASSANDRA-11707
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11707
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Chandan Kumar


Seeing this Error in the system.log on start one of the nodes of the cluster:

ERROR [main] 2016-05-03 19:55:40,294  CassandraDaemon.java:581 - Exception 
encountered during startup
java.lang.RuntimeException: java.io.EOFException
at 
org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:99)
 ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
at 
org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:204)
 ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116) 
~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:363) 
~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:336) 
~[dse-core-4.8.5.jar:4.8.5]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564) 
~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
at com.datastax.bdp.DseModule.main(DseModule.java:74) 
[dse-core-4.8.5.jar:4.8.5]
Caused by: java.io.EOFException: null
at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
~[na:1.8.0_60]
at 
org.apache.cassandra.db.commitlog.CommitLogDescriptor.fromHeader(CommitLogDescriptor.java:86)
 ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
... 6 common frames omitted




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11706) Tracing payload not passed through newSession(..)

[mck (JIRA)]

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

mck updated CASSANDRA-11706:

   Labels: tracing  (was: )
Reproduced In: 3.4
   Status: Patch Available  (was: In Progress)

> Tracing payload not passed through newSession(..)
> -
>
> Key: CASSANDRA-11706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11706
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: tracing
> Fix For: 3.6
>
> Attachments: 11706-trunk.txt
>
>
> Caused by CASSANDRA-10392
> There's a small bug in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tracing/Tracing.java#L153
> {noformat}
> public UUID newSession(UUID sessionId, Map 
> customPayload)
> {
> return newSession(sessionId, TraceType.QUERY, Collections.EMPTY_MAP);
> }{noformat}
> in that it passes on an {{EMPTY_MAP}} instead of the {{customPayload}}.
> I've marked this as "minor" as custom tracing plugins can easily enough 
> workaround it by also overriding the {{newSession(UUID sessionId, 
> Map customPayload)}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11706) Tracing payload not passed through newSession(..)

[mck (JIRA)]

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

mck updated CASSANDRA-11706:

Attachment: (was: 11706-trunk.txt)

> Tracing payload not passed through newSession(..)
> -
>
> Key: CASSANDRA-11706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11706
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 3.6
>
> Attachments: 11706-trunk.txt
>
>
> Caused by CASSANDRA-10392
> There's a small bug in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tracing/Tracing.java#L153
> {noformat}
> public UUID newSession(UUID sessionId, Map 
> customPayload)
> {
> return newSession(sessionId, TraceType.QUERY, Collections.EMPTY_MAP);
> }{noformat}
> in that it passes on an {{EMPTY_MAP}} instead of the {{customPayload}}.
> I've marked this as "minor" as custom tracing plugins can easily enough 
> workaround it by also overriding the {{newSession(UUID sessionId, 
> Map customPayload)}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11706) Tracing payload not passed through newSession(..)

[mck (JIRA)]

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

mck updated CASSANDRA-11706:

Attachment: 11706-trunk.txt

> Tracing payload not passed through newSession(..)
> -
>
> Key: CASSANDRA-11706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11706
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 3.6
>
> Attachments: 11706-trunk.txt
>
>
> Caused by CASSANDRA-10392
> There's a small bug in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tracing/Tracing.java#L153
> {noformat}
> public UUID newSession(UUID sessionId, Map 
> customPayload)
> {
> return newSession(sessionId, TraceType.QUERY, Collections.EMPTY_MAP);
> }{noformat}
> in that it passes on an {{EMPTY_MAP}} instead of the {{customPayload}}.
> I've marked this as "minor" as custom tracing plugins can easily enough 
> workaround it by also overriding the {{newSession(UUID sessionId, 
> Map customPayload)}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11706) Tracing payload not passed through newSession(..)

[mck (JIRA)]

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

mck updated CASSANDRA-11706:

Attachment: 11706-trunk.txt

Contains the fix, and one log line improved.

> Tracing payload not passed through newSession(..)
> -
>
> Key: CASSANDRA-11706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11706
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 3.6
>
> Attachments: 11706-trunk.txt
>
>
> Caused by CASSANDRA-10392
> There's a small bug in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tracing/Tracing.java#L153
> {noformat}
> public UUID newSession(UUID sessionId, Map 
> customPayload)
> {
> return newSession(sessionId, TraceType.QUERY, Collections.EMPTY_MAP);
> }{noformat}
> in that it passes on an {{EMPTY_MAP}} instead of the {{customPayload}}.
> I've marked this as "minor" as custom tracing plugins can easily enough 
> workaround it by also overriding the {{newSession(UUID sessionId, 
> Map customPayload)}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11706) Tracing payload not passed through newSession(..)

[mck (JIRA)]

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

mck updated CASSANDRA-11706:

Fix Version/s: 3.6

> Tracing payload not passed through newSession(..)
> -
>
> Key: CASSANDRA-11706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11706
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 3.6
>
>
> Caused by CASSANDRA-10392
> There's a small bug in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tracing/Tracing.java#L153
> {noformat}
> public UUID newSession(UUID sessionId, Map 
> customPayload)
> {
> return newSession(sessionId, TraceType.QUERY, Collections.EMPTY_MAP);
> }{noformat}
> in that it passes on an {{EMPTY_MAP}} instead of the {{customPayload}}.
> I've marked this as "minor" as custom tracing plugins can easily enough 
> workaround it by also overriding the {{newSession(UUID sessionId, 
> Map customPayload)}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11706) Tracing payload not passed through newSession(..)

[mck (JIRA)]

mck created CASSANDRA-11706:
---

 Summary: Tracing payload not passed through newSession(..)
 Key: CASSANDRA-11706
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11706
 Project: Cassandra
  Issue Type: Bug
Reporter: mck
Assignee: mck
Priority: Minor


Caused by CASSANDRA-10392

There's a small bug in 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tracing/Tracing.java#L153

{noformat}
public UUID newSession(UUID sessionId, Map customPayload)
{
return newSession(sessionId, TraceType.QUERY, Collections.EMPTY_MAP);
}{noformat}

in that it passes on an {{EMPTY_MAP}} instead of the {{customPayload}}.

I've marked this as "minor" as custom tracing plugins can easily enough 
workaround it by also overriding the {{newSession(UUID sessionId, 
Map customPayload)}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[Cassandra Wiki] Update of "DataModel" by jeremyhanna

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "DataModel" page has been changed by jeremyhanna:
https://wiki.apache.org/cassandra/DataModel?action=diff=42=43

Comment:
Added a link to Sebastian's data modeler tool and links to twitter accounts.

  
  This allows pervasive denormalization to "pre-build" resultsets at update 
time, rather than doing expensive joins across the cluster.
  
- A blog post by committer Tyler Hobbs that gives 
[[http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling|Basic 
Rules of Cassandra Data Modeling]].
+ A blog post by committer [[https://twitter.com/tylhobbs|Tyler Hobbs]] that 
gives 
[[http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling|Basic 
Rules of Cassandra Data Modeling]].
  
  !DataStax has a free self-paced online course 
[[https://academy.datastax.com/courses/ds220-data-modeling?dxt=blogposting|DS220:
 Data Modeling with Apache Cassandra]].
  
- For more detail, see Patrick !McFadin's data modeling series:
+ A blog post by [[https://twitter.com/syllogistic|Sebastian Estevez]] 
describing a web based tool he created to help visualize data models (pre-3.0) 
as well as gives a tailored cassandra-stress configuration file to test the 
model. [[http://www.datastax.com/dev/blog/data-modeler|Using the Cassandra Data 
Modeler to Stress and Size Cassandra Instances]]
+ 
+ [[https://twitter.com/patrickmcfadin|Patrick McFadin's]] data modeling series:
  
   1. The Data Model is Dead; Long live the Data Model: 
[[http://www.youtube.com/watch?v=px6U2n74q3g|Video]], 
[[http://www.slideshare.net/patrickmcfadin/the-data-model-is-dead-long-live-the-data-model|Slides]]
   1. Become a Super Modeler: 
[[http://www.youtube.com/watch?v=qphhxujn5Es|Video]], 
[[http://www.slideshare.net/patrickmcfadin/become-a-super-modeler|Slides]]

[jira] [Commented] (CASSANDRA-9766) Bootstrap outgoing streaming speeds are much slower than during repair

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-9766:
---

bq. ColumnIndex.create() is only called in BTW.append.

Good point I fixed this so its just re-used vs recycled.

bq. I would suggest leaving BTreeSearchIterator not recycled. 

I agree. I removed all this in the last push.  I'd like to revisit this though 
in a later ticket.

bq. dob.recycle() should be in a finally since serializeRowBody() can throw.

done.

bq. I don't understand this line

I just did it for clarity.

bq. Why do we need to allocate cells lazily in BTreeRow.Builder

The cell builder is recycled on build().  Also the Row Builder is reset() on 
build().  Sometimes the RowBuilder is re-used and sometimes its thrown away.  
So by making the cell builder lazy we ensure the recycled object is only 
allocated when the RowBuilder is re-used.


I also fixed the imports and kicked off the tests again.


> Bootstrap outgoing streaming speeds are much slower than during repair
> --
>
> Key: CASSANDRA-9766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9766
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Streaming and Messaging
> Environment: Cassandra 2.1.2. more details in the pdf attached 
>Reporter: Alexei K
>Assignee: T Jake Luciani
>  Labels: performance
> Fix For: 3.x
>
> Attachments: problem.pdf
>
>
> I have a cluster in Amazon cloud , its described in detail in the attachment. 
> What I've noticed is that we during bootstrap we never go above 12MB/sec 
> transmission speeds and also those speeds flat line almost like we're hitting 
> some sort of a limit ( this remains true for other tests that I've ran) 
> however during the repair we see much higher,variable sending rates. I've 
> provided network charts in the attachment as well . Is there an explanation 
> for this? Is something wrong with my configuration, or is it a possible bug?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10070) Automatic repair scheduling

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-10070:


How closely does this match the design doc from February?  Is it worth posting 
an updated design for those of us joining late?

> Automatic repair scheduling
> ---
>
> Key: CASSANDRA-10070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10070
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Minor
> Fix For: 3.x
>
> Attachments: Distributed Repair Scheduling.doc
>
>
> Scheduling and running repairs in a Cassandra cluster is most often a 
> required task, but this can both be hard for new users and it also requires a 
> bit of manual configuration. There are good tools out there that can be used 
> to simplify things, but wouldn't this be a good feature to have inside of 
> Cassandra? To automatically schedule and run repairs, so that when you start 
> up your cluster it basically maintains itself in terms of normal 
> anti-entropy, with the possibility for manual configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11626) cqlsh fails and exits on non-ascii chars

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-11626:

Reproduced In: 3.5, 3.0.4  (was: 3.0.4, 3.5)
   Status: Patch Available  (was: Open)

Okay, I've pushed a new commit and the second test run looks better.

> cqlsh fails and exits on non-ascii chars
> 
>
> Key: CASSANDRA-11626
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11626
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: Tyler Hobbs
>Priority: Minor
>  Labels: cqlsh
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> Just seen on cqlsh on current trunk:
> To repro, copy {{ä}} (german umlaut) to cqlsh and press return.
> cqlsh errors out and immediately exits.
> {code}
> $ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.13-SNAPSHOT | CQL spec 3.2.1 | Native protocol 
> v3]
> Use HELP for help.
> cqlsh> ä
> Invalid syntax at line 1, char 1
> Traceback (most recent call last):
>   File "/Users/snazy/devel/cassandra/trunk/bin/cqlsh.py", line 2636, in 
> 
> main(*read_options(sys.argv[1:], os.environ))
>   File "/Users/snazy/devel/cassandra/trunk/bin/cqlsh.py", line 2625, in main
> shell.cmdloop()
>   File "/Users/snazy/devel/cassandra/trunk/bin/cqlsh.py", line 1114, in 
> cmdloop
> if self.onecmd(self.statement.getvalue()):
>   File "/Users/snazy/devel/cassandra/trunk/bin/cqlsh.py", line 1139, in onecmd
> self.printerr('  %s' % statementline)
>   File "/Users/snazy/devel/cassandra/trunk/bin/cqlsh.py", line 2314, in 
> printerr
> self.writeresult(text, color, newline=newline, out=sys.stderr)
>   File "/Users/snazy/devel/cassandra/trunk/bin/cqlsh.py", line 2303, in 
> writeresult
> out.write(self.applycolor(str(text), color) + ('\n' if newline else ''))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 
> 2: ordinal not in range(128)
> $ 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11547) Add background thread to check for clock drift

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-11547:
-

OK, I am fine with not adding in "external monitoring", as @tjake referenced in 
the CASSANDRA-8093 discussion.

Closing ticket.

> Add background thread to check for clock drift
> --
>
> Key: CASSANDRA-11547
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11547
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>  Labels: clocks, time
>
> The system clock has the potential to drift while a system is running. As a 
> simple way to check if this occurs, we can run a background thread that wakes 
> up every n seconds, reads the system clock, and checks to see if, indeed, n 
> seconds have passed. 
> * If the clock's current time is less than the last recorded time (captured n 
> seconds in the past), we know the clock has jumped backward.
> * If n seconds have not elapsed, we know the system clock is running slow or 
> has moved backward (by a value less than n)
> * If (n + a small offset) seconds have elapsed, we can assume we are within 
> an acceptable window of clock movement. Reasons for including an offset are 
> the clock checking thread might not have been scheduled on time, or garbage 
> collection, and so on.
> * If the clock is greater than (n + a small offset) seconds, we can assume 
> the clock jumped forward.
> In the unhappy cases, we can write a message to the log and increment some 
> metric that the user's monitoring systems can trigger/alert on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11547) Add background thread to check for clock drift

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-11547:

Resolution: Won't Fix
Status: Resolved  (was: Patch Available)

> Add background thread to check for clock drift
> --
>
> Key: CASSANDRA-11547
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11547
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>  Labels: clocks, time
>
> The system clock has the potential to drift while a system is running. As a 
> simple way to check if this occurs, we can run a background thread that wakes 
> up every n seconds, reads the system clock, and checks to see if, indeed, n 
> seconds have passed. 
> * If the clock's current time is less than the last recorded time (captured n 
> seconds in the past), we know the clock has jumped backward.
> * If n seconds have not elapsed, we know the system clock is running slow or 
> has moved backward (by a value less than n)
> * If (n + a small offset) seconds have elapsed, we can assume we are within 
> an acceptable window of clock movement. Reasons for including an offset are 
> the clock checking thread might not have been scheduled on time, or garbage 
> collection, and so on.
> * If the clock is greater than (n + a small offset) seconds, we can assume 
> the clock jumped forward.
> In the unhappy cases, we can write a message to the log and increment some 
> metric that the user's monitoring systems can trigger/alert on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11477) MerkleTree mismatch when a cell is shadowed by a range tombstone in different SSTables

[Fabien Rousseau (JIRA)]

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

Fabien Rousseau commented on CASSANDRA-11477:
-

Hum, in fact, the patch is not worth reviewing it because it does not work.
(When I did it, I forgot that the code was executed for regular compaction as 
well)

In fact, this ticket is tightly coupled with CASSANDRA-11349. In that ticket, 
there is a patch that attempts to solve this ticket but also CASSANDRA-11349 
and it would be good to have feedback.


> MerkleTree mismatch when a cell is shadowed by a range tombstone in different 
> SSTables
> --
>
> Key: CASSANDRA-11477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11477
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fabien Rousseau
>Assignee: Fabien Rousseau
>  Labels: repair
> Attachments: 11477-2.1.patch
>
>
> Below is a script which allows to reproduce the problem:
> {noformat}
> ccm create test -v 2.1.13 -n 2 -s
> ccm node1 cqlsh
> CREATE KEYSPACE test_rt WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> USE test_rt;
> CREATE TABLE IF NOT EXISTS table1 (
> c1 text,
> c2 text,
> c3 text,
> PRIMARY KEY ((c1), c2)
> );
> INSERT INTO table1 (c1, c2, c3) VALUES ( 'a', 'b', 'c');
> ctrl ^d
> # now flush only one of the two nodes
> ccm node1 flush 
> ccm node1 cqlsh
> USE test_rt;
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> ccm node1 repair test_rt table1
> # now grep the log and observe that there was some inconstencies detected 
> between nodes (while it shouldn't have detected any)
> ccm node1 showlog | grep "out of sync"
> {noformat}
> The wrong hash will be computed on node1, which will include the previously 
> deleted cell, thus resulting in a MT mismatch.
> This is due to the fact that, in LazilyCompactedRow, the RT is not added into 
> the RT tracker (in fact, it's added only if it is GCable, but should always 
> be added).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11503) Need a tool to detect what percentage of SSTables on a node have been repaired when using incremental repairs.

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-11503:
---

I do think theres some value in a global repaired%, since I think some of the 
goal is "do I need to repair" which individual table metrics would not answer.

We could make a keyspace/global version of the table metric as well though.  
Keyspaces with <2 RF and the system distributed are skipped over by repairs. So 
their metrics would show 0%, this would throw off global. Although the table 
globals could just be a custom gauge that returns what the attached does. Also 
we can just axe the RepairMetrics, that sound good?


> Need a tool to detect what percentage of SSTables on a node have been 
> repaired when using incremental repairs.
> --
>
> Key: CASSANDRA-11503
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11503
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Sean Usher
>Assignee: Chris Lohfink
>Priority: Minor
> Attachments: CASSANDRA-11503.patch
>
>
> When using incremental repair, we should be able to look at SSTables and 
> understand how many sstables are in the repaired and unrepaired buckets on 
> each machine. This can help us track the repair progress and if we are 
> hitting any issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11475) MV code refactor

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-11475:


These changes look good; I kicked off CI again, so assuming cassci is happy, 
I'm +1.

> MV code refactor
> 
>
> Key: CASSANDRA-11475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11475
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
>
> While working on CASSANDRA-5546 I run into a problem with TTLs on MVs, which 
> looking more closely is a bug of the MV code. But one thing leading to 
> another I reviewed a good portion of the MV code and found the following 
> correction problems:
> * If a base row is TTLed then even if an update remove that TTL the view 
> entry remained TTLed and expires, leading to an inconsistency.
> * Due to calling the wrong ctor for {{LivenessInfo}}, when a TTL was set on 
> the base table, the view entry was living twice as long as the TTL. Again 
> leading to a temporary inconsistency.
> * When reading existing data to compute view updates, all deletion 
> informations are completely ignored (the code uses a {{PartitionIterator}} 
> instead of an {{UnfilteredPartitionIterator}}). This is a serious issue since 
> it means some deletions could be totally ignored as far as views are 
> concerned especially when messages are delivered to a replica out of order. 
> I'll note that while the 2 previous points are relatively easy to fix, I 
> didn't find an easy and clean way to fix this one on the current code.
> Further, I think the MV code in general has inefficiencies/code complexities 
> that should be avoidable:
> * {{TemporalRow.Set}} is buffering both everything read and a pretty much 
> complete copy of the updates. That's a potentially high memory requirement. 
> We shouldn't have to copy the updates and we shouldn't buffer all reads but 
> rather work incrementally.
> * {{TemporalRow}}/{{TemporalRow.Set}}/{{TemporalCell}} classes are somewhat 
> re-inventing the wheel. They are really just storing both an update we're 
> doing and the corresponding existing data, but we already have 
> {{Row}}/{{Partition}}/{{Cell}} for that. In practice, those {{Temporal*}} 
> class generates a lot of allocations that we could avoid.
> * The code from CASSANDRA-10060 to avoid multiple reads of the base table 
> with multiple views doesn't work when the update has partition/range 
> tombstones because the code uses {{TemporalRow.Set.setTombstonedExisting()}} 
> to trigger reuse, but the {{TemporalRow.Set.withNewViewPrimaryKey()}} method 
> is used between view and it does not preseve the {{hasTombstonedExisting}} 
> flag.  But that oversight, which is trivial to fix, is kind of a good thing 
> since if you fix it, you're left with a correction problem.
>   The read done when there is a partition deletion depends on the view itself 
> (if there is clustering filters in particular) and so reusing that read for 
> other views is wrong. Which makes that whole reuse code really dodgy imo: the 
> read for existing data is in {{View.java}}, suggesting that it depends on the 
> view (which again, it does at least for partition deletion), but it shouldn't 
> if we're going to reuse the result across multiple views.
> * Even ignoring the previous point, we still potentially read the base table 
> twice if the update mix both row updates and partition/range deletions, 
> potentially re-reading the same values.
> * It's probably more minor but the reading code is using {{QueryPager}}, 
> which is probably an artifact of the initial version of the code being 
> pre-8099, but it's not necessary anymore (the reads are local and locally 
> we're completely iterator based), adding, especially when we do page. I'll 
> note that despite using paging, the current code still buffers everything in 
> {{TemporalRow.Set}} anyway .
> Overall, I suspect trying to fix the problems above (particularly the fact 
> that existing deletion infos are ignored) is only going to add complexity 
> with the current code and we'd still have to fix the inefficiencies. So I 
> propose a refactor of that code which does 2 main things:
> # it removes all of {{TemporalRow}} and related classes. Instead, it directly 
> uses the existing {{Row}} (with all its deletion infos) and the update being 
> applied to it and compute the updates for the view from that. I submit that 
> this is more clear/simple, but this also avoid copying every cell of both the 
> existing and update data as a {{TemporalCell}}. We can also reuse codes like 
> {{Rows.merge}} and {{Rows.diff}} to make the handling of deletions relatively 
> painless.
> # instead of dealing with each view one at a time, re-iterating over all 
> 

[jira] [Updated] (CASSANDRA-11518) o.a.c.utils.UUIDGen clock generation is not very high in entropy

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11518:

Reviewer: Branimir Lambov  (was: Joel Knighton)

> o.a.c.utils.UUIDGen clock generation is not very high in entropy
> 
>
> Key: CASSANDRA-11518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11518
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Trivial
> Fix For: 3.0.x, 3.x
>
>
> makeClockSeqAndNode uses {{java.util.Random}} to generate the clock. 
> {{Random}} only has 48-bits of internal state so it's not going to generate 
> the best bits for clock and in addition to that it uses a collision prone 
> seed that sort of defeats the purpose of clock sequence.
> A better approach to get the most out of those 14-bits would be to use 
> {{SecureRandom}} with something like SHA1PRNG.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11011) DateTieredCompactionStrategy not compacting sstables in 2.1.12

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11011:
-

I suspect this is a duplicate of CASSANDRA-11041

> DateTieredCompactionStrategy not compacting  sstables in 2.1.12
> ---
>
> Key: CASSANDRA-11011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11011
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Ubuntu 14.04.3 LTS
> 2.1.12
>Reporter: Alexander Piavlo
>Assignee: Marcus Eriksson
>  Labels: dtcs
>
> The following CF is never compacting from day one
> CREATE TABLE globaldb."DynamicParameter" (
> dp_id bigint PRIMARY KEY,
> dp_advertiser_id int,
> dp_application_id int,
> dp_application_user_id bigint,
> dp_banner_id int,
> dp_campaign_id int,
> dp_click_timestamp timestamp,
> dp_country text,
> dp_custom_parameters text,
> dp_flags bigint,
> dp_ip int,
> dp_machine_id text,
> dp_string text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'max_sstable_age_days': '30', 'base_time_seconds': 
> '3600', 'timestamp_resolution': 'MILLISECONDS', 'enabled': 'true', 
> 'min_threshold': '2', 'class': 
> 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.2
> AND default_time_to_live = 10713600
> AND gc_grace_seconds = 1209600
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11011) DateTieredCompactionStrategy not compacting sstables in 2.1.12

[Anonymous (JIRA)]

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

Anonymous updated CASSANDRA-11011:
--
Resolution: Duplicate
Status: Resolved  (was: Awaiting Feedback)

> DateTieredCompactionStrategy not compacting  sstables in 2.1.12
> ---
>
> Key: CASSANDRA-11011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11011
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Ubuntu 14.04.3 LTS
> 2.1.12
>Reporter: Alexander Piavlo
>Assignee: Marcus Eriksson
>  Labels: dtcs
>
> The following CF is never compacting from day one
> CREATE TABLE globaldb."DynamicParameter" (
> dp_id bigint PRIMARY KEY,
> dp_advertiser_id int,
> dp_application_id int,
> dp_application_user_id bigint,
> dp_banner_id int,
> dp_campaign_id int,
> dp_click_timestamp timestamp,
> dp_country text,
> dp_custom_parameters text,
> dp_flags bigint,
> dp_ip int,
> dp_machine_id text,
> dp_string text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'max_sstable_age_days': '30', 'base_time_seconds': 
> '3600', 'timestamp_resolution': 'MILLISECONDS', 'enabled': 'true', 
> 'min_threshold': '2', 'class': 
> 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.2
> AND default_time_to_live = 10713600
> AND gc_grace_seconds = 1209600
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10635) Add metrics for authentication failures

[Soumava Ghosh (JIRA)]

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

Soumava Ghosh commented on CASSANDRA-10635:
---

Yeah, sorry for the delay, I'm looking at this right now  and I should be back 
with a patch within the next few days.

> Add metrics for authentication failures
> ---
>
> Key: CASSANDRA-10635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10635
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Soumava Ghosh
>Assignee: Soumava Ghosh
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 10635-2.1.txt, 10635-2.2.txt, 10635-3.0.txt
>
>
> There should be no auth failures on a cluster in general. 
> Having metrics around the authentication code would help detect clients 
> that are connecting to the wrong cluster or have auth incorrectly configured.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11661) Cassandra 2.0 and later require Java 7u25 or later - jdk 101

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11661:

Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

[Committed|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=5202147d9f4077afe6ac185654fa153c7fbd6f95].
 

Thanks!

> Cassandra 2.0 and later require Java 7u25 or later - jdk 101
> 
>
> Key: CASSANDRA-11661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11661
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Cassandra Server 2.1.5 and Java jdk1.7.0_101-b14
>Reporter: William Boutin
>Assignee: Eduard Tudenhoefner
>Priority: Critical
> Fix For: 2.1.15, 2.2.7, 3.7, 3.0.7
>
> Attachments: 11661-2.1.patch, 11661-2.2.patch, 11661-3.0.patch
>
>
> We have been running the cassandr server version 2.1.5. Friday, we applied 
> the latest java patch, Java(TM) SE Runtime Environment (build 1.7.0_101-b14). 
> Cassandra cannot start with this patch. The cassandra log states:  Cassandra 
> 2.0 and later require Java 7u25 or later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[14/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.7

[jmckenzie]

Merge branch 'cassandra-3.0' into cassandra-3.7


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

Branch: refs/heads/trunk
Commit: 54d7fc4b021a7b4b1e9db16131b815cdfea1b88f
Parents: 0095499 c7d216e
Author: Josh McKenzie 
Authored: Tue May 3 14:06:57 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:06:57 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/54d7fc4b/conf/cassandra-env.sh
--

[06/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[jmckenzie]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/trunk
Commit: 8bf453a4491c766ec8a920a12f8a87111a7546e4
Parents: d3db33c 5202147
Author: Josh McKenzie 
Authored: Tue May 3 14:05:23 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:05:23 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8bf453a4/conf/cassandra-env.sh
--

[11/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[jmckenzie]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.7
Commit: c7d216e3fe86535948d521aa96db3bdac56cfafc
Parents: 5244787 8bf453a
Author: Josh McKenzie 
Authored: Tue May 3 14:06:03 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:06:18 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c7d216e3/conf/cassandra-env.sh
--
diff --cc conf/cassandra-env.sh
index 0ba0c4e,b519b76..44fe110
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@@ -97,8 -99,8 +97,8 @@@ if [ "$JVM_VERSION" \< "1.8" ] ; the
  exit 1;
  fi
  
- if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "40" ] ; then
 -if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 -echo "Cassandra 2.0 and later require Java 7u25 or later."
++if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 40 ] ; then
 +echo "Cassandra 3.0 and later require Java 8u40 or later."
  exit 1;
  fi
  

[08/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[jmckenzie]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.0
Commit: 8bf453a4491c766ec8a920a12f8a87111a7546e4
Parents: d3db33c 5202147
Author: Josh McKenzie 
Authored: Tue May 3 14:05:23 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:05:23 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8bf453a4/conf/cassandra-env.sh
--

[02/15] cassandra git commit: Use -lt comparator for JVM patch version

[jmckenzie]

Use -lt comparator for JVM patch version

Patch by etudenhoefner; reviewed by mshuler for CASSANDRA-11661


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

Branch: refs/heads/cassandra-2.2
Commit: 5202147d9f4077afe6ac185654fa153c7fbd6f95
Parents: 86c5a00
Author: Eduard Tudenhoefner 
Authored: Tue May 3 13:55:21 2016 +0200
Committer: Josh McKenzie 
Committed: Tue May 3 14:04:16 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5202147d/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index eccea48..13e9cc7 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -99,7 +99,7 @@ if [ "$JVM_VERSION" \< "1.7" ] ; then
 exit 1;
 fi
 
-if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "25" ] ; then
+if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 echo "Cassandra 2.0 and later require Java 7u25 or later."
 exit 1;
 fi

[09/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[jmckenzie]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.7
Commit: 8bf453a4491c766ec8a920a12f8a87111a7546e4
Parents: d3db33c 5202147
Author: Josh McKenzie 
Authored: Tue May 3 14:05:23 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:05:23 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8bf453a4/conf/cassandra-env.sh
--

[13/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.7

[jmckenzie]

Merge branch 'cassandra-3.0' into cassandra-3.7


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

Branch: refs/heads/cassandra-3.7
Commit: 54d7fc4b021a7b4b1e9db16131b815cdfea1b88f
Parents: 0095499 c7d216e
Author: Josh McKenzie 
Authored: Tue May 3 14:06:57 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:06:57 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/54d7fc4b/conf/cassandra-env.sh
--

[10/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[jmckenzie]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: c7d216e3fe86535948d521aa96db3bdac56cfafc
Parents: 5244787 8bf453a
Author: Josh McKenzie 
Authored: Tue May 3 14:06:03 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:06:18 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c7d216e3/conf/cassandra-env.sh
--
diff --cc conf/cassandra-env.sh
index 0ba0c4e,b519b76..44fe110
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@@ -97,8 -99,8 +97,8 @@@ if [ "$JVM_VERSION" \< "1.8" ] ; the
  exit 1;
  fi
  
- if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "40" ] ; then
 -if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 -echo "Cassandra 2.0 and later require Java 7u25 or later."
++if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 40 ] ; then
 +echo "Cassandra 3.0 and later require Java 8u40 or later."
  exit 1;
  fi
  

[03/15] cassandra git commit: Use -lt comparator for JVM patch version

[jmckenzie]

Use -lt comparator for JVM patch version

Patch by etudenhoefner; reviewed by mshuler for CASSANDRA-11661


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

Branch: refs/heads/trunk
Commit: 5202147d9f4077afe6ac185654fa153c7fbd6f95
Parents: 86c5a00
Author: Eduard Tudenhoefner 
Authored: Tue May 3 13:55:21 2016 +0200
Committer: Josh McKenzie 
Committed: Tue May 3 14:04:16 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5202147d/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index eccea48..13e9cc7 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -99,7 +99,7 @@ if [ "$JVM_VERSION" \< "1.7" ] ; then
 exit 1;
 fi
 
-if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "25" ] ; then
+if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 echo "Cassandra 2.0 and later require Java 7u25 or later."
 exit 1;
 fi

[12/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[jmckenzie]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: c7d216e3fe86535948d521aa96db3bdac56cfafc
Parents: 5244787 8bf453a
Author: Josh McKenzie 
Authored: Tue May 3 14:06:03 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:06:18 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c7d216e3/conf/cassandra-env.sh
--
diff --cc conf/cassandra-env.sh
index 0ba0c4e,b519b76..44fe110
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@@ -97,8 -99,8 +97,8 @@@ if [ "$JVM_VERSION" \< "1.8" ] ; the
  exit 1;
  fi
  
- if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "40" ] ; then
 -if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 -echo "Cassandra 2.0 and later require Java 7u25 or later."
++if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 40 ] ; then
 +echo "Cassandra 3.0 and later require Java 8u40 or later."
  exit 1;
  fi
  

[05/15] cassandra git commit: Use -lt comparator for JVM patch version

[jmckenzie]

Use -lt comparator for JVM patch version

Patch by etudenhoefner; reviewed by mshuler for CASSANDRA-11661


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

Branch: refs/heads/cassandra-3.7
Commit: 5202147d9f4077afe6ac185654fa153c7fbd6f95
Parents: 86c5a00
Author: Eduard Tudenhoefner 
Authored: Tue May 3 13:55:21 2016 +0200
Committer: Josh McKenzie 
Committed: Tue May 3 14:04:16 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5202147d/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index eccea48..13e9cc7 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -99,7 +99,7 @@ if [ "$JVM_VERSION" \< "1.7" ] ; then
 exit 1;
 fi
 
-if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "25" ] ; then
+if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 echo "Cassandra 2.0 and later require Java 7u25 or later."
 exit 1;
 fi

[01/15] cassandra git commit: Use -lt comparator for JVM patch version

[jmckenzie]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 86c5a00c2 -> 5202147d9
  refs/heads/cassandra-2.2 d3db33c00 -> 8bf453a44
  refs/heads/cassandra-3.0 52447873a -> c7d216e3f
  refs/heads/cassandra-3.7 009549927 -> 54d7fc4b0
  refs/heads/trunk b0806f8f1 -> 17d30c9e5


Use -lt comparator for JVM patch version

Patch by etudenhoefner; reviewed by mshuler for CASSANDRA-11661


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

Branch: refs/heads/cassandra-2.1
Commit: 5202147d9f4077afe6ac185654fa153c7fbd6f95
Parents: 86c5a00
Author: Eduard Tudenhoefner 
Authored: Tue May 3 13:55:21 2016 +0200
Committer: Josh McKenzie 
Committed: Tue May 3 14:04:16 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5202147d/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index eccea48..13e9cc7 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -99,7 +99,7 @@ if [ "$JVM_VERSION" \< "1.7" ] ; then
 exit 1;
 fi
 
-if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "25" ] ; then
+if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 echo "Cassandra 2.0 and later require Java 7u25 or later."
 exit 1;
 fi

[04/15] cassandra git commit: Use -lt comparator for JVM patch version

[jmckenzie]

Use -lt comparator for JVM patch version

Patch by etudenhoefner; reviewed by mshuler for CASSANDRA-11661


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

Branch: refs/heads/cassandra-3.0
Commit: 5202147d9f4077afe6ac185654fa153c7fbd6f95
Parents: 86c5a00
Author: Eduard Tudenhoefner 
Authored: Tue May 3 13:55:21 2016 +0200
Committer: Josh McKenzie 
Committed: Tue May 3 14:04:16 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5202147d/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index eccea48..13e9cc7 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -99,7 +99,7 @@ if [ "$JVM_VERSION" \< "1.7" ] ; then
 exit 1;
 fi
 
-if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" \< "25" ] ; then
+if [ "$JVM_VERSION" \< "1.8" ] && [ "$JVM_PATCH_VERSION" -lt 25 ] ; then
 echo "Cassandra 2.0 and later require Java 7u25 or later."
 exit 1;
 fi

[07/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[jmckenzie]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: 8bf453a4491c766ec8a920a12f8a87111a7546e4
Parents: d3db33c 5202147
Author: Josh McKenzie 
Authored: Tue May 3 14:05:23 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:05:23 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8bf453a4/conf/cassandra-env.sh
--

[15/15] cassandra git commit: Merge branch 'cassandra-3.7' into trunk

[jmckenzie]

Merge branch 'cassandra-3.7' into trunk


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

Branch: refs/heads/trunk
Commit: 17d30c9e52693e3f9dee3f07fb8838273dd25daf
Parents: b0806f8 54d7fc4
Author: Josh McKenzie 
Authored: Tue May 3 14:07:12 2016 -0400
Committer: Josh McKenzie 
Committed: Tue May 3 14:07:12 2016 -0400

--
 conf/cassandra-env.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--

[jira] [Commented] (CASSANDRA-11678) cassandra crush when enable hints_compression

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-11678:
-

The problem here is that there are 1-3 extra bytes at the end of an 
uncompressed block. The hints reader tries to read the length of the next hint, 
but there's not enough buffer/file remaining, causing the eof exception. 
[~iamaleksey] could you sanity check my write logic 
([here|https://github.com/bdeggleston/cassandra/blob/c20566fa64031dd30a1f731eee1394264977eb6f/src/java/org/apache/cassandra/hints/CompressedHintsWriter.java#L45-L45])
 and read logic 
([here|https://github.com/bdeggleston/cassandra/blob/ac7e2793debe6de27d5ca50ce9afc3ff9a17f88d/src/java/org/apache/cassandra/hints/CompressedChecksummedDataInput.java#L54-L54])?
 Maybe there's an off-by-one error, or something that might cause 
[CompressedChecksummedDataInput.isEOF|https://github.com/bdeggleston/cassandra/blob/ac7e2793debe6de27d5ca50ce9afc3ff9a17f88d/src/java/org/apache/cassandra/hints/CompressedChecksummedDataInput.java#L49-L49]
 to return a false negative, that I'm missing.

> cassandra crush when enable hints_compression
> -
>
> Key: CASSANDRA-11678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11678
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, Local Write-Read Paths
> Environment: Centos 7
>Reporter: Weijian Lin
>Assignee: Blake Eggleston
>Priority: Critical
>
> When I enable hints_compression and set the compression class to
> LZ4Compressor，the
> cassandra (v3.05, V3.5.0) will crush。That is a bug, or any conf is wrong?
> *Exception in V 3.5.0 *
> {code}
> ERROR [HintsDispatcher:2] 2016-04-26 15:02:56,970
> HintsDispatchExecutor.java:225 - Failed to dispatch hints file
> abc4dda2-b551-427e-bb0b-e383d4a392e1-1461654138963-1.hints: file is
> corrupted ({})
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at 
> org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:284)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:254)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatcher.sendHints(HintsDispatcher.java:156)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:137)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:119) 
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:91) 
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:259)
>  [apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
>  [apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
>  [apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
>  [apache-cassandra-3.5.0.jar:3.5.0]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_65]
> Caused by: java.io.EOFException: null
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:146)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readPrimitiveSlowly(RebufferingInputStream.java:108)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readInt(RebufferingInputStream.java:188)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNextInternal(HintsReader.java:297)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:280)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> ... 15 common frames omitted
> {code}
> *Exception in V 3.0.5 *
> {code}
> ERROR [HintsDispatcher:2] 2016-04-26 15:54:46,294
> 

[jira] [Commented] (CASSANDRA-10635) Add metrics for authentication failures

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10635:
-

[~soumava], did you get a chance to revisit this?

> Add metrics for authentication failures
> ---
>
> Key: CASSANDRA-10635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10635
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Soumava Ghosh
>Assignee: Soumava Ghosh
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 10635-2.1.txt, 10635-2.2.txt, 10635-3.0.txt
>
>
> There should be no auth failures on a cluster in general. 
> Having metrics around the authentication code would help detect clients 
> that are connecting to the wrong cluster or have auth incorrectly configured.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11547) Add background thread to check for clock drift

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-11547:


I'm really not understanding the purpose of this ticket.  Esp. if the end 
result is "we can write a message to the log and increment some metric that the 
user's monitoring systems can trigger/alert on."  

 You can read more about this general thought process in the resolution of 
CASSANDRA-8093

> Add background thread to check for clock drift
> --
>
> Key: CASSANDRA-11547
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11547
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>  Labels: clocks, time
>
> The system clock has the potential to drift while a system is running. As a 
> simple way to check if this occurs, we can run a background thread that wakes 
> up every n seconds, reads the system clock, and checks to see if, indeed, n 
> seconds have passed. 
> * If the clock's current time is less than the last recorded time (captured n 
> seconds in the past), we know the clock has jumped backward.
> * If n seconds have not elapsed, we know the system clock is running slow or 
> has moved backward (by a value less than n)
> * If (n + a small offset) seconds have elapsed, we can assume we are within 
> an acceptable window of clock movement. Reasons for including an offset are 
> the clock checking thread might not have been scheduled on time, or garbage 
> collection, and so on.
> * If the clock is greater than (n + a small offset) seconds, we can assume 
> the clock jumped forward.
> In the unhappy cases, we can write a message to the log and increment some 
> metric that the user's monitoring systems can trigger/alert on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11641) java.lang.IllegalArgumentException: Not enough bytes in system.log

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11641:
-

[~wavelet] any update here?

> java.lang.IllegalArgumentException: Not enough bytes in system.log
> --
>
> Key: CASSANDRA-11641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11641
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: centos 6.5 cassandra2.1.13
>Reporter: peng xiao
>Assignee: Paulo Motta
> Attachments: system.log
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10194) Deadlock on startup

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-10194:


It's no longer impacting us (potentially because we have far fewer sstables 
than we used to, or because it was somehow fixed in 2.1.8 or 2.1.9. 



> Deadlock on startup
> ---
>
> Key: CASSANDRA-10194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10194
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
> Attachments: aggregated thread dump, cassandra-thread
>
>
> Possible deadlock on startup. Seen on 2.1.5 and 2.1.7. Thread dump attached. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10194) Deadlock on startup

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-10194:
---
Resolution: Cannot Reproduce
Status: Resolved  (was: Awaiting Feedback)

> Deadlock on startup
> ---
>
> Key: CASSANDRA-10194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10194
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
> Attachments: aggregated thread dump, cassandra-thread
>
>
> Possible deadlock on startup. Seen on 2.1.5 and 2.1.7. Thread dump attached. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11518) o.a.c.utils.UUIDGen clock generation is not very high in entropy

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11518:

Reviewer: Joel Knighton  (was: Branimir Lambov)

> o.a.c.utils.UUIDGen clock generation is not very high in entropy
> 
>
> Key: CASSANDRA-11518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11518
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Trivial
> Fix For: 3.0.x, 3.x
>
>
> makeClockSeqAndNode uses {{java.util.Random}} to generate the clock. 
> {{Random}} only has 48-bits of internal state so it's not going to generate 
> the best bits for clock and in addition to that it uses a collision prone 
> seed that sort of defeats the purpose of clock sequence.
> A better approach to get the most out of those 14-bits would be to use 
> {{SecureRandom}} with something like SHA1PRNG.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11517) o.a.c.utils.UUIDGen could handle contention better

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11517:

Reviewer: Joel Knighton  (was: Branimir Lambov)

> o.a.c.utils.UUIDGen could handle contention better
> --
>
> Key: CASSANDRA-11517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11517
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.x
>
>
> I noticed this profiling a query handler implementation that uses UUIDGen to 
> get handles to track queries for logging purposes.
> Under contention threads are being unscheduled instead of spinning until the 
> lock is available. I would have expected intrinsic locks to be able to adapt 
> to this based on profiling information.
> Either way it's seems pretty straightforward to rewrite this to use a CAS 
> loop and test that it generally produces unique values.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11641) java.lang.IllegalArgumentException: Not enough bytes in system.log

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11641:

Assignee: Paulo Motta

> java.lang.IllegalArgumentException: Not enough bytes in system.log
> --
>
> Key: CASSANDRA-11641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11641
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: centos 6.5 cassandra2.1.13
>Reporter: peng xiao
>Assignee: Paulo Motta
> Attachments: system.log
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11011) DateTieredCompactionStrategy not compacting sstables in 2.1.12

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11011:

Assignee: Marcus Eriksson

> DateTieredCompactionStrategy not compacting  sstables in 2.1.12
> ---
>
> Key: CASSANDRA-11011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11011
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Ubuntu 14.04.3 LTS
> 2.1.12
>Reporter: Alexander Piavlo
>Assignee: Marcus Eriksson
>  Labels: dtcs
>
> The following CF is never compacting from day one
> CREATE TABLE globaldb."DynamicParameter" (
> dp_id bigint PRIMARY KEY,
> dp_advertiser_id int,
> dp_application_id int,
> dp_application_user_id bigint,
> dp_banner_id int,
> dp_campaign_id int,
> dp_click_timestamp timestamp,
> dp_country text,
> dp_custom_parameters text,
> dp_flags bigint,
> dp_ip int,
> dp_machine_id text,
> dp_string text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'max_sstable_age_days': '30', 'base_time_seconds': 
> '3600', 'timestamp_resolution': 'MILLISECONDS', 'enabled': 'true', 
> 'min_threshold': '2', 'class': 
> 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.2
> AND default_time_to_live = 10713600
> AND gc_grace_seconds = 1209600
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11011) DateTieredCompactionStrategy not compacting sstables in 2.1.12

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11011:

Reviewer: Carl Yeksigian

> DateTieredCompactionStrategy not compacting  sstables in 2.1.12
> ---
>
> Key: CASSANDRA-11011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11011
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Ubuntu 14.04.3 LTS
> 2.1.12
>Reporter: Alexander Piavlo
>Assignee: Marcus Eriksson
>  Labels: dtcs
>
> The following CF is never compacting from day one
> CREATE TABLE globaldb."DynamicParameter" (
> dp_id bigint PRIMARY KEY,
> dp_advertiser_id int,
> dp_application_id int,
> dp_application_user_id bigint,
> dp_banner_id int,
> dp_campaign_id int,
> dp_click_timestamp timestamp,
> dp_country text,
> dp_custom_parameters text,
> dp_flags bigint,
> dp_ip int,
> dp_machine_id text,
> dp_string text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'max_sstable_age_days': '30', 'base_time_seconds': 
> '3600', 'timestamp_resolution': 'MILLISECONDS', 'enabled': 'true', 
> 'min_threshold': '2', 'class': 
> 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.2
> AND default_time_to_live = 10713600
> AND gc_grace_seconds = 1209600
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10945) rebuild fail ,received file doesn't exist?

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10945:

Resolution: Cannot Reproduce
Status: Resolved  (was: Awaiting Feedback)

Closing as cannot reproduce after 5 months no update.

If you're on Windows, please upgrade to 2.2+ since we fixed a bunch of the file 
access problems on that release.

> rebuild fail ,received file doesn't exist?
> --
>
> Key: CASSANDRA-10945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10945
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 2.1.0
> java version "1.7.0_80"
>Reporter: wateray
>
> we rebuild dc1 from dc1.
> Rebuild file have received completely.
> Rebuild 41cf1460-aade-11e5-8a0c-e7d99dc4b078
> /172.16.0.100
> Receiving 16 files, 514112829261 bytes total. Already received 16 
> files, 514112829261 bytes total
> /172.16.0.101
> Receiving 12 files, 620055599407 bytes total. Already received 12 
> files, 620055599407 bytes total
> 
> But rebuild log didn't show streamsession end.
> We found the following errors:
> ERROR [StreamReceiveTask:4] 2015-12-27 10:56:13,133 CassandraDaemon.java:227 
> - Exception in thread Thread[StreamReceiveTask:4,5,RMI Runtime]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:159) 
> ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:154) 
> ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.java:558) 
> ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.rename(SSTableWriter.java:546) 
> ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.close(SSTableWriter.java:520) 
> ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.finish(SSTableWriter.java:453) 
> ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:445)
>  ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:440)
>  ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:128)
>  ~[apache-cassandra-2.1.10.jar:2.1.10]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_80]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
> ~[na:1.7.0_80]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_80]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_80]
> It is seems that just received file doesn't existed.How is that happened?
> Some other thread change or remove that file?
> And streamsession doesn't end up normally even exception is also a problem I 
> think.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10714) tcp retransmission issue seen in cassandra cluster

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-10714:
-

So to clarify - are you seeing this on other hosts on AWS running C*, or just 
other hosts on AWS in general? i.e. is this a problem that's localized to C* or 
is it something further reaching and thus not something we should dig into 
further from the perspective of it being a potential C* problem?

> tcp retransmission issue seen in cassandra cluster
> --
>
> Key: CASSANDRA-10714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10714
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Liu
>
> I have been seen tcp package retransmission issue in various stacks in our 
> environment. ( AWS with no VPC). I'm currently using hsha rpc server type on 
> cassandra 2.1.6 version. The information captured by wireshark shows that the 
> retransmission happened both between client-to-server and server-to-server. 
> Even within a cluster that doesn't have any client traffic, sporadic 
> retransmission still happens.
> It's pretty easy to reproduce this issue by watching "netstat -s | grep 
> retrans". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10766) OOM from 22000 memtables

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10766:

   Resolution: Duplicate
Fix Version/s: (was: 3.0.x)
   (was: 2.2.x)
   (was: 2.1.x)
   (was: 3.x)
   Status: Resolved  (was: Awaiting Feedback)

Closing as duplicate of CASSANDRA-8496.

> OOM from 22000 memtables 
> -
>
> Key: CASSANDRA-10766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10766
> Project: Cassandra
>  Issue Type: Bug
> Environment: * 32 cores, physical machines
> * 8 SSD drives in raid 0
> * hotspot java 8.60 
> * Linux version 3.8.13-98.el6uek.x86_64 (mockbuild@x86-ol6-builder-04) (gcc 
> version 4.4.7 20120313 (Red Hat 4.4.7-11)
> * G1 heap with 26 GB heap, 24 concurrent and 24 parallel threads, 500 ms 
> pause target
>Reporter: amorton
>Assignee: amorton
> Attachments: MemtableFlushWriter.txt, SlabPoolCleaner.txt, 
> lots-of-memtables.png, thread-dump-flush.txt, thread-dump-full.txt
>
>
> Hi folks, we observed this on a new cassandra 2.1.11 cluster. 
> The node ran out of memory, and when it did it had 22,000 + memtables in 
> memory with a corresponding number of pending MemtableFlushWriter and 
> MemtablePostFlushWriter tasks. We have seen other nodes going OOM, but have 
> not looked at them as deeply as this one.
> We also noticed that while there was 8 flush writers configured, there were 
> times when only one (or maybe two) were making progress. And that there was 
> times when the SlabPoolCleaner was flushing memtables 50 times a second. 
> I'll try to put as much info below that makes sense. I have the full system 
> logs and a heap dump and can go through them with someone if needed. Please 
> ping me on IRC or the usual email if I am not on. 
> Below is part of the Heap Dump showing the huge amount of memtables in ram. 
> I have also attached copied of the same thread dump:
> * thread-dump-full.txt is the full dump, node that is includes approximately 
> 300 shared worker threads. 
> * thread-dump-flush.txt is the MemtableFlushWriter and MemtablePostFlush 
> threads. 
> Note that all the MemtableFlushWriter threads are trying to update the 
> DataTracker, and that the MemtablePostFlush is waiting on the countdown latch 
> to be set. The PostFlush object in the MemtablePostFlush thread is associated 
> with the MemtableFlushWriter:744 thread. 
> Looking at the MemtableFlushWriter threads they are trying to flush the 
> following tables:
> {noformat}
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:750" 266120 120
> system.hints
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:744" 223864 120
> system.sstable_activity
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:752" 220848 120
> system.sstable_activity
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:754" 219736 120
> system.sstable_activity
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:749" 214336 120
> system.sstable_activity
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:753" 211632 120
> system.sstable_activity
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:748" 149616 120
> system.sstable_activity
> java.lang.Thread [Thread, Stack Local] "MemtableFlushWriter:751" 143480 120
> system.sstable_activity
> {noformat}
> When I saw that these were all on the same table I was wondering if the CAS 
> in {{DataTracker.replaceFlushed()}} was starving some threads. 
> The attached SlabPoolCleaner.txt file is the lines from the SlabPoolCleaner 
> thread from a couple of system.log files. Notes:
> * The machine went OOM at 08:38:25,463 server time. 
> * The server was flushing user tables between 100 and 200 MB until approx 
> 2015-11-22 07:40:39,669 server time.
> * After that the server was flushing files that were 10's of bytes. 
> The attached MemtableFlushWriter.txt includes log lines from the 
> MemtableFlushWriter threads. Notes:
> * from approx 2015-11-22 07:41:18 it often looks like only one 
> MemtableFlushWriter thread progresses at a time. 
> A few other notes:
> * This machine has logged a few dozen LEAK DETECTED messages. 
> * This has logged messages about corrupted SSTables. 
> At this point I am unsure if the SlabPoolCleaner was reacting to low memory 
> and correctly flushing, or it was incorrectly flushing a lot which overloaded 
> the flush system. We are also unsure what role the CAS in 
> {{DataTracker.replaceFlushed()}} played, all the MemtableFlushWriter threads 
> with the same progress seems odd.
> As a test for the CAS theory we ran the node with {{memtable_flush_writers}} 
> set to 2, it has been running for approx 12 hours under load and has not 
> OOM'd yet. This is a good sign. 
> Any 

[jira] [Updated] (CASSANDRA-8496) Remove MemtablePostFlusher

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-8496:
---
Assignee: Branimir Lambov

> Remove MemtablePostFlusher
> --
>
> Key: CASSANDRA-8496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8496
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Assignee: Branimir Lambov
>Priority: Minor
>
> To improve clearing of the CL, prevent infinite growth, and ensure the prompt 
> completion of tasks waiting on flush in the case of transient errors, large 
> flushes or slow disks, in 2.1 we could eliminate the post flusher altogether. 
> Since we now enforce that Memtables track contiguous ranges, a relatively 
> small change would permit Memtables to know the exact minimum as well as the 
> currently known exact maximum. The CL could easily track the total dirty 
> range, knowing that it must be contiguous, by using an AtomicLong instead of 
> an AtomicInteger, and tracking both the min/max seen, not just the max. The 
> only slight complexity will come in for tracking the _clean_ range as this 
> can now be non-contiguous, if there are 3 memtable flushes covering the same 
> CL segment, and one of them completes later. To solve this we can use an 
> interval tree since these operations are infrequent, so the extra overhead is 
> nominal. Once the interval tree completely overlaps the dirty range, we mark 
> the entire dirty range clean.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10714) tcp retransmission issue seen in cassandra cluster

[Jeff Liu (JIRA)]

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

Jeff Liu commented on CASSANDRA-10714:
--

[~JoshuaMcKenzie], Josh, I think it's related to the aws network. I'm seeing it 
on other hosts as well.

> tcp retransmission issue seen in cassandra cluster
> --
>
> Key: CASSANDRA-10714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10714
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Liu
>
> I have been seen tcp package retransmission issue in various stacks in our 
> environment. ( AWS with no VPC). I'm currently using hsha rpc server type on 
> cassandra 2.1.6 version. The information captured by wireshark shows that the 
> retransmission happened both between client-to-server and server-to-server. 
> Even within a cluster that doesn't have any client traffic, sporadic 
> retransmission still happens.
> It's pretty easy to reproduce this issue by watching "netstat -s | grep 
> retrans". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10714) tcp retransmission issue seen in cassandra cluster

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-10714:
-

[~jeffl]: Are you still seeing this issue, or did it resolve via other means 
(software/firmware/hardware changes)?

> tcp retransmission issue seen in cassandra cluster
> --
>
> Key: CASSANDRA-10714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10714
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Liu
>
> I have been seen tcp package retransmission issue in various stacks in our 
> environment. ( AWS with no VPC). I'm currently using hsha rpc server type on 
> cassandra 2.1.6 version. The information captured by wireshark shows that the 
> retransmission happened both between client-to-server and server-to-server. 
> Even within a cluster that doesn't have any client traffic, sporadic 
> retransmission still happens.
> It's pretty easy to reproduce this issue by watching "netstat -s | grep 
> retrans". 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10687) When adding new node to cluster getting Cassandra timeout during write query

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10687:

Resolution: Cannot Reproduce
Status: Resolved  (was: Awaiting Feedback)

[~eyalso]: Closing this as cannot reproduce. Please feel free to re-open if 
you're still seeing it on a 2.1/2.2 release of C*.

> When adding new node to cluster getting Cassandra timeout during write query
> 
>
> Key: CASSANDRA-10687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Coordination, Streaming and Messaging
> Environment: Cassandra 2.0.9 using vnodes, on Debian 7.9,  on two 
> data centers (AUS & TAM)
>Reporter: Eyal Sorek
>
> When adding one new node on 8 nodes cluster (also again after completing 
> adding the 9th in AUS data center and again when adding the 10th node on TAM 
> data center with same behaviour).
> We get many of the following errors below.
> First - why this, when the node is joining :
> LOCAL_ONE (2 replica were required but only 1 acknowledged the write
> Since when LOCAL_ONE requires 2 replicas ?
> Second, why we fill so much overhead on the all cluster, when a node is 
> joining ?
> com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout 
> during write query at consistency LOCAL_ONE (2 replica were required but only 
> 1 acknowledged the write)
> Sample stack trace
> …stax.driver.core.exceptions.WriteTimeoutException.copy 
> (WriteTimeoutException.java:73)
> …m.datastax.driver.core.DriverThrowables.propagateCause 
> (DriverThrowables.java:37)
> ….driver.core.DefaultResultSetFuture.getUninterruptibly 
> (DefaultResultSetFuture.java:214)
>com.datastax.driver.core.AbstractSession.execute 
> (AbstractSession.java:52)
> com.wixpress.publichtml.renderer.data.access.dao.page.CassandraPagesReadWriteDao$$anonfun$insertCompressed$1.apply(CassandraPagesReadWriteDao.scala:29)
> com.wixpress.publichtml.renderer.data.access.dao.page.CassandraPagesReadWriteDao$$anonfun$insertCompressed$1.apply(CassandraPagesReadWriteDao.scala:25)
> com.wixpress.framework.monitoring.metering.SyncMetering$class.tracking(Metering.scala:58)
> com.wixpress.publichtml.renderer.data.access.dao.page.CassandraPagesReadOnlyDao.tracking(CassandraPagesReadOnlyDao.scala:19)
> com.wixpress.publichtml.renderer.data.access.dao.page.CassandraPagesReadWriteDao.insertCompressed(CassandraPagesReadWriteDao.scala:25)
> com.wixpress.html.data.distributor.core.DaoPageDistributor.com$wixpress$html$data$distributor$core$DaoPageDistributor$$distributePage(DaoPageDistributor.scala:36)
> com.wixpress.html.data.distributor.core.DaoPageDistributor$$anonfun$process$1.apply$mcV$sp(DaoPageDistributor.scala:26)
> com.wixpress.html.data.distributor.core.DaoPageDistributor$$anonfun$process$1.apply(DaoPageDistributor.scala:26)
> com.wixpress.html.data.distributor.core.DaoPageDistributor$$anonfun$process$1.apply(DaoPageDistributor.scala:26)
> com.wixpress.framework.monitoring.metering.SyncMetering$class.tracking(Metering.scala:58)
> com.wixpress.html.data.distributor.core.DaoPageDistributor.tracking(DaoPageDistributor.scala:17)
> com.wixpress.html.data.distributor.core.DaoPageDistributor.process(DaoPageDistributor.scala:25)
> com.wixpress.html.data.distributor.core.greyhound.DistributionRequestHandler.handleMessage(DistributionRequestHandler.scala:19)
> com.wixpress.greyhound.KafkaUserHandlers.handleMessage(UserHandlers.scala:11)
> com.wixpress.greyhound.EventsConsumer.com$wixpress$greyhound$EventsConsumer$$handleMessage(EventsConsumer.scala:51)
> com.wixpress.greyhound.EventsConsumer$$anonfun$com$wixpress$greyhound$EventsConsumer$$dispatch$1.apply$mcV$sp(EventsConsumer.scala:43)
> com.wixpress.greyhound.EventsConsumer$$anonfun$com$wixpress$greyhound$EventsConsumer$$dispatch$1.apply(EventsConsumer.scala:40)
> com.wixpress.greyhound.EventsConsumer$$anonfun$com$wixpress$greyhound$EventsConsumer$$dispatch$1.apply(EventsConsumer.scala:40)
> scala.util.Try$.apply(Try.scala:192)
> com.wixpress.greyhound.EventsConsumer.com$wixpress$greyhound$EventsConsumer$$dispatch(EventsConsumer.scala:40)
> com.wixpress.greyhound.EventsConsumer$$anonfun$consumeEvents$1.apply(EventsConsumer.scala:26)
> com.wixpress.greyhound.EventsConsumer$$anonfun$consumeEvents$1.apply(EventsConsumer.scala:25)
> scala.collection.Iterator$class.foreach(Iterator.scala:742)
> scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
> com.wixpress.greyhound.EventsConsumer.consumeEvents(EventsConsumer.scala:25)
> com.wixpress.greyhound.EventsConsumer.run(EventsConsumer.scala:20)
>   java.util.concurrent.ThreadPoolExecutor.runWorker 
> (ThreadPoolExecutor.java:1142)
>  

[jira] [Updated] (CASSANDRA-11570) Concurrent execution of prepared statement returns invalid JSON as result

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-11570:

Resolution: Duplicate
Status: Resolved  (was: Awaiting Feedback)

I'm going to go ahead and resolve this as a duplicate of CASSANDRA-11048.  If 
anybody is able to reproduce this issue in a version with that fix, we can 
reopen this ticket.

> Concurrent execution of prepared statement returns invalid JSON as result
> -
>
> Key: CASSANDRA-11570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11570
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.2, C++ or C# driver
>Reporter: Alexander Ryabets
>Assignee: Tyler Hobbs
> Attachments: CassandraPreparedStatementsTest.zip, broken_output.txt, 
> test_neptunao.cql, valid_output.txt
>
>
> When I use prepared statement for async execution of multiple statements I 
> get JSON with broken data. Keys got totally corrupted when values seems to be 
> normal though.
> First I encoutered this issue when I were performing stress testing of our 
> project using custom script. We are using DataStax C++ driver and execute 
> statements from different fibers.
> Then I was trying to isolate problem and wrote simple C# program which starts 
> multiple Tasks in a loop. Each task uses the once created prepared statement 
> to read data from the base. As you can see results are totally mess.
> I 've attached archive with console C# project (1 cs file) which just print 
> resulting JSON to user. 
> Here is the main part of C# code.
> {noformat}
> static void Main(string[] args)
> {
>   const int task_count = 300;
>   using(var cluster = Cluster.Builder().AddContactPoints(/*contact points 
> here*/).Build())
>   {
> using(var session = cluster.Connect())
> {
>   var prepared = session.Prepare("select json * from test_neptunao.ubuntu 
> where id=?");
>   var tasks = new Task[task_count];
>   for(int i = 0; i < task_count; i++)
>   {
> tasks[i] = Query(prepared, session);
>   }
>   Task.WaitAll(tasks);
> }
>   }
>   Console.ReadKey();
> }
> private static Task Query(PreparedStatement prepared, ISession session)
> {
>   string id = GetIdOfRandomRow();
>   var stmt = prepared.Bind(id);
>   stmt.SetConsistencyLevel(ConsistencyLevel.One);
>   return session.ExecuteAsync(stmt).ContinueWith(tr =>
>   {
> foreach(var row in tr.Result)
> {
>   var value = row.GetValue(0);
>   //some kind of output
> }
>   });
> }
> {noformat}
> I also attached cql script with test DB schema.
> {noformat}
> CREATE KEYSPACE IF NOT EXISTS test_neptunao
> WITH replication = {
>   'class' : 'SimpleStrategy',
>   'replication_factor' : 3
> };
> use test_neptunao;
> create table if not exists ubuntu (
>   id timeuuid PRIMARY KEY,
>   precise_pangolin text,
>   trusty_tahr text,
>   wily_werewolf text, 
>   vivid_vervet text,
>   saucy_salamander text,
>   lucid_lynx text
> );
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10303) streaming for 'nodetool rebuild' fails after adding a datacenter

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10303:

   Resolution: Fixed
Fix Version/s: (was: 2.1.x)
   Status: Resolved  (was: Awaiting Feedback)

Closing as fixed since we haven't heard anything in 5 months and 
CASSANDRA-10012 should resolve at least some of what was brought up here.

Feel free to reopen if there's still something here we need to resolve.

> streaming for 'nodetool rebuild' fails after adding a datacenter 
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
>  Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 - 
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160) 
> ~[guava-16.0.jar:na]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) 
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) 
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59) 
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109) 
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) 
> ~[na:1.7.0_60]
> at 
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
>  ~[apache-cassandra-2.1.8.jar:2.1.8]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to 
> success



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11678) cassandra crush when enable hints_compression

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-11678:

Description: 
When I enable hints_compression and set the compression class to
LZ4Compressor，the
cassandra (v3.05, V3.5.0) will crush。That is a bug, or any conf is wrong?


*Exception in V 3.5.0 *

{code}
ERROR [HintsDispatcher:2] 2016-04-26 15:02:56,970
HintsDispatchExecutor.java:225 - Failed to dispatch hints file
abc4dda2-b551-427e-bb0b-e383d4a392e1-1461654138963-1.hints: file is
corrupted ({})
org.apache.cassandra.io.FSReadError: java.io.EOFException
at 
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:284)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:254)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHints(HintsDispatcher.java:156) 
~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:137)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:119) 
~[apache-cassandra-3.5.0.jar:3.5.0]
at org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:91) 
~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:259)
 [apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
 [apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
 [apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
 [apache-cassandra-3.5.0.jar:3.5.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_65]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_65]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_65]
Caused by: java.io.EOFException: null
at 
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:146)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.io.util.RebufferingInputStream.readPrimitiveSlowly(RebufferingInputStream.java:108)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.io.util.RebufferingInputStream.readInt(RebufferingInputStream.java:188)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNextInternal(HintsReader.java:297)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
at 
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:280)
 ~[apache-cassandra-3.5.0.jar:3.5.0]
... 15 common frames omitted
{code}

*Exception in V 3.0.5 *

{code}
ERROR [HintsDispatcher:2] 2016-04-26 15:54:46,294
HintsDispatchExecutor.java:225 - Failed to dispatch hints file
8603be13-6878-4de3-8bc3-a7a7146b0376-1461657251205-1.hints: file is
corrupted ({})
org.apache.cassandra.io.FSReadError: java.io.EOFException
at 
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:282)
 ~[apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:252)
 ~[apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHints(HintsDispatcher.java:156) 
~[apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:137)
 ~[apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:119) 
~[apache-cassandra-3.0.5.jar:3.0.5]
at org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:91) 
~[apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:259)
 [apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
 [apache-cassandra-3.0.5.jar:3.0.5]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
 [apache-cassandra-3.0.5.jar:3.0.5]
at 

[jira] [Commented] (CASSANDRA-10287) nodetool rebuild does not work with join_ring=false

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-10287:
-

cc [~pauloricardomg] / [~yukim] (assignee/reviewer)

> nodetool rebuild does not work with join_ring=false
> ---
>
> Key: CASSANDRA-10287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10287
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van den Berge
>Assignee: Paulo Motta
>
> I'm setting up a new data center as described in 
> http://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_add_dc_to_cluster_t.html,
>  with one change: I'm starting the new node with join_ring=false, because I 
> want to prevent reads to be routed to the new node.
> When starting nodetool rebuild as described in 7b, the command immediately 
> returns. In the log file, I can see a message that states the the streaming 
> is started. Then nothing happens, not even after a few hours of waiting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10287) nodetool rebuild does not work with join_ring=false

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10287:

Assignee: Paulo Motta
Reviewer: Yuki Morishita

> nodetool rebuild does not work with join_ring=false
> ---
>
> Key: CASSANDRA-10287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10287
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van den Berge
>Assignee: Paulo Motta
>
> I'm setting up a new data center as described in 
> http://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_add_dc_to_cluster_t.html,
>  with one change: I'm starting the new node with join_ring=false, because I 
> want to prevent reads to be routed to the new node.
> When starting nodetool rebuild as described in 7b, the command immediately 
> returns. In the log file, I can see a message that states the the streaming 
> is started. Then nothing happens, not even after a few hours of waiting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10194) Deadlock on startup

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-10194:
-

[~jjirsa]: You ever get closure on this?

> Deadlock on startup
> ---
>
> Key: CASSANDRA-10194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10194
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
> Attachments: aggregated thread dump, cassandra-thread
>
>
> Possible deadlock on startup. Seen on 2.1.5 and 2.1.7. Thread dump attached. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-9660) Error while adding a node to existing cluster

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-9660:
---
   Resolution: Cannot Reproduce
Fix Version/s: (was: 2.1.x)
   Status: Resolved  (was: Awaiting Feedback)

Closing as cannot reproduce as we haven't had an update in... a long time. Feel 
free to re-open if you can reproduce reliably or have further information on 
the problem.

> Error while adding a node to existing cluster
> -
>
> Key: CASSANDRA-9660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9660
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: pankaj mishra
>Assignee: pankaj mishra
>
> Hi,
> We are trying to add a fresh node to existing cluster of cassandra. Currently 
> it has two nodes. While adding, it continue for a while and then node stops 
> after throwing following exception. I have restarted several times but it 
> fails every time. 
> {code}
> ERROR 11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Streaming error 
> occurred
> java.io.IOException: net.jpountz.lz4.LZ4Exception: Error decoding offset 
> 24114 of input buffer
>   at 
> org.apache.cassandra.io.compress.LZ4Compressor.uncompress(LZ4Compressor.java:93)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.compress.CompressedInputStream.decompress(CompressedInputStream.java:114)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.compress.CompressedInputStream.read(CompressedInputStream.java:92)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at java.io.InputStream.read(InputStream.java:170) ~[na:1.8.0_45]
>   at java.io.DataInputStream.readFully(DataInputStream.java:195) 
> ~[na:1.8.0_45]
>   at java.io.DataInputStream.readLong(DataInputStream.java:416) 
> ~[na:1.8.0_45]
>   at 
> org.apache.cassandra.utils.BytesReadTracker.readLong(BytesReadTracker.java:114)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:131)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:86)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52) 
> ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46) 
> ~[apache-cassandra-2.1.6.jar:2.1.6]
>   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.SSTableWriter.appendFromStream(SSTableWriter.java:286)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.StreamReader.writeRow(StreamReader.java:156) 
> ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:89)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:48)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:38)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:250)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> Caused by: net.jpountz.lz4.LZ4Exception: Error decoding offset 24114 of input 
> buffer
>   at 
> net.jpountz.lz4.LZ4JNIFastDecompressor.decompress(LZ4JNIFastDecompressor.java:33)
>  ~[lz4-1.2.0.jar:na]
>   at 
> org.apache.cassandra.io.compress.LZ4Compressor.uncompress(LZ4Compressor.java:88)
>  ~[apache-cassandra-2.1.6.jar:2.1.6]
>   ... 20 common frames omitted
> INFO  11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Session with 
> /192.168.36.81 is complete
> WARN  11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Stream failed
> ERROR 11:13:54 Exception encountered during startup
> java.lang.RuntimeException: Error during boostrap: Stream failed
>   at 
> org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86) 
> ~[apache-cassandra-2.1.6.jar:2.1.6]
>   at 
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1121)
>  

[jira] [Updated] (CASSANDRA-8152) Cassandra crashes with Native memory allocation failure

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-8152:
---
   Resolution: Cannot Reproduce
Reproduced In: 2.1.2, 2.1.0  (was: 2.1.0, 2.1.2)
   Status: Resolved  (was: Awaiting Feedback)

Closing as cannot reproduce as it's been half a year since last update. If you 
can get the information requested onto the ticket, we'd be happy to re-open and 
look into this further.

> Cassandra crashes with Native memory allocation failure
> ---
>
> Key: CASSANDRA-8152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8152
> Project: Cassandra
>  Issue Type: Bug
> Environment: EC2 (i2.xlarge)
>Reporter: Babar Tareen
>Priority: Minor
> Attachments: db06_hs_err_pid26159.log.zip, 
> db_05_hs_err_pid25411.log.zip
>
>
> On a 6 node Cassandra (datastax-community-2.1) cluster running on EC2 
> (i2.xlarge) instances, Jvm hosting the cassandra service randomly crashes 
> with following error.
> {code}
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 12288 bytes for 
> committing reserved memory.
> # Possible reasons:
> #   The system is out of physical RAM or swap space
> #   In 32 bit mode, the process size limit was hit
> # Possible solutions:
> #   Reduce memory load on the system
> #   Increase physical memory or swap space
> #   Check if swap backing store is full
> #   Use 64 bit Java on a 64 bit OS
> #   Decrease Java heap size (-Xmx/-Xms)
> #   Decrease number of Java threads
> #   Decrease Java thread stack sizes (-Xss)
> #   Set larger code cache with -XX:ReservedCodeCacheSize=
> # This output file may be truncated or incomplete.
> #
> #  Out of Memory Error (os_linux.cpp:2747), pid=26159, tid=140305605682944
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 
> 1.7.0_60-b19)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode 
> linux-amd64 compressed oops)
> # Failed to write core dump. Core dumps have been disabled. To enable core 
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> ---  T H R E A D  ---
> Current thread (0x08341000):  JavaThread "MemtableFlushWriter:2055" 
> daemon [_thread_new, id=23336, stack(0x7f9b71c56000,0x7f9b71c97000)]
> Stack: [0x7f9b71c56000,0x7f9b71c97000],  sp=0x7f9b71c95820,  free 
> space=254k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0x99e7ca]  VMError::report_and_die()+0x2ea
> V  [libjvm.so+0x496fbb]  report_vm_out_of_memory(char const*, int, unsigned 
> long, char const*)+0x9b
> V  [libjvm.so+0x81d81e]  os::Linux::commit_memory_impl(char*, unsigned long, 
> bool)+0xfe
> V  [libjvm.so+0x81d8dc]  os::pd_commit_memory(char*, unsigned long, bool)+0xc
> V  [libjvm.so+0x81565a]  os::commit_memory(char*, unsigned long, bool)+0x2a
> V  [libjvm.so+0x81bdcd]  os::pd_create_stack_guard_pages(char*, unsigned 
> long)+0x6d
> V  [libjvm.so+0x9522de]  JavaThread::create_stack_guard_pages()+0x5e
> V  [libjvm.so+0x958c24]  JavaThread::run()+0x34
> V  [libjvm.so+0x81f7f8]  java_start(Thread*)+0x108
> {code}
> Changes in cassandra-env.sh settings
> {code}
> MAX_HEAP_SIZE="8G"
> HEAP_NEWSIZE="800M"
> JVM_OPTS="$JVM_OPTS -XX:TargetSurvivorRatio=50"
> JVM_OPTS="$JVM_OPTS -XX:+AggressiveOpts"
> JVM_OPTS="$JVM_OPTS -XX:+UseLargePages"
> {code}
> Writes are about 10K-15K/sec and there are very few reads. Cassandra 2.0.9 
> with same settings never crashed. JVM crash logs are attached from two 
> machines.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-7306:
---
Reviewer: Aleksey Yeschenko

> Support "edge dcs" with more flexible gossip
> 
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Tupshin Harper
>Assignee: Jeff Jirsa
>  Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more 
> complex, there is more and more need for a notion of "hub" and "spoke" 
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs, 
> is the assumption that all dcs need to talk to each other (and be connected 
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be 
> an optional per-dc annotation of which other DCs that DC could gossip with.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11503) Need a tool to detect what percentage of SSTables on a node have been repaired when using incremental repairs.

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-11503:


Thanks for the patch Chris!

Adding RepairMetrics is nice idea, though isn't it useful to have repaired% per 
table rather than accumulating repaired% accross all tables?
If so, maybe moving repaired% to TableMetrics is better, and we can show it 
through {{nodetool tablestats}}.

For the code, I prefer moving {{RepairMetrics}} to {{ActiveRepairService}} and 
passing it to {{RepairSession}} constructor, so we don't have to access 
{{StorageService.instance}} singleton.

> Need a tool to detect what percentage of SSTables on a node have been 
> repaired when using incremental repairs.
> --
>
> Key: CASSANDRA-11503
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11503
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Sean Usher
>Assignee: Chris Lohfink
>Priority: Minor
> Attachments: CASSANDRA-11503.patch
>
>
> When using incremental repair, we should be able to look at SSTables and 
> understand how many sstables are in the repaired and unrepaired buckets on 
> each machine. This can help us track the repair progress and if we are 
> hitting any issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11615) cassandra-stress blocks when connecting to a big cluster

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11615:

Reviewer: T Jake Luciani

> cassandra-stress blocks when connecting to a big cluster
> 
>
> Key: CASSANDRA-11615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11615
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
> Fix For: 3.0.x
>
> Attachments: 11615-3.0-2nd.patch, 11615-3.0.patch
>
>
> I had a *100* node cluster and was running 
> {code}
> cassandra-stress read n=100 no-warmup cl=LOCAL_QUORUM -rate 'threads=20' 
> 'limit=1000/s'
> {code}
> Based on the thread dump it looks like it's been blocked at 
> https://github.com/apache/cassandra/blob/cassandra-3.0/tools/stress/src/org/apache/cassandra/stress/util/JavaDriverClient.java#L96
> {code}
> "Thread-20" #245 prio=5 os_prio=0 tid=0x7f3781822000 nid=0x46c4 waiting 
> for monitor entry [0x7f36cc788000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at 
> org.apache.cassandra.stress.util.JavaDriverClient.prepare(JavaDriverClient.java:96)
> - waiting to lock <0x0005c003d920> (a 
> java.util.concurrent.ConcurrentHashMap)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation$JavaDriverWrapper.createPreparedStatement(CqlOperation.java:314)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:77)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
> at 
> org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
> "Thread-19" #244 prio=5 os_prio=0 tid=0x7f378182 nid=0x46c3 waiting 
> for monitor entry [0x7f36cc889000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at 
> org.apache.cassandra.stress.util.JavaDriverClient.prepare(JavaDriverClient.java:96)
> - waiting to lock <0x0005c003d920> (a 
> java.util.concurrent.ConcurrentHashMap)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation$JavaDriverWrapper.createPreparedStatement(CqlOperation.java:314)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:77)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:109)
> at 
> org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:261)
> at 
> org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:327)
> {code}
> I was trying the same with with a smaller cluster (50 nodes) and it was 
> working fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11569) Track message latency across DCs

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11569:

Reviewer: Carl Yeksigian

> Track message latency across DCs
> 
>
> Key: CASSANDRA-11569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11569
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Attachments: CASSANDRA-11569.patch
>
>
> Since we have the timestamp a message is created and when arrives, we can get 
> an approximate time it took relatively easy and would remove necessity for 
> more complex hacks to determine latency between DCs.
> Although is not going to be very meaningful when ntp is not setup, it is 
> pretty common to have NTP setup and even with clock drift nothing is really 
> hurt except the metric becoming whacky.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11552) Reduce amount of logging calls from ColumnFamilyStore.selectAndReference

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11552:

Reviewer: Benjamin Lerer

> Reduce amount of logging calls from ColumnFamilyStore.selectAndReference
> 
>
> Key: CASSANDRA-11552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11552
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>
> {{org.apache.cassandra.db.ColumnFamilyStore#selectAndReference}} logs two 
> messages at _info_ level "as fast as it can" if it waits for more than 100ms.
> The following code is executed in a while-true fashion in this case:
> {code}
> logger.info("Spinning trying to capture released readers {}", 
> released);
> logger.info("Spinning trying to capture all readers {}", 
> view.sstables);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11547) Add background thread to check for clock drift

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11547:

Reviewer: T Jake Luciani

> Add background thread to check for clock drift
> --
>
> Key: CASSANDRA-11547
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11547
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>  Labels: clocks, time
>
> The system clock has the potential to drift while a system is running. As a 
> simple way to check if this occurs, we can run a background thread that wakes 
> up every n seconds, reads the system clock, and checks to see if, indeed, n 
> seconds have passed. 
> * If the clock's current time is less than the last recorded time (captured n 
> seconds in the past), we know the clock has jumped backward.
> * If n seconds have not elapsed, we know the system clock is running slow or 
> has moved backward (by a value less than n)
> * If (n + a small offset) seconds have elapsed, we can assume we are within 
> an acceptable window of clock movement. Reasons for including an offset are 
> the clock checking thread might not have been scheduled on time, or garbage 
> collection, and so on.
> * If the clock is greater than (n + a small offset) seconds, we can assume 
> the clock jumped forward.
> In the unhappy cases, we can write a message to the log and increment some 
> metric that the user's monitoring systems can trigger/alert on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8094) Heavy writes in RangeSlice read requests

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-8094:
---
Status: Open  (was: Patch Available)

> Heavy writes in RangeSlice read  requests 
> --
>
> Key: CASSANDRA-8094
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8094
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Minh Do
>Assignee: Sam Tunnicliffe
>  Labels: lhf
> Fix For: 3.x
>
>
> RangeSlice requests always do a scheduled read repair when coordinators try 
> to resolve replicas' responses no matter read_repair_chance is set or not.
> Because of this, in low writes and high reads clusters, there are very high 
> write requests going on between nodes.  
> We should have an option to turn this off and this can be different than the 
> read_repair_chance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8094) Heavy writes in RangeSlice read requests

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-8094:


Coming back to look at this now, I think that using {{extensions}} to persist 
the param is just too hacky to be considered a reasonable approach. Given that, 
we should either defer this ticket until 4.0 or prioritize CASSANDRA-11382, 
using this as a driver towards an implementation. 

> Heavy writes in RangeSlice read  requests 
> --
>
> Key: CASSANDRA-8094
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8094
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Minh Do
>Assignee: Sam Tunnicliffe
>  Labels: lhf
> Fix For: 3.x
>
>
> RangeSlice requests always do a scheduled read repair when coordinators try 
> to resolve replicas' responses no matter read_repair_chance is set or not.
> Because of this, in low writes and high reads clusters, there are very high 
> write requests going on between nodes.  
> We should have an option to turn this off and this can be different than the 
> read_repair_chance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11546) Stress doesn't respect case-sensitive column names when building insert queries

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11546:

Reproduced In: 3.0.5, 2.2.5, 3.6  (was: 2.2.5, 3.0.5, 3.6)
 Reviewer: T Jake Luciani

> Stress doesn't respect case-sensitive column names when building insert 
> queries
> ---
>
> Key: CASSANDRA-11546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11546
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Joel Knighton
>Assignee: Giampaolo
>Priority: Trivial
>  Labels: lhf
> Attachments: cassandra-11546-trunk-giampaolo-trapasso.patch, 
> example.yaml
>
>
> When using a custom stress profile, if the schema uses case sensitive column 
> names, stress doesn't respect case sensitivity when building insert/update 
> statements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11541) correct the java documentation for SlabAllocator and NativeAllocator

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11541:

Reviewer: Branimir Lambov

> correct the java documentation for SlabAllocator and NativeAllocator
> 
>
> Key: CASSANDRA-11541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11541
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Trivial
>  Labels: document, lhf
> Fix For: 2.2.x
>
> Attachments: CASSANDRA-11541.patch
>
>
> I heard a lot that Cassandra uses 2MB slab allocation strategy for memtable 
> to improve its memory efficiency. But in fact, it has been changed from 2MB 
> to 1 MB. 
> And in NativeAllocator, it's logarithmically from 8kb to 1mb.
> large number of tables may not cause too much trouble in term of memtable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11540) The JVM should exit if jmx fails to bind

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11540:

Reviewer: Joshua McKenzie

> The JVM should exit if jmx fails to bind
> 
>
> Key: CASSANDRA-11540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11540
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Alex Petrov
>  Labels: lhf
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> If you are already running a cassandra instance, but for some reason try to 
> start another one, this happens:
> {noformat}
> INFO  20:57:09 JNA mlockall successful
> WARN  20:57:09 JMX is not enabled to receive remote connections. Please see 
> cassandra-env.sh for more info.
> ERROR 20:57:10 Error starting local jmx server:
> java.rmi.server.ExportException: Port already in use: 7199; nested exception 
> is:
> java.net.BindException: Address already in use
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) 
> ~[na:1.7.0_76]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:207) 
> ~[na:1.7.0_76]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:122) 
> ~[na:1.7.0_76]
> at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:98) 
> ~[na:1.7.0_76]
> at 
> java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239) 
> ~[na:1.7.0_76]
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:100)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:222) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:653) 
> [main/:na]
> Caused by: java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method) ~[na:1.7.0_76]
> at 
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:376) 
> ~[na:1.7.0_76]
> at java.net.ServerSocket.bind(ServerSocket.java:376) ~[na:1.7.0_76]
> at java.net.ServerSocket.(ServerSocket.java:237) ~[na:1.7.0_76]
> at 
> javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
>  ~[na:1.7.0_76]
> at 
> org.apache.cassandra.utils.RMIServerSocketFactoryImpl.createServerSocket(RMIServerSocketFactoryImpl.java:13)
>  ~[main/:na]
> at 
> sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) 
> ~[na:1.7.0_76]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) 
> ~[na:1.7.0_76]
> ... 11 common frames omitted
> {noformat}
> However the startup continues, and ends up replaying commitlogs, which is 
> probably not a good thing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11518) o.a.c.utils.UUIDGen clock generation is not very high in entropy

[Branimir Lambov (JIRA)]

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

Branimir Lambov commented on CASSANDRA-11518:
-

LGTM

> o.a.c.utils.UUIDGen clock generation is not very high in entropy
> 
>
> Key: CASSANDRA-11518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11518
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Trivial
> Fix For: 3.0.x, 3.x
>
>
> makeClockSeqAndNode uses {{java.util.Random}} to generate the clock. 
> {{Random}} only has 48-bits of internal state so it's not going to generate 
> the best bits for clock and in addition to that it uses a collision prone 
> seed that sort of defeats the purpose of clock sequence.
> A better approach to get the most out of those 14-bits would be to use 
> {{SecureRandom}} with something like SHA1PRNG.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-11705:
-

| *3.0* | *3.7* | *trunk* |
| [branch|https://github.com/bdeggleston/cassandra/tree/11705-3.0] | 
[branch|https://github.com/bdeggleston/cassandra/tree/11705-3.7] | 
[branch|https://github.com/bdeggleston/cassandra/tree/11705-trunk] |

> clearSnapshots using Directories.dataDirectories instead of 
> CFS.initialDirectories
> --
>
> Key: CASSANDRA-11705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.7
>
>
> An oversight in CASSANDRA-10518 prevents snapshots created in data 
> directories defined outside of cassandra.yaml from being cleared by 
> {{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should 
> be used when finding snapshots to clear, not {{Directories.dataDirectories}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11647) Don't use static dataDirectories field in Directories instances

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-11647:
-

The ones in {{AbstractCompactionStrategy}} and 
{{ColumnFamilyStore.createColumnFamilyStore}} aren't problems. The one in 
{{getKSChildDirectories}} _is_ a problem, and will prevent the clearing of any 
snapshots in directories defined outside of cassandra.yaml. However, that's an 
oversight of CASSANDRA-10518, and also affects 3.0.x. I've opened 
CASSANDRA-11705, which targets 3.0.x, and 3.7.

> Don't use static dataDirectories field in Directories instances
> ---
>
> Key: CASSANDRA-11647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11647
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 3.x
>
>
> Some of the changes to Directories by CASSANDRA-6696 use the static 
> {{dataDirectories}} field, instead of the instance field {{paths}}. This 
> complicates things for external code creating their own Directories instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Blake Eggleston (JIRA)]

Blake Eggleston created CASSANDRA-11705:
---

 Summary: clearSnapshots using Directories.dataDirectories instead 
of CFS.initialDirectories
 Key: CASSANDRA-11705
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
 Project: Cassandra
  Issue Type: Bug
Reporter: Blake Eggleston
Assignee: Blake Eggleston
Priority: Minor
 Fix For: 3.0.x, 3.7


An oversight in CASSANDRA-10518 prevents snapshots created in data directories 
defined outside of cassandra.yaml from being cleared by 
{{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should be 
used when finding snapshots to clear, not {{Directories.dataDirectories}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11576) Add support for JNA mlockall(2) on POWER

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11576:

Reviewer: Joshua McKenzie

> Add support for JNA mlockall(2) on POWER
> 
>
> Key: CASSANDRA-11576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11576
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
> Environment: POWER architecture
>Reporter: Rei Odaira
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 11576-2.1.txt
>
>
> org.apache.cassandra.utils.CLibrary contains hard-coded C-macro values to be 
> passed to system calls through JNA. These values are system-dependent, and as 
> far as I investigated, Linux and AIX on the IBM POWER architecture define 
> {{MCL_CURRENT}} and {{MCL_FUTURE}} (for mlockall(2)) as different values than 
> the current hard-coded values.  As a result, mlockall(2) fails on these 
> platforms.
> {code}
> WARN  18:51:51 Unknown mlockall error 22
> {code}
> I am going to provide a patch to support JNA mlockall(2) on POWER.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11519) Add support for IBM POWER

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11519:

Reviewer: Joshua McKenzie

> Add support for IBM POWER
> -
>
> Key: CASSANDRA-11519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11519
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
> Environment: POWER architecture
>Reporter: Rei Odaira
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 11519-2.1.txt, 11519-3.0.txt
>
>
> Add support for the IBM POWER architecture (ppc, ppc64, and ppc64le) in 
> org.apache.cassandra.utils.FastByteOperations, 
> org.apache.cassandra.utils.memory.MemoryUtil, and 
> org.apache.cassandra.io.util.Memory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11661) Cassandra 2.0 and later require Java 7u25 or later - jdk 101

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-11661:
---
Fix Version/s: (was: 2.2.x)
   (was: 2.1.x)
   3.0.7
   2.2.7
   2.1.15

> Cassandra 2.0 and later require Java 7u25 or later - jdk 101
> 
>
> Key: CASSANDRA-11661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11661
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Cassandra Server 2.1.5 and Java jdk1.7.0_101-b14
>Reporter: William Boutin
>Assignee: Eduard Tudenhoefner
>Priority: Critical
> Fix For: 2.1.15, 2.2.7, 3.7, 3.0.7
>
> Attachments: 11661-2.1.patch, 11661-2.2.patch, 11661-3.0.patch
>
>
> We have been running the cassandr server version 2.1.5. Friday, we applied 
> the latest java patch, Java(TM) SE Runtime Environment (build 1.7.0_101-b14). 
> Cassandra cannot start with this patch. The cassandra log states:  Cassandra 
> 2.0 and later require Java 7u25 or later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11661) Cassandra 2.0 and later require Java 7u25 or later - jdk 101

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-11661:
---
Fix Version/s: (was: 3.0.x)
   3.7

> Cassandra 2.0 and later require Java 7u25 or later - jdk 101
> 
>
> Key: CASSANDRA-11661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11661
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Cassandra Server 2.1.5 and Java jdk1.7.0_101-b14
>Reporter: William Boutin
>Assignee: Eduard Tudenhoefner
>Priority: Critical
> Fix For: 2.1.15, 2.2.7, 3.7, 3.0.7
>
> Attachments: 11661-2.1.patch, 11661-2.2.patch, 11661-3.0.patch
>
>
> We have been running the cassandr server version 2.1.5. Friday, we applied 
> the latest java patch, Java(TM) SE Runtime Environment (build 1.7.0_101-b14). 
> Cassandra cannot start with this patch. The cassandra log states:  Cassandra 
> 2.0 and later require Java 7u25 or later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11661) Cassandra 2.0 and later require Java 7u25 or later - jdk 101

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-11661:
---
Status: Ready to Commit  (was: Patch Available)

> Cassandra 2.0 and later require Java 7u25 or later - jdk 101
> 
>
> Key: CASSANDRA-11661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11661
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Cassandra Server 2.1.5 and Java jdk1.7.0_101-b14
>Reporter: William Boutin
>Assignee: Eduard Tudenhoefner
>Priority: Critical
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: 11661-2.1.patch, 11661-2.2.patch, 11661-3.0.patch
>
>
> We have been running the cassandr server version 2.1.5. Friday, we applied 
> the latest java patch, Java(TM) SE Runtime Environment (build 1.7.0_101-b14). 
> Cassandra cannot start with this patch. The cassandra log states:  Cassandra 
> 2.0 and later require Java 7u25 or later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11661) Cassandra 2.0 and later require Java 7u25 or later - jdk 101

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-11661:


+1 to patches - need a committer :)

> Cassandra 2.0 and later require Java 7u25 or later - jdk 101
> 
>
> Key: CASSANDRA-11661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11661
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Cassandra Server 2.1.5 and Java jdk1.7.0_101-b14
>Reporter: William Boutin
>Assignee: Michael Shuler
>Priority: Critical
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: 11661-2.1.patch, 11661-2.2.patch, 11661-3.0.patch
>
>
> We have been running the cassandr server version 2.1.5. Friday, we applied 
> the latest java patch, Java(TM) SE Runtime Environment (build 1.7.0_101-b14). 
> Cassandra cannot start with this patch. The cassandra log states:  Cassandra 
> 2.0 and later require Java 7u25 or later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11661) Cassandra 2.0 and later require Java 7u25 or later - jdk 101

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-11661:
---
Assignee: Eduard Tudenhoefner  (was: Michael Shuler)

> Cassandra 2.0 and later require Java 7u25 or later - jdk 101
> 
>
> Key: CASSANDRA-11661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11661
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Cassandra Server 2.1.5 and Java jdk1.7.0_101-b14
>Reporter: William Boutin
>Assignee: Eduard Tudenhoefner
>Priority: Critical
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: 11661-2.1.patch, 11661-2.2.patch, 11661-3.0.patch
>
>
> We have been running the cassandr server version 2.1.5. Friday, we applied 
> the latest java patch, Java(TM) SE Runtime Environment (build 1.7.0_101-b14). 
> Cassandra cannot start with this patch. The cassandra log states:  Cassandra 
> 2.0 and later require Java 7u25 or later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11661) Cassandra 2.0 and later require Java 7u25 or later - jdk 101

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-11661:
---
Reviewer: Michael Shuler

> Cassandra 2.0 and later require Java 7u25 or later - jdk 101
> 
>
> Key: CASSANDRA-11661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11661
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
> Environment: Cassandra Server 2.1.5 and Java jdk1.7.0_101-b14
>Reporter: William Boutin
>Assignee: Michael Shuler
>Priority: Critical
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: 11661-2.1.patch, 11661-2.2.patch, 11661-3.0.patch
>
>
> We have been running the cassandr server version 2.1.5. Friday, we applied 
> the latest java patch, Java(TM) SE Runtime Environment (build 1.7.0_101-b14). 
> Cassandra cannot start with this patch. The cassandra log states:  Cassandra 
> 2.0 and later require Java 7u25 or later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11503) Need a tool to detect what percentage of SSTables on a node have been repaired when using incremental repairs.

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11503:

Reviewer: Yuki Morishita

> Need a tool to detect what percentage of SSTables on a node have been 
> repaired when using incremental repairs.
> --
>
> Key: CASSANDRA-11503
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11503
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Sean Usher
>Assignee: Chris Lohfink
>Priority: Minor
> Attachments: CASSANDRA-11503.patch
>
>
> When using incremental repair, we should be able to look at SSTables and 
> understand how many sstables are in the repaired and unrepaired buckets on 
> each machine. This can help us track the repair progress and if we are 
> hitting any issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11518) o.a.c.utils.UUIDGen clock generation is not very high in entropy

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11518:

Reviewer: Branimir Lambov

> o.a.c.utils.UUIDGen clock generation is not very high in entropy
> 
>
> Key: CASSANDRA-11518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11518
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Trivial
> Fix For: 3.0.x, 3.x
>
>
> makeClockSeqAndNode uses {{java.util.Random}} to generate the clock. 
> {{Random}} only has 48-bits of internal state so it's not going to generate 
> the best bits for clock and in addition to that it uses a collision prone 
> seed that sort of defeats the purpose of clock sequence.
> A better approach to get the most out of those 14-bits would be to use 
> {{SecureRandom}} with something like SHA1PRNG.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11517) o.a.c.utils.UUIDGen could handle contention better

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11517:

Reviewer: Branimir Lambov

> o.a.c.utils.UUIDGen could handle contention better
> --
>
> Key: CASSANDRA-11517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11517
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.x
>
>
> I noticed this profiling a query handler implementation that uses UUIDGen to 
> get handles to track queries for logging purposes.
> Under contention threads are being unscheduled instead of spinning until the 
> lock is available. I would have expected intrinsic locks to be able to adapt 
> to this based on profiling information.
> Either way it's seems pretty straightforward to rewrite this to use a CAS 
> loop and test that it generally produces unique values.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11481) Example metrics config has DroppedMetrics

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11481:

Reviewer: Joshua McKenzie

> Example metrics config has DroppedMetrics
> -
>
> Key: CASSANDRA-11481
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11481
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation and Website
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
> Fix For: 3.x
>
> Attachments: fix-example-metrics.patch
>
>
> Noticed this when setting up metrics reporting on a new cluster. I assume it 
> is meant to be DroppedMessage



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)