[jira] [Updated] (CASSANDRA-12976) NullPointerException in SharedPool-Worker
[
https://issues.apache.org/jira/browse/CASSANDRA-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12976:
-
Environment: Ubuntu 14.04/16.04 (was: Cassandra 3.0.9)
> NullPointerException in SharedPool-Worker
> -
>
> Key: CASSANDRA-12976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12976
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04/16.04
>Reporter: Mike
>
> After an update from 3.0.8 to 3.0.9 we are getting the following exception on
> every node for the query:
> {noformat}
> SELECT * FROM keyspace.table WHERE partition = 0 AND expiration_time <
> 1480519469368;
> {noformat}
> on the following table:
> {noformat}
> CREATE TABLE keyspace.table (
> partition int,
> expiration_time timestamp,
> phone text,
> PRIMARY KEY (partition, expiration_time, phone)
> ) WITH CLUSTERING ORDER BY (expiration_time ASC, phone ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 360
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {noformat}
> {noformat}
> WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.RuntimeException: java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_111]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [apache-cassandra-3.0.9.jar:3.0.9]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.0.9.jar:3.0.9]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
> ~[apache-cassandra-3.0.9.jar:3.0.9]
> ... 5 common frames omitted
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12976) NullPointerException in SharedPool-Worker
[
https://issues.apache.org/jira/browse/CASSANDRA-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12976:
-
Description:
After an update from 3.0.8 to 3.0.9 we are getting the following exception on
every node for the query:
{noformat}
SELECT * FROM keyspace.table WHERE partition = 0 AND expiration_time <
1480519469368;
{noformat}
on the following table:
{noformat}
CREATE TABLE keyspace.table (
partition int,
expiration_time timestamp,
phone text,
PRIMARY KEY (partition, expiration_time, phone)
) WITH CLUSTERING ORDER BY (expiration_time ASC, phone ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 360
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
~[apache-cassandra-3.0.9.jar:3.0.9]
... 5 common frames omitted
{noformat}
was:
After an update from 3.0.8 to 3.0.9 we are getting the following exception on
every node for the query:
{noformat}
SELECT * FROM keyspace.table WHERE partition = 0 AND expiration_time <
1480519469368;
{noformat}
on the following table:
{noformat}
CREATE TABLE keyspace.table (
partition int,
expiration_time timestamp,
phone text,
PRIMARY KEY (partition, expiration_time, phone)
) WITH CLUSTERING ORDER BY (expiration_time ASC, phone ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 360
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND
[jira] [Updated] (CASSANDRA-12976) NullPointerException in SharedPool-Worker
[
https://issues.apache.org/jira/browse/CASSANDRA-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12976:
-
Description:
After an update from 3.0.8 to 3.0.9 we are getting the following exception on
every node for the query:
{noformat}
SELECT * FROM keyspace.table WHERE partition = 0 AND expiration_time <
1480519469368;
{noformat}
on the following table:
{noformat}
CREATE TABLE keyspace.table (
partition int,
expiration_time timestamp,
phone text,
PRIMARY KEY (partition, expiration_time, phone)
) WITH CLUSTERING ORDER BY (expiration_time ASC, phone ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 360
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
~[apache-cassandra-3.0.9.jar:3.0.9]
{noformat}
was:
After an update from 3.0.8 to 3.0.9 we are getting the following exception on
every node for the query:
{noformat}
SELECT * FROM keyspace.table WHERE partition = 0 AND expiration_time <
1480519469368;
on the following table:
CREATE TABLE keyspace.table (
partition int,
expiration_time timestamp,
phone text,
PRIMARY KEY (partition, expiration_time, phone)
) WITH CLUSTERING ORDER BY (expiration_time ASC, phone ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 360
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
[jira] [Updated] (CASSANDRA-12976) NullPointerException in SharedPool-Worker
[
https://issues.apache.org/jira/browse/CASSANDRA-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12976:
-
Description:
After an update from 3.0.8 to 3.0.9 we are getting the following exception on
every node for the query:
{noformat}
SELECT * FROM keyspace.table WHERE partition = 0 AND expiration_time <
1480519469368;
on the following table:
CREATE TABLE keyspace.table (
partition int,
expiration_time timestamp,
phone text,
PRIMARY KEY (partition, expiration_time, phone)
) WITH CLUSTERING ORDER BY (expiration_time ASC, phone ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 360
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
~[apache-cassandra-3.0.9.jar:3.0.9]
{noformat}
was:
After an update from 3.0.8 to 3.0.9 we are getting the following exception once
per minute on every node:
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
[jira] [Updated] (CASSANDRA-12976) NullPointerException in SharedPool-Worker
[
https://issues.apache.org/jira/browse/CASSANDRA-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12976:
-
Description:
After an update from 3.0.8 to 3.0.9 we are getting the following exception once
per minute on every node:
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
~[apache-cassandra-3.0.9.jar:3.0.9]
{noformat}
was:
After an update from 3.0.8 to 3.0.9 we are getting the following exception once
per minute on every node:
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
[jira] [Updated] (CASSANDRA-12976) NullPointerException in SharedPool-Worker
[
https://issues.apache.org/jira/browse/CASSANDRA-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12976:
-
Description:
After an update from 3.0.8 to 3.0.9 we are getting the following exception once
per minute on every node:
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
~[apache-cassandra-3.0.9.jar:3.0.9]
{noformat}
Full repair fails also with the following error:
{noformat}
[2016-11-30 15:07:02,565] Some repair failed
[2016-11-30 15:07:02,566] Repair command #7 finished in 1 second
error: Repair job has failed with the error message: [2016-11-30 15:07:02,565]
Some repair failed
-- StackTrace --
java.lang.RuntimeException: Repair job has failed with the error message:
[2016-11-30 15:07:02,565] Some repair failed
at
org.apache.cassandra.tools.RepairRunner.progress(RepairRunner.java:115)
at
org.apache.cassandra.utils.progress.jmx.JMXNotificationProgressListener.handleNotification(JMXNotificationProgressListener.java:77)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.dispatchNotification(ClientNotifForwarder.java:583)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.doRun(ClientNotifForwarder.java:533)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.run(ClientNotifForwarder.java:452)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor$1.run(ClientNotifForwarder.java:108)
{noformat}
was:
After an update from 3.0.8 to 3.0.9 we are getting the following exception once
per second on every node:
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
[jira] [Created] (CASSANDRA-12976) NullPointerException in SharedPool-Worker
Mike created CASSANDRA-12976:
Summary: NullPointerException in SharedPool-Worker
Key: CASSANDRA-12976
URL: https://issues.apache.org/jira/browse/CASSANDRA-12976
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 3.0.9
Reporter: Mike
After an update from 3.0.8 to 3.0.9 we are getting the following exception once
per second on every node:
{noformat}
WARN [SharedPool-Worker-1] 2016-11-30 14:48:00,852
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2470)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_111]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[apache-cassandra-3.0.9.jar:3.0.9]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.9.jar:3.0.9]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.lang.NullPointerException: null
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$ComponentOfSlice.isEQ(Slices.java:748)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.Slices$ArrayBackedSlices.toCQLString(Slices.java:659)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.filter.ClusteringIndexSliceFilter.toCQLString(ClusteringIndexSliceFilter.java:150)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.SinglePartitionReadCommand.appendCQLWhereClause(SinglePartitionReadCommand.java:911)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand.toCQLString(ReadCommand.java:560)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:506)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:76)
~[apache-cassandra-3.0.9.jar:3.0.9]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1797)
~[apache-cassandra-3.0.9.jar:3.0.9]
{noformat}
Full repair fails also with the following error:
{noformat}
[2016-11-30 15:07:02,565] Some repair failed
[2016-11-30 15:07:02,566] Repair command #7 finished in 1 second
error: Repair job has failed with the error message: [2016-11-30 15:07:02,565]
Some repair failed
-- StackTrace --
java.lang.RuntimeException: Repair job has failed with the error message:
[2016-11-30 15:07:02,565] Some repair failed
at
org.apache.cassandra.tools.RepairRunner.progress(RepairRunner.java:115)
at
org.apache.cassandra.utils.progress.jmx.JMXNotificationProgressListener.handleNotification(JMXNotificationProgressListener.java:77)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.dispatchNotification(ClientNotifForwarder.java:583)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.doRun(ClientNotifForwarder.java:533)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.run(ClientNotifForwarder.java:452)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor$1.run(ClientNotifForwarder.java:108)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12505) Authentication failure for new nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-12505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12505:
-
Description:
I added new data center with one node to a cluster. The cluster currently has 5
nodes in 3 data centers. I changed the replication factor of system_auth
keyspace according to the number of nodes. I run nodetool repair and rebuild on
new nodes, but I cannot login into the new nodes. cqlsh reports the following
error:
{noformat}
Connection error: ('Unable to connect to any servers', {'ip':
AuthenticationFailed(u'Failed to authenticate to ip: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{noformat}
I tried using both the SimpleStrategy and NetworkTopologyStrategy for the
system_auth keyspace without changes. I am still able to login into old nodes.
nodetool status reports that every node owns 100% of the system_auth keyspace.
The log file does not show any errors.
was:
I added new data center with one node to a cluster. The cluster currently has 5
nodes in 3 data centers. I changed the replication factor of system_auth
keyspace according to the number of nodes. I run nodetool repair and rebuild on
new nodes, but I cannot login to the new nodes. cqlsh reports the following
error:
{noformat}
Connection error: ('Unable to connect to any servers', {'ip':
AuthenticationFailed(u'Failed to authenticate to ip: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{noformat}
I tried using both the SimpleStrategy and NetworkTopologyStrategy for the
system_auth keyspace without changes. I am still able to login into old nodes.
nodetool status reports that every node owns 100% of the system_auth keyspace.
The log file does not show any errors.
> Authentication failure for new nodes
>
>
> Key: CASSANDRA-12505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12505
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 16.04
>Reporter: Mike
>Priority: Trivial
>
> I added new data center with one node to a cluster. The cluster currently has
> 5 nodes in 3 data centers. I changed the replication factor of system_auth
> keyspace according to the number of nodes. I run nodetool repair and rebuild
> on new nodes, but I cannot login into the new nodes. cqlsh reports the
> following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'ip':
> AuthenticationFailed(u'Failed to authenticate to ip: code=0100 [Bad
> credentials] message="Username and/or password are incorrect"',)})
> {noformat}
> I tried using both the SimpleStrategy and NetworkTopologyStrategy for the
> system_auth keyspace without changes. I am still able to login into old
> nodes. nodetool status reports that every node owns 100% of the system_auth
> keyspace. The log file does not show any errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12505) Authentication failure for new nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-12505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12505:
-
Priority: Trivial (was: Critical)
> Authentication failure for new nodes
>
>
> Key: CASSANDRA-12505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12505
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 16.04
>Reporter: Mike
>Priority: Trivial
>
> I added new data center with one node to a cluster. The cluster currently has
> 5 nodes in 3 data centers. I changed the replication factor of system_auth
> keyspace according to the number of nodes. I run nodetool repair and rebuild
> on new nodes, but I cannot login to the new nodes. cqlsh reports the
> following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'ip':
> AuthenticationFailed(u'Failed to authenticate to ip: code=0100 [Bad
> credentials] message="Username and/or password are incorrect"',)})
> {noformat}
> I tried using both the SimpleStrategy and NetworkTopologyStrategy for the
> system_auth keyspace without changes. I am still able to login into old
> nodes. nodetool status reports that every node owns 100% of the system_auth
> keyspace. The log file does not show any errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12505) Authentication failure for new nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-12505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15428377#comment-15428377
]
Mike commented on CASSANDRA-12505:
--
I haven't found it in any Cassandra documentation regarding adding new node/DC,
but after I run nodetool repair -full, I was able to login into new node.
> Authentication failure for new nodes
>
>
> Key: CASSANDRA-12505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12505
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 16.04
>Reporter: Mike
>Priority: Critical
>
> I added new data center with one node to a cluster. The cluster currently has
> 5 nodes in 3 data centers. I changed the replication factor of system_auth
> keyspace according to the number of nodes. I run nodetool repair and rebuild
> on new nodes, but I cannot login to the new nodes. cqlsh reports the
> following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'ip':
> AuthenticationFailed(u'Failed to authenticate to ip: code=0100 [Bad
> credentials] message="Username and/or password are incorrect"',)})
> {noformat}
> I tried using both the SimpleStrategy and NetworkTopologyStrategy for the
> system_auth keyspace without changes. I am still able to login into old
> nodes. nodetool status reports that every node owns 100% of the system_auth
> keyspace. The log file does not show any errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12505) Authentication failure for new nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-12505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike resolved CASSANDRA-12505.
--
Resolution: Fixed
> Authentication failure for new nodes
>
>
> Key: CASSANDRA-12505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12505
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 16.04
>Reporter: Mike
>Priority: Critical
>
> I added new data center with one node to a cluster. The cluster currently has
> 5 nodes in 3 data centers. I changed the replication factor of system_auth
> keyspace according to the number of nodes. I run nodetool repair and rebuild
> on new nodes, but I cannot login to the new nodes. cqlsh reports the
> following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'ip':
> AuthenticationFailed(u'Failed to authenticate to ip: code=0100 [Bad
> credentials] message="Username and/or password are incorrect"',)})
> {noformat}
> I tried using both the SimpleStrategy and NetworkTopologyStrategy for the
> system_auth keyspace without changes. I am still able to login into old
> nodes. nodetool status reports that every node owns 100% of the system_auth
> keyspace. The log file does not show any errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12505) Authentication failure for new nodes
Mike created CASSANDRA-12505:
Summary: Authentication failure for new nodes
Key: CASSANDRA-12505
URL: https://issues.apache.org/jira/browse/CASSANDRA-12505
Project: Cassandra
Issue Type: Bug
Environment: Ubuntu 16.04
Reporter: Mike
Priority: Critical
I added new data center with one node to a cluster. The cluster currently has 5
nodes in 3 data centers. I changed the replication factor of system_auth
keyspace according to the number of nodes. I run nodetool repair and rebuild on
new nodes, but I cannot login to the new nodes. cqlsh reports the following
error:
{noformat}
Connection error: ('Unable to connect to any servers', {'ip':
AuthenticationFailed(u'Failed to authenticate to ip: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{noformat}
I tried using both the SimpleStrategy and NetworkTopologyStrategy for the
system_auth keyspace without changes. I am still able to login into old nodes.
nodetool status reports that every node owns 100% of the system_auth keyspace.
The log file does not show any errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12185) Exception during metrics calculation
[
https://issues.apache.org/jira/browse/CASSANDRA-12185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12185:
-
Description:
I am trying to report Cassandra metrics to Graphite server using
metrics-graphite. When there is no load on the cluster everything works fine
and all metrics are reported properly. But if some load occurs, I receive
following exception in system.log:
{noformat}
ERROR [metrics-graphite-reporter-1-thread-1] 2016-07-13 08:21:23,580
ScheduledReporter.java:119 - RuntimeException thrown from
GraphiteReporter#report. Exception was suppressed.
java.lang.IllegalStateException: Unable to compute ceiling for max when
histogram overflowed
at
org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
~[apache-cassandra-3.0.7.jar:3.0.7]
at
org.apache.cassandra.metrics.EstimatedHistogramReservoir$HistogramSnapshot.getMean(EstimatedHistogramReservoir.java:103)
~[apache-cassandra-3.0.7.jar:3.0.7]
at
com.codahale.metrics.graphite.GraphiteReporter.reportHistogram(GraphiteReporter.java:265)
~[metrics-graphite-3.1.2.jar:3.1.2]
at
com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:179)
~[metrics-graphite-3.1.2.jar:3.1.2]
at
com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
~[metrics-core-3.1.0.jar:3.1.0]
at
com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
~[metrics-core-3.1.0.jar:3.1.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_91]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[na:1.8.0_91]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_91]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
{noformat}
This message is repeated every second on every Cassandra node and some metrics
become unavailable. In order to receive the metrics again, I have to restart
all Cassandra nodes. I tried different metrics-graphite versions from 3.1.0 to
3.1.2 with the same issue.
was:
I am trying to report Cassandra metrics to Graphite server using
metrics-graphite. When there is no load on the cluster everything works fine
and all metrics are reported properly. But if some load occurs, I receive
following exception in system.log:
{noformat}
ERROR [metrics-graphite-reporter-1-thread-1] 2016-07-13 08:21:23,580
ScheduledReporter.java:119 - RuntimeException thrown from
GraphiteReporter#report. Exception was suppressed.
java.lang.IllegalStateException: Unable to compute ceiling for max when
histogram overflowed
at
org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
~[apache-cassandra-3.0.7.jar:3.0.7]
at
org.apache.cassandra.metrics.EstimatedHistogramReservoir$HistogramSnapshot.getMean(EstimatedHistogramReservoir.java:103)
~[apache-cassandra-3.0.7.jar:3.0.7]
at
com.codahale.metrics.graphite.GraphiteReporter.reportHistogram(GraphiteReporter.java:265)
~[metrics-graphite-3.1.2.jar:3.1.2]
at
com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:179)
~[metrics-graphite-3.1.2.jar:3.1.2]
at
com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
~[metrics-core-3.1.0.jar:3.1.0]
at
com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
~[metrics-core-3.1.0.jar:3.1.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_91]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[na:1.8.0_91]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_91]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
{noformat}
This message is repeated every second on every Cassandra node and some metrics
become unavailable. In order to receive the metrics again, I have to restart
all Cassandra nodes.
> Exception during metrics calculation
>
>
> Key:
[jira] [Created] (CASSANDRA-12185) Exception during metrics calculation
Mike created CASSANDRA-12185:
Summary: Exception during metrics calculation
Key: CASSANDRA-12185
URL: https://issues.apache.org/jira/browse/CASSANDRA-12185
Project: Cassandra
Issue Type: Bug
Components: Observability
Environment: Ubuntu 14.04, Java 1.8.0_91, metrics-graphite-3.1.2
Reporter: Mike
I am trying to report Cassandra metrics to Graphite server using
metrics-graphite. When there is no load on the cluster everything works fine
and all metrics are reported properly. But if some load occurs, I receive
following exception in system.log:
{noformat}
ERROR [metrics-graphite-reporter-1-thread-1] 2016-07-13 08:21:23,580
ScheduledReporter.java:119 - RuntimeException thrown from
GraphiteReporter#report. Exception was suppressed.
java.lang.IllegalStateException: Unable to compute ceiling for max when
histogram overflowed
at
org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
~[apache-cassandra-3.0.7.jar:3.0.7]
at
org.apache.cassandra.metrics.EstimatedHistogramReservoir$HistogramSnapshot.getMean(EstimatedHistogramReservoir.java:103)
~[apache-cassandra-3.0.7.jar:3.0.7]
at
com.codahale.metrics.graphite.GraphiteReporter.reportHistogram(GraphiteReporter.java:265)
~[metrics-graphite-3.1.2.jar:3.1.2]
at
com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:179)
~[metrics-graphite-3.1.2.jar:3.1.2]
at
com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
~[metrics-core-3.1.0.jar:3.1.0]
at
com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
~[metrics-core-3.1.0.jar:3.1.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_91]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[na:1.8.0_91]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_91]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
{noformat}
This message is repeated every second on every Cassandra node and some metrics
become unavailable. In order to receive the metrics again, I have to restart
all Cassandra nodes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12133:
-
Environment: Ubuntu 14.04, Java 1.8.0_91 (was: Ubuntu 14.04)
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
> Fix For: 3.0.7
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike updated CASSANDRA-12133:
-
Description:
After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
receive this warning in system.log during startup:
{noformat}
WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
implementation ohc-core-j8 : java.lang.NoSuchMethodException:
org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
{noformat}
was:
After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
receive this warning in system.log during startup:
WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
implementation ohc-core-j8 : java.lang.NoSuchMethodException:
org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04
>Reporter: Mike
> Fix For: 3.0.7
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
Mike created CASSANDRA-12133: Summary: Failed to load Java8 implementation ohc-core-j8 Key: CASSANDRA-12133 URL: https://issues.apache.org/jira/browse/CASSANDRA-12133 Project: Cassandra Issue Type: Bug Components: Core Environment: Ubuntu 14.04 Reporter: Mike Fix For: 3.0.7 After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I receive this warning in system.log during startup: WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8 implementation ohc-core-j8 : java.lang.NoSuchMethodException: org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8359) Make DTCS consider removing SSTables much more frequently
[ https://issues.apache.org/jira/browse/CASSANDRA-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14729710#comment-14729710 ] mike commented on CASSANDRA-8359: - is there any way I can get a patch for 2.0.14? Thanks! > Make DTCS consider removing SSTables much more frequently > - > > Key: CASSANDRA-8359 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8359 > Project: Cassandra > Issue Type: Improvement >Reporter: Björn Hegerfors >Assignee: Björn Hegerfors >Priority: Minor > Labels: dtcs > Fix For: 2.2.0 beta 1, 2.0.15, 2.1.5 > > Attachments: cassandra-2.0-CASSANDRA-8359.txt > > > When I run DTCS on a table where every value has a TTL (always the same TTL), > SSTables are completely expired, but still stay on disk for much longer than > they need to. I've applied CASSANDRA-8243, but it doesn't make an apparent > difference (probably because the subject SSTables are purged via compaction > anyway, if not by directly dropping them). > Disk size graphs show clearly that tombstones are only removed when the > oldest SSTable participates in compaction. In the long run, size on disk > continually grows bigger. This should not have to happen. It should easily be > able to stay constant, thanks to DTCS separating the expired data from the > rest. > I think checks for whether SSTables can be dropped should happen much more > frequently. This is something that probably only needs to be tweaked for > DTCS, but perhaps there's a more general place to put this. Anyway, my > thinking is that DTCS should, on every call to getNextBackgroundTask, check > which SSTables can be dropped. It would be something like a call to > CompactionController.getFullyExpiredSSTables with all non-compactingSSTables > sent in as "compacting" and all other SSTables sent in as "overlapping". The > returned SSTables, if any, are then added to whichever set of SSTables that > DTCS decides to compact. Then before the compaction happens, Cassandra is > going to make another call to CompactionController.getFullyExpiredSSTables, > where it will see that it can just drop them. > This approach has a bit of redundancy in that it needs to call > CompactionController.getFullyExpiredSSTables twice. To avoid that, the code > path for deciding SSTables to drop would have to be changed. > (Side tracking a little here: I'm also thinking that tombstone compactions > could be considered more often in DTCS. Maybe even some kind of multi-SSTable > tombstone compaction involving the oldest couple of SSTables...) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9252) for DateTieredCompactionStrategy, TIMESTAMP_RESOLUTION_KEY sets wrong msxSSTableAge value if RESOLUTION is other than MILLISECONDS
mike created CASSANDRA-9252:
---
Summary: for DateTieredCompactionStrategy,
TIMESTAMP_RESOLUTION_KEY sets wrong msxSSTableAge value if RESOLUTION is other
than MILLISECONDS
Key: CASSANDRA-9252
URL: https://issues.apache.org/jira/browse/CASSANDRA-9252
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux/CentOS
Reporter: mike
Fix For: 2.0.14
Attachments: DateTieredCompactionStrategy.java,
DateTieredCompactionStrategyOptions.java
I was trying to set 'timestamp_resolution' to MINUTES/HOURS/DAYS. it turned out
maxSSTableAge was set as wrong value. In the code,
public DateTieredCompactionStrategyOptions(MapString, String options)
{
String optionValue = options.get(TIMESTAMP_RESOLUTION_KEY);
TimeUnit timestampResolution = optionValue == null ?
DEFAULT_TIMESTAMP_RESOLUTION : TimeUnit.valueOf(optionValue);
optionValue = options.get(MAX_SSTABLE_AGE_KEY);
double fractionalDays = optionValue == null ?
DEFAULT_MAX_SSTABLE_AGE_DAYS : Double.parseDouble(optionValue);
maxSSTableAge = Math.round(fractionalDays *
timestampResolution.convert(1, TimeUnit.DAYS));
... }
maxSSTableAge will be set as the value in timestamp_resolution unit, such as
, with the following settings,
'timestamp_resolution':'HOURS',
'max_sstable_age_days':'7',
'base_time_seconds':'3600'
and I get:
maxSSTableAge=168, baseTime=1
while in the following routine, it expect maxSSTableAge as milliseconds
static IterableSSTableReader filterOldSSTables(ListSSTableReader
sstables, long maxSSTableAge, long now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8736) core dump on creating keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14305540#comment-14305540
]
mike commented on CASSANDRA-8736:
-
yes, that is what we have. We will try to upgrade python to see if it will
resolve the issue.
Thanks
core dump on creating keyspaces
Key: CASSANDRA-8736
URL: https://issues.apache.org/jira/browse/CASSANDRA-8736
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux
Reporter: mike
Priority: Minor
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
{noformat}
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f
${dbDefaultDataDir}/${DATA_SCRIPT}”.
*** glibc detected *** python: corrupted double-linked list:
0x02dc95f0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0
[heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
7fd1be1e9000-7fd1be1ed000 r-xp 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be1ed000-7fd1be3ed000 ---p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ed000-7fd1be3ef000 rw-p 4000
[jira] [Commented] (CASSANDRA-8736) core dump on creating keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14305556#comment-14305556
]
mike commented on CASSANDRA-8736:
-
here are some detail of our env:
CentOS release 6.3 (Final)
Linux version 2.6.32-431.3.1.el6.x86_64 (mockbu...@c6b10.bsys.dev.centos.org)
(gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Jan 3 21:39:27
UTC 2014
Python 2.6.6
java version 1.7.0_67
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
Thanks
core dump on creating keyspaces
Key: CASSANDRA-8736
URL: https://issues.apache.org/jira/browse/CASSANDRA-8736
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux
Reporter: mike
Priority: Minor
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
{noformat}
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f
${dbDefaultDataDir}/${DATA_SCRIPT}”.
*** glibc detected *** python: corrupted double-linked list:
0x02dc95f0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0
[heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
[jira] [Created] (CASSANDRA-8736) core dump on creating keyspaces
mike created CASSANDRA-8736:
---
Summary: core dump on creating keyspaces
Key: CASSANDRA-8736
URL: https://issues.apache.org/jira/browse/CASSANDRA-8736
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux
Reporter: mike
Priority: Critical
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f
${dbDefaultDataDir}/${VCE_DATA_SCRIPT}” that was seen yesterday I also am
seeing below on my environment when deploying.
*** glibc detected *** python: corrupted double-linked list: 0x02dc95f0
***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0 [heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
7fd1be1e9000-7fd1be1ed000 r-xp 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be1ed000-7fd1be3ed000 ---p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ed000-7fd1be3ef000 rw-p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ef000-7fd1be3f2000 r-xp 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be3f2000-7fd1be5f1000 ---p 3000 08:06 180869
[jira] [Updated] (CASSANDRA-8736) core dump on creating keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike updated CASSANDRA-8736:
Description:
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f
${dbDefaultDataDir}/${VCE_DATA_SCRIPT}” that was seen yesterday I also am
seeing below on my environment when deploying.
*** glibc detected *** python: corrupted double-linked list: 0x02dc95f0
***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0 [heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
7fd1be1e9000-7fd1be1ed000 r-xp 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be1ed000-7fd1be3ed000 ---p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ed000-7fd1be3ef000 rw-p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ef000-7fd1be3f2000 r-xp 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be3f2000-7fd1be5f1000 ---p 3000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f1000-7fd1be5f2000 rw-p 2000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f2000-7fd1be5f5000 r-xp 08:06 180866
[jira] [Updated] (CASSANDRA-8736) core dump on creating keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike updated CASSANDRA-8736:
Description:
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f ${dbDefaultDataDir}/${DATA_SCRIPT}”
that was seen yesterday I also am seeing below on my environment when deploying.
*** glibc detected *** python: corrupted double-linked list: 0x02dc95f0
***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0 [heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
7fd1be1e9000-7fd1be1ed000 r-xp 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be1ed000-7fd1be3ed000 ---p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ed000-7fd1be3ef000 rw-p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ef000-7fd1be3f2000 r-xp 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be3f2000-7fd1be5f1000 ---p 3000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f1000-7fd1be5f2000 rw-p 2000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f2000-7fd1be5f5000 r-xp 08:06 180866
[jira] [Updated] (CASSANDRA-8736) core dump on creating keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike updated CASSANDRA-8736:
Description:
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f ${dbDefaultDataDir}/${DATA_SCRIPT}”.
*** glibc detected *** python: corrupted double-linked list: 0x02dc95f0
***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0 [heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
7fd1be1e9000-7fd1be1ed000 r-xp 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be1ed000-7fd1be3ed000 ---p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ed000-7fd1be3ef000 rw-p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ef000-7fd1be3f2000 r-xp 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be3f2000-7fd1be5f1000 ---p 3000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f1000-7fd1be5f2000 rw-p 2000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f2000-7fd1be5f5000 r-xp 08:06 180866
/usr/lib64/python2.6/lib-dynload/_hashlib.so
7fd1be5f5000-7fd1be7f4000
[jira] [Updated] (CASSANDRA-8736) core dump on creating keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike updated CASSANDRA-8736:
Description:
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f ${dbDefaultDataDir}/${DATA_SCRIPT}”.
*** glibc detected *** python: corrupted double-linked list: 0x02dc95f0
***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0 [heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
7fd1be1e9000-7fd1be1ed000 r-xp 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be1ed000-7fd1be3ed000 ---p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ed000-7fd1be3ef000 rw-p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ef000-7fd1be3f2000 r-xp 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be3f2000-7fd1be5f1000 ---p 3000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f1000-7fd1be5f2000 rw-p 2000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f2000-7fd1be5f5000 r-xp 08:06 180866
/usr/lib64/python2.6/lib-dynload/_hashlib.so
7fd1be5f5000-7fd1be7f4000
[jira] [Updated] (CASSANDRA-8736) core dump on creating keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike updated CASSANDRA-8736:
Description:
After we upgraded C* to 2.1.2, with new installation, sometimes on creating
Keyspaces, it failed. Is there a patch available or will it be fixed in 2.1.3
release. Thanks.
$CASSANDRA_DIR/bin/cqlsh ${cassandraIp} -f ${dbDefaultDataDir}/${DATA_SCRIPT}”.
*** glibc detected *** python: corrupted double-linked list: 0x02dc95f0
***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x7fd1c43b8166]
/lib64/libc.so.6(+0x78ef4)[0x7fd1c43baef4]
/usr/lib64/libpython2.6.so.1.0(+0x7f6f7)[0x7fd1c4ffd6f7]
/usr/lib64/libpython2.6.so.1.0(+0xa1bb0)[0x7fd1c501fbb0]
/usr/lib64/libpython2.6.so.1.0(+0x555bb)[0x7fd1c4fd35bb]
/usr/lib64/libpython2.6.so.1.0(+0x6d132)[0x7fd1c4feb132]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x597)[0x7fd1c505e407]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x7fd1c505cbe4]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6eead)[0x7fd1c4fecead]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x7fd1c505b5b0]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x7fd1c505dccf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x7fd1c505e797]
/usr/lib64/libpython2.6.so.1.0(+0x6edb0)[0x7fd1c4fecdb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(+0x5970f)[0x7fd1c4fd770f]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7fd1c4fc2303]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7fd1c5056dd3]
/usr/lib64/libpython2.6.so.1.0(+0x10bf2a)[0x7fd1c5089f2a]
/lib64/libpthread.so.0(+0x79d1)[0x7fd1c4d689d1]
/lib64/libc.so.6(clone+0x6d)[0x7fd1c442ab6d]
=== Memory map:
0040-00401000 r-xp 08:06 450964
/usr/bin/python
0060-00601000 rw-p 08:06 450964
/usr/bin/python
024ba000-02f29000 rw-p 00:00 0 [heap]
7fd1b000-7fd1b0172000 rw-p 00:00 0
7fd1b0172000-7fd1b400 ---p 00:00 0
7fd1b400-7fd1b4021000 rw-p 00:00 0
7fd1b4021000-7fd1b800 ---p 00:00 0
7fd1b800-7fd1b8021000 rw-p 00:00 0
7fd1b8021000-7fd1bc00 ---p 00:00 0
7fd1bc1d-7fd1bc1e6000 r-xp 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc1e6000-7fd1bc3e5000 ---p 00016000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e5000-7fd1bc3e6000 rw-p 00015000 08:0a 917506
/lib64/libgcc_s-4.4.6-20120305.so.1
7fd1bc3e6000-7fd1bc3e7000 ---p 00:00 0
7fd1bc3e7000-7fd1bcde7000 rw-p 00:00 0
7fd1bcde7000-7fd1bcde8000 ---p 00:00 0
7fd1bcde8000-7fd1bd7e8000 rw-p 00:00 0
7fd1bd7e8000-7fd1bd7e9000 ---p 00:00 0
7fd1bd7e9000-7fd1be1e9000 rw-p 00:00 0
7fd1be1e9000-7fd1be1ed000 r-xp 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be1ed000-7fd1be3ed000 ---p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ed000-7fd1be3ef000 rw-p 4000 08:06 180906
/usr/lib64/python2.6/lib-dynload/selectmodule.so
7fd1be3ef000-7fd1be3f2000 r-xp 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be3f2000-7fd1be5f1000 ---p 3000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f1000-7fd1be5f2000 rw-p 2000 08:06 180869
/usr/lib64/python2.6/lib-dynload/_json.so
7fd1be5f2000-7fd1be5f5000 r-xp 08:06 180866
/usr/lib64/python2.6/lib-dynload/_hashlib.so
7fd1be5f5000-7fd1be7f4000
[jira] [Commented] (CASSANDRA-5391) SSL problems with inter-DC communication
[
https://issues.apache.org/jira/browse/CASSANDRA-5391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697313#comment-13697313
]
Mike commented on CASSANDRA-5391:
-
I don't think I see any code changes in the 1.1.x branch as a result of this
bug. Does the bug not apply to 1.1.x (aka, it was introduced in the 1.2.0
streaming refactor?), or does 1.1.12 (and 1.1.9, on which Datastax Enterprise
is based) still suffer from this?
SSL problems with inter-DC communication
Key: CASSANDRA-5391
URL: https://issues.apache.org/jira/browse/CASSANDRA-5391
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Environment: $ /etc/alternatives/jre_1.6.0/bin/java -version
java version 1.6.0_23
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)
$ uname -a
Linux hostname 2.6.32-358.2.1.el6.x86_64 #1 SMP Tue Mar 12 14:18:09 CDT 2013
x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
Scientific Linux release 6.3 (Carbon)
$ facter | grep ec2
...
ec2_placement = availability_zone=us-east-1d
...
$ rpm -qi cassandra
cassandra-1.2.3-1.el6.cmp1.noarch
(custom built rpm from cassandra tarball distribution)
Reporter: Ondřej Černoš
Assignee: Yuki Morishita
Priority: Blocker
Fix For: 1.2.4
Attachments: 5391-1.2.3.txt, 5391-1.2.txt, 5391-v2-1.2.txt
I get SSL and snappy compression errors in multiple datacenter setup.
The setup is simple: 3 nodes in AWS east, 3 nodes in Rackspace. I use
slightly modified Ec2MultiRegionSnitch in Rackspace (I just added a regex
able to parse the Rackspace/Openstack availability zone which happens to be
in unusual format).
During {{nodetool rebuild}} tests I managed to (consistently) trigger the
following error:
{noformat}
2013-03-19 12:42:16.059+0100 [Thread-13] [DEBUG]
IncomingTcpConnection.java(79)
org.apache.cassandra.net.IncomingTcpConnection: IOException reading from
socket; closing
java.io.IOException: FAILED_TO_UNCOMPRESS(5)
at org.xerial.snappy.SnappyNative.throw_error(SnappyNative.java:78)
at org.xerial.snappy.SnappyNative.rawUncompress(Native Method)
at org.xerial.snappy.Snappy.rawUncompress(Snappy.java:391)
at
org.apache.cassandra.io.compress.SnappyCompressor.uncompress(SnappyCompressor.java:93)
at
org.apache.cassandra.streaming.compress.CompressedInputStream.decompress(CompressedInputStream.java:101)
at
org.apache.cassandra.streaming.compress.CompressedInputStream.read(CompressedInputStream.java:79)
at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:337)
at
org.apache.cassandra.utils.BytesReadTracker.readUnsignedShort(BytesReadTracker.java:140)
at
org.apache.cassandra.utils.ByteBufferUtil.readShortLength(ByteBufferUtil.java:361)
at
org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:371)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:160)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:226)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:166)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:66)
{noformat}
The exception is raised during DB file download. What is strange is the
following:
* the exception is raised only when rebuildig from AWS into Rackspace
* the exception is raised only when all nodes are up and running in AWS (all
3). In other words, if I bootstrap from one or two nodes in AWS, the command
succeeds.
Packet-level inspection revealed malformed packets _on both ends of
communication_ (the packet is considered malformed on the machine it
originates on).
Further investigation raised two more concerns:
* We managed to get another stacktrace when testing the scenario. The
exception was raised only once during the tests and was raised when I
throttled the inter-datacenter bandwidth to 1Mbps.
{noformat}
java.lang.RuntimeException: javax.net.ssl.SSLException: bad record MAC
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.net.ssl.SSLException: bad record MAC
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
at
