[jira] [Updated] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-10412:

Fix Version/s: (was: 2.2.x)
   2.2.3
   3.0.0 rc2

> Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
> -
>
> Key: CASSANDRA-10412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10412
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: OS: Windows 2012 R2
> Java JRE: 1.8.0_51
>Reporter: Eric Simmons
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 3.0.0 rc2, 2.2.3
>
> Attachments: cassandra-env.ps1, cassandra.yaml
>
>
> We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however 
> we can use the same environment to start version 2.1.2
> I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference.  
> I have also attached the system.log file displaying the error.
> I have also included an excerpt of the log file showing the stack trace of 
> the error.
> ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482 
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.cassandra.config.DatabaseDescriptor
>   at 
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57)
>  ~[apache-cassandra-2.2.1.jar:2.2.1]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122)
>  ~[apache-cassandra-2.2.1.jar:2.2.1]
>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.runAndReset(Unknown Source) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
>  Source) ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
>  Source) ~[na:1.8.0_51]
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
> [na:1.8.0_51]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> [na:1.8.0_51]
>   at java.lang.Thread.run(Unknown Source) [na:1.8.0_51]



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

[jira] [Created] (CASSANDRA-10467) QoS for Queries

[Benjamin Coverston (JIRA)]

Benjamin Coverston created CASSANDRA-10467:
--

 Summary: QoS for Queries
 Key: CASSANDRA-10467
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10467
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benjamin Coverston


Background: As an OLTP system that is based on pipelined execution worker pools 
can be saturated with long(er) running calls. When the system is under stress, 
those long running calls can make requests that should be short lived requests 
take a much longer period of time.

Introduce the concept of QoS into Cassandra for client queries. A few ideas:

1. Allow clients to specify a QoS to be sent to Cassandra from the driver as 
part of the protocol.

2. Allow different requests to be tagged based on some simple criteria (perhaps 
configured) (i.e. ALLOW FILTERING was part of the query)

3. QOS based on the LUN that is accessed (SSDs get higher QOS than the RAID5)





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

[jira] [Assigned] (CASSANDRA-10459) Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest

[Paulo Motta (JIRA)]

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

Paulo Motta reassigned CASSANDRA-10459:
---

Assignee: Paulo Motta

> Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest
> --
>
> Key: CASSANDRA-10459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10459
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This test on large columns is failing:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/largecolumn_test/TestLargeColumn/cleanup_test/
> and it's been failing for a while:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/junit/largecolumn_test/TestLargeColumn/cleanup_test/history/
> I've reproduced the failure on OpenStack, so it's not just a CassCI problem.



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

[jira] [Created] (CASSANDRA-10470) Fix likely dtest bugs in upgrade_tests

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10470:


 Summary: Fix likely dtest bugs in upgrade_tests
 Key: CASSANDRA-10470
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10470
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
 Fix For: 3.0.0 rc2


These two upgrade tests fail on CassCI:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingDatasetChanges/test_cell_TTL_expiry_during_paging/
http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.cql_tests/TestCQL/counters_test/

I believe the tests expect values to be formatted slightly differently, e.g. 
for values to have type {{unicode}} instead of {{str}}. If I'm wrong and this 
requires more than a few dtest fixes, this should be split out into multiple 
tickets.

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs. 
Until then, you can run it with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.collection_indexing_test
{code}




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

[jira] [Created] (CASSANDRA-10473) fix failing dtest for select distinct with static columns on 2.2->3.0 upgrade path

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10473:


 Summary: fix failing dtest for select distinct with static columns 
on 2.2->3.0 upgrade path
 Key: CASSANDRA-10473
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10473
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey


{{upgrade_tests/cql_tests.py:TestCQL.static_columns_with_distinct_test}} fails 
on the upgrade path from 2.2 to 3.0:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/lastCompletedBuild/testReport/upgrade_tests.cql_tests/TestCQL/static_columns_with_distinct_test/

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs. 
Until then, you can run it with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests upgrade_tests/cql_tests.py:TestCQL.static_columns_with_distinct_test
{code}




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

[jira] [Commented] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10412:
-

+1, marking as ready to commit. thanks!

> Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
> -
>
> Key: CASSANDRA-10412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10412
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: OS: Windows 2012 R2
> Java JRE: 1.8.0_51
>Reporter: Eric Simmons
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: cassandra-env.ps1, cassandra.yaml
>
>
> We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however 
> we can use the same environment to start version 2.1.2
> I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference.  
> I have also attached the system.log file displaying the error.
> I have also included an excerpt of the log file showing the stack trace of 
> the error.
> ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482 
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.cassandra.config.DatabaseDescriptor
>   at 
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57)
>  ~[apache-cassandra-2.2.1.jar:2.2.1]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122)
>  ~[apache-cassandra-2.2.1.jar:2.2.1]
>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.runAndReset(Unknown Source) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
>  Source) ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
>  Source) ~[na:1.8.0_51]
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
> [na:1.8.0_51]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> [na:1.8.0_51]
>   at java.lang.Thread.run(Unknown Source) [na:1.8.0_51]



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

[jira] [Created] (CASSANDRA-10468) Fix class-casting error in mixed clusters

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10468:


 Summary: Fix class-casting error in mixed clusters
 Key: CASSANDRA-10468
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10468
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
 Fix For: 3.0.0 rc2


Three upgrade tests:

- {{upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test}}
- {{upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test}}
- {{upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test}}

fail on the upgrade path from 2.2 to 3.0. The failures can be found on CassCI 
here:

[cas_and_list_index_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/cas_and_list_index_test/]
[collection_and_regular_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/collection_and_regular_test/]
[composite_index_collections_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/composite_index_collections_test/]

You can run these tests with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test 
upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test 
upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test
{code}

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs.



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

[jira] [Commented] (CASSANDRA-10443) CQLSStableWriter example fails on 3.0rc1

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-10443:


Patch and tests LGTM. +1.
cassandra-bulkloader-example also runs without error with the patch.

> CQLSStableWriter example fails on 3.0rc1
> 
>
> Key: CASSANDRA-10443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10443
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, Tools
>Reporter: Jonathan Shook
>Assignee: Carl Yeksigian
> Fix For: 3.0.0 rc2
>
>
> CQLSSTableWriter which works with 2.2.1 does not work with 3.0rc1.
> Something like https://github.com/yukim/cassandra-bulkload-example should be 
> added to the test suite.
> Exception in thread "main" java.lang.RuntimeException: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter.close(SSTableSimpleUnsortedWriter.java:136)
>   at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.close(CQLSSTableWriter.java:274)
>   at com.metawiring.sandbox.BulkLoadExample.main(BulkLoadExample.java:160)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: java.lang.ExceptionInInitializerError
>   at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:372)
>   at org.apache.cassandra.db.Keyspace.(Keyspace.java:309)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:133)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:110)
>   at 
> org.apache.cassandra.io.sstable.SSTableTxnWriter.create(SSTableTxnWriter.java:97)
>   at 
> org.apache.cassandra.io.sstable.AbstractSSTableSimpleWriter.createWriter(AbstractSSTableSimpleWriter.java:63)
>   at 
> org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:206)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1153)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:116)
>   ... 7 more



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

[jira] [Created] (CASSANDRA-10472) fix upgrade test for multi list sets on 2.2->3.0 upgrade path

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10472:


 Summary: fix upgrade test for multi list sets on 2.2->3.0 upgrade 
path
 Key: CASSANDRA-10472
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10472
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
 Fix For: 3.0.0 rc2


The following test fails on the upgrade path from 2.2 to 3.0:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/lastCompletedBuild/testReport/upgrade_tests.cql_tests/TestCQL/multi_list_set_test/

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs. 
Until then, you can run it with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.multi_list_set_test
{code}




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

[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap due to long GC pause

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-10449:


There are couples of things going on.

{code}
ERROR [StreamReceiveTask:29] 2015-10-05 14:46:17,090 CassandraDaemon.java:223 - 
Exception in thread Thread[StreamReceiveTask:29,5,main]
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: 
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
{code}

When rebuilding secondary index after receiving files, bootstrapping node is 
experiencing TombstoneOverwhelmingException.
This can make streaming to hang, as it never completes the receiving task.
Streaming should tolerate secondary index build failure, instead of failing 
entire stream session, it should just warn user and go on, so that user can 
manually trigger secondary index rebuild later.

I'm not sure the above relates to OOM. From StatusLogger, FlushWriter task is 
glowing and that is the cause of OOM.
If you can capture stack using jstack, that would be greate help.

I create separate JIRA for the former.

> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
>  Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and 
> 500-700GB per node.  SSTable counts are <10 per table.  I am attempting to 
> provision additional nodes, but bootstrapping OOMs every time after about 10 
> hours with a sudden long GC pause:
> {noformat}
> INFO  [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old 
> Generation GC in 1586126ms.  G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to 
> no avail.



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

[jira] [Commented] (CASSANDRA-10415) Fix cqlsh bugs

[Jim Witschey (JIRA)]

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

Jim Witschey commented on CASSANDRA-10415:
--

These same tests fail on 3.0, so I'm making this ticket a subtask of 
CASSANDRA-10166 and setting the fix version to rc2. These tests run on 3.0 on 
CassCI here:

http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_cqlshlib/2/testReport/

> Fix cqlsh bugs
> --
>
> Key: CASSANDRA-10415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10415
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.0.0 rc2
>
>
> This is followup to CASSANDRA-10289
> The tests currently failing should be:
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_columnfamily}}
> ** uses {{create_columnfamily_table_template}}. Stefania says "the {{(}} 
> after {{CREATE ... IF}} does not look valid to me."
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_table}}
> ** uses {{create_columnfamily_table_template}}, see above.
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_delete}}
> ** Stefania says: "I don't think keyspaces are a valid completion after 
> {{DELETE a [}} and after {{DELETE FROM twenty_rows_composite_table USING 
> TIMESTAMP 0 WHERE TOKEN(a) >=}}. From a quick analysis of {{cqlhandling.py}} 
> I think it comes from {{}}, which picks up {{}}, which 
> was changed to include {{ks.}} by CASSANDRA-7556.
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_drop_keyspace}}
> ** Stefania says: "the {{;}} after {{DROP KEYSPACE IF}} is not valid.
> * {{cqlshlib.test.test_cqlsh_output.TestCqlshOutput.test_timestamp_output}}
> ** already documented with CASSANDRA-10313 and CASSANDRA-10397
> I'm happy to break these out into separate tickets if necessary. 
> To run the tests locally, I cd to {{cassandra/pylib/cqlshlib}} and run the 
> following:
> {code}
> ccm create -n 1 --install-dir=../.. test
> ccm start --wait-for-binary-proto
> nosetests test 2>&1
> ccm remove
> {code}
> This requires nose and ccm. Until CASSANDRA-10289 is resolved, you'll have to 
> use my branch here: https://github.com/mambocab/cassandra/tree/fix-cqlsh-tests
> Tests for this branch are run (non-continuously) here:
> http://cassci.datastax.com/job/scratch_mambocab-fix_cqlsh/
> Assigning [~Stefania] for now, since she's already looked at 10289, but feel 
> free to reassign.



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

[jira] [Comment Edited] (CASSANDRA-10205) decommissioned_wiped_node_can_join_test fails on Jenkins

[Joel Knighton (JIRA)]

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

Joel Knighton edited comment on CASSANDRA-10205 at 10/7/15 10:05 PM:
-

I'm +1 on C* patch and dtest patch. {{markDead}} makes sense for nodes that 
have LEFT because we consider LEFT a dead state elsewhere in Gossip.

A note for anyone following: in the dtest, we've switched from hardstopping the 
node to stopping the node gracefully. This is fine since it exercises the same 
code path, since LEFT is a dead state so shutting it down gracefully will leave 
it LEFT in gossip, and we'll go through {{markDead}}.

Sorry for how long this was stuck in limbo.


was (Author: jkni):
I'm +1 on C* patch and dtest patch. `markDead` makes sense for nodes that have 
LEFT because we consider LEFT a dead state elsewhere in Gossip.

A note for anyone following: in the dtest, we've switched from hardstopping the 
node to stopping the node gracefully. This is fine since it exercises the same 
code path, since LEFT is a dead state so shutting it down gracefully will leave 
it LEFT in gossip, and we'll go through `markDead`.

Sorry for how long this was stuck in limbo.

> decommissioned_wiped_node_can_join_test fails on Jenkins
> 
>
> Key: CASSANDRA-10205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10205
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.0 rc2
>
> Attachments: decommissioned_wiped_node_can_join_test.tar.gz
>
>
> This test passes locally but reliably fails on Jenkins. It seems after we 
> restart node4, it is unable to Gossip with other nodes:
> {code}
> INFO  [HANDSHAKE-/127.0.0.2] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.2
> INFO  [HANDSHAKE-/127.0.0.1] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.1
> INFO  [HANDSHAKE-/127.0.0.3] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.3
> ERROR [main] 2015-08-27 06:51:13,785 CassandraDaemon.java:635 - Exception 
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at 
> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1342) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:518)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:763)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:320) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [main/:na]
> WARN  [StorageServiceShutdownHook] 2015-08-27 06:51:13,799 Gossiper.java:1453 
> - No local state or state is in silent shutdown, not announcing shutdown
> {code}
> It seems both the addresses and port number of the seeds are correct so I 
> don't think the problem is the Amazon private addresses but I might be wrong. 
> It's also worth noting that the first time the node starts up without 
> problems. The problem only occurs during a restart.



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

[jira] [Updated] (CASSANDRA-10471) fix flapping empty_in_test dtest

[Jim Witschey (JIRA)]

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

Jim Witschey updated CASSANDRA-10471:
-
Description: 
{{upgrade_tests/cql_tests.py:TestCQL.empty_in_test}} fails about half the time 
on the upgrade path from 2.2 to 3.0:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.cql_tests/TestCQL/empty_in_test/history/

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs. 
Until then, you can run it with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.empty_in_test
{code}



  was:
{{upgrade_tests/cql_tests.py:TestCQL.empty_in_test}} fails on the upgrade path 
from 2.2 to 3.0

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.cql_tests/TestCQL/empty_in_test/history/


> fix flapping empty_in_test dtest
> 
>
> Key: CASSANDRA-10471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10471
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
> Fix For: 3.0.0 rc2
>
>
> {{upgrade_tests/cql_tests.py:TestCQL.empty_in_test}} fails about half the 
> time on the upgrade path from 2.2 to 3.0:
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.cql_tests/TestCQL/empty_in_test/history/
> Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
> merged, these tests should also run with this upgrade path on normal 3.0 
> jobs. Until then, you can run it with the following command:
> {code}
> SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
> nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.empty_in_test
> {code}



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

[jira] [Comment Edited] (CASSANDRA-10449) OOM on bootstrap due to long GC pause

[Yuki Morishita (JIRA)]

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

Yuki Morishita edited comment on CASSANDRA-10449 at 10/7/15 11:25 PM:
--

There are couples of things going on.

{code}
ERROR [StreamReceiveTask:29] 2015-10-05 14:46:17,090 CassandraDaemon.java:223 - 
Exception in thread Thread[StreamReceiveTask:29,5,main]
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: 
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
{code}

When rebuilding secondary index after receiving files, bootstrapping node is 
experiencing TombstoneOverwhelmingException.
This can make streaming to hang, as it never completes the receiving task.
Streaming should tolerate secondary index build failure, instead of failing 
entire stream session, it should just warn user and go on, so that user can 
manually trigger secondary index rebuild later.

I'm not sure the above relates to OOM. From StatusLogger, FlushWriter task is 
glowing and that is the cause of OOM.
-If you can capture stack using jstack, that would be greate help.- Missed 
attachment, sorry.

-I create separate JIRA for the former.- Created CASSANDRA-10474.


was (Author: yukim):
There are couples of things going on.

{code}
ERROR [StreamReceiveTask:29] 2015-10-05 14:46:17,090 CassandraDaemon.java:223 - 
Exception in thread Thread[StreamReceiveTask:29,5,main]
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: 
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
{code}

When rebuilding secondary index after receiving files, bootstrapping node is 
experiencing TombstoneOverwhelmingException.
This can make streaming to hang, as it never completes the receiving task.
Streaming should tolerate secondary index build failure, instead of failing 
entire stream session, it should just warn user and go on, so that user can 
manually trigger secondary index rebuild later.

I'm not sure the above relates to OOM. From StatusLogger, FlushWriter task is 
glowing and that is the cause of OOM.
If you can capture stack using jstack, that would be greate help.

-I create separate JIRA for the former.- Created CASSANDRA-10474.

> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
>  Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and 
> 500-700GB per node.  SSTable counts are <10 per table.  I am attempting to 
> provision additional nodes, but bootstrapping OOMs every time after about 10 
> hours with a sudden long GC pause:
> {noformat}
> INFO  [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old 
> Generation GC in 1586126ms.  G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to 
> no avail.



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

[jira] [Comment Edited] (CASSANDRA-10459) Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-10459 at 10/7/15 11:38 PM:
---

The test was checking if total off-heap memory usage since node start was below 
the large column size (66060288 bytes), and it was passing on cassandra 2.2. 
However, on 3.0 it was not passing (probably due to increase in off-heap memory 
footprint), so I modified the test to check the memory usage delta instead 
(before and after stress), which should be sufficient to identify if heap usage 
grows proportional to column size.

[cassandra-dtest PR|https://github.com/riptano/cassandra-dtest/pull/585] 
created. Would you mind reviewing, [~aweisberg]? Thanks.


was (Author: pauloricardomg):
The test was checking if total off-heap memory usage since node start was below 
the large column size (66060288 bytes), and it was passing on cassandra 2.2 
However, on 3.0 it was not passing, so I modified the test to check the memory 
usage delta instead (before and after stress), which should be sufficient to 
identify if heap usage grows proportional to column size.

[cassandra-dtest PR|https://github.com/riptano/cassandra-dtest/pull/585] 
created. Would you mind reviewing, [~aweisberg]? Thanks.

> Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest
> --
>
> Key: CASSANDRA-10459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10459
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This test on large columns is failing:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/largecolumn_test/TestLargeColumn/cleanup_test/
> and it's been failing for a while:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/junit/largecolumn_test/TestLargeColumn/cleanup_test/history/
> I've reproduced the failure on OpenStack, so it's not just a CassCI problem.



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

[jira] [Commented] (CASSANDRA-10244) Replace heartbeats with locally recorded metrics for failure detection

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-10244:
-

My proposal, nor any algorithm for that matter, cannot solve the worst case 
behavior - send a request and wait for it to time out, as it is impossible to 
know when a peer will become unavailable, or that packet gets lost, and so on. 
However, I believe my proposal will perform better in the average case as we 
use our own local knowledge of availability (based upon responses to previous 
requests) to judge whether we send the request to a peer (or select another 
peer or hint) - and not just use the transitive availability that the heartbeat 
provides. While the paper doesn't quite get the details correct about why the 
gossip messages (which carry the heartbeat) aren't propagating as expected, 
they do correctly identify the absence of *continuous and steady* propagation 
of the heartbeats causes the FailureDetector to get unhappy and mark the peer 
UP, then DOWN, then UP, then DOWN, then...


> Replace heartbeats with locally recorded metrics for failure detection
> --
>
> Key: CASSANDRA-10244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10244
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> In the current implementation, the primary purpose of sending gossip messages 
> is for delivering the updated heartbeat values of each node in a cluster. The 
> other data that is passed in gossip (node metadata such as status, dc, rack, 
> tokens, and so on) changes very infrequently (or rarely), such that the 
> eventual delivery of that data is entirely reasonable. Heartbeats, however, 
> are quite different. A continuous and nearly consistent delivery time of 
> updated heartbeats is critical for the stability of a cluster. It is through 
> the receipt of the updated heartbeat that a node determines the reachability 
> (UP/DOWN status) of all peers in the cluster. The current implementation of 
> FailureDetector measures the time differences between the heartbeat updates 
> received about a peer (Note: I said about a peer, not from the peer directly, 
> as those values are disseminated via gossip). Without a consistent time 
> delivery of those updates, the FD, via it's use of the PHI-accrual 
> algorigthm, will mark the peer as DOWN (unreachable). The two nodes could be 
> sending all other traffic without problem, but if the heartbeats are not 
> propagated correctly, each of the nodes will mark the other as DOWN, which is 
> clearly suboptimal to cluster health. Further, heartbeat updates are the only 
> mechanism we use to determine reachability (UP/DOWN) of a peer; dynamic 
> snitch measurements, for example, are not included in the determination. 
> To illustrate this, in the current implementation, assume a cluster of nodes: 
> A, B, and C. A partition starts between nodes A and C (no communication 
> succeeds), but both nodes can communicate with B. As B will get the updated 
> heartbeats from both A and C, it will, via gossip, send those over to the 
> other node. Thus, A thinks C is UP, and C thinks A is UP. Unfortunately, due 
> to the partition between them, all communication between A and C will fail, 
> yet neither node will mark the other as down because each is receiving, 
> transitively via B, the updated heartbeat about the other. While it's true 
> that the other node is alive, only having transitive knowledge about a peer, 
> and allowing that to be the sole determinant of UP/DOWN reachability status, 
> is not sufficient for a correct and effieicently operating cluster. 
> This transitive availability is suboptimal, and I propose we drop the 
> heartbeat concept altogether. Instead, the dynamic snitch should become more 
> intelligent, and it's measurements ultimately become the input for 
> determining the reachability status of each peer(as fed into a revamped FD). 
> As we already capture latencies in the dsntich, we can reasonably extend it 
> to include timeouts/missed responses, and make that the basis for the UP/DOWN 
> decisioning. Thus we will have more accurate and relevant peer statueses that 
> is tailored to the local node.  



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

[jira] [Updated] (CASSANDRA-10468) Fix class-casting error in mixed clusters for 2.2->3.0 upgrades

[Jim Witschey (JIRA)]

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

Jim Witschey updated CASSANDRA-10468:
-
Description: 
Three upgrade tests:

- {{upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test}}
- {{upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test}}
- {{upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test}}

fail on the upgrade path from 2.2 to 3.0. The failures can be found on CassCI 
here:

[cas_and_list_index_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/cas_and_list_index_test/]
[collection_and_regular_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/collection_and_regular_test/]
[composite_index_collections_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/composite_index_collections_test/]

You can run these tests with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test 
upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test 
upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test
{code}

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs.

EDIT: the following test seems to fail with the same error:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/41/testReport/upgrade_tests.cql_tests/TestCQL/null_support_test/

  was:
Three upgrade tests:

- {{upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test}}
- {{upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test}}
- {{upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test}}

fail on the upgrade path from 2.2 to 3.0. The failures can be found on CassCI 
here:

[cas_and_list_index_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/cas_and_list_index_test/]
[collection_and_regular_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/collection_and_regular_test/]
[composite_index_collections_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/composite_index_collections_test/]

You can run these tests with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test 
upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test 
upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test
{code}

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs.


> Fix class-casting error in mixed clusters for 2.2->3.0 upgrades
> ---
>
> Key: CASSANDRA-10468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10468
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
> Fix For: 3.0.0 rc2
>
>
> Three upgrade tests:
> - {{upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test}}
> - {{upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test}}
> - {{upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test}}
> fail on the upgrade path from 2.2 to 3.0. The failures can be found on CassCI 
> here:
> [cas_and_list_index_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/cas_and_list_index_test/]
> [collection_and_regular_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/collection_and_regular_test/]
> [composite_index_collections_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/composite_index_collections_test/]
> You can run these tests with the following command:
> {code}
> SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
> nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test 
> upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test 
> upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test
> {code}
> Once [this dtest 

[jira] [Commented] (CASSANDRA-10421) Potential issue with LogTransaction as it only checks in a single directory for files

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10421:


Can you set the ticket to patch available?

If rc2 is end of the week I think it's going to be hard to get to +1 for a new 
sub-system and patch like this. I'm not going to be able to do more review 
until tomorrow evening my time.

bq. We don't duplicate all records to all files, only the final commit or abort 
flag is written to all files. When we read the files on startup we collect all 
the sstable records from all existing txn files and check that the final flag 
record is the same in all files (but we do accept if some files are missing the 
last record and in this case we just warn). Therefore, if a file is lost we 
continue with the transaction processing but we do not touch the sstables in 
the folder of that file. Chances are either the entire disk was lost or the 
user deleted the file and in this case the user probably wanted to keep the 
sstables. Does this make sense?

Is there an advantage to writing only the commit record to all the files? Seems 
conceptually easier for them to all be the same log and since it is low traffic 
there is no performance motivation. Was there a discussion somewhere else where 
it seemed like people might delete the file? Are we really ok with losing 
atomicity if they don't lose the whole disk?

If they all had all the records you could just read the contents from any file 
that has a commit record.

* [Can you just have it do nothing if it is called multiple 
times?|https://github.com/stef1927/cassandra/commit/49a2d5f289c98fcf646272cfab777d20001f9b9e#diff-d8721a4dd04f4f35b65e7edeb6c883f6R198].
 Maybe save a headache down the road.
* [Why is this check not necessary 
anymore?|https://github.com/stef1927/cassandra/commit/49a2d5f289c98fcf646272cfab777d20001f9b9e#diff-d8721a4dd04f4f35b65e7edeb6c883f6L161]
* [Not part of your current work, but relying on modified time for files seems 
suspect to me, file contents should have the modified time so copying and other 
operations don't change 
it|https://github.com/stef1927/cassandra/commit/49a2d5f289c98fcf646272cfab777d20001f9b9e#diff-d8721a4dd04f4f35b65e7edeb6c883f6R283]

I got through a first pass of the implementation. I'm looking at the tests now.


> Potential issue with LogTransaction as it only checks in a single directory 
> for files
> -
>
> Key: CASSANDRA-10421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10421
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Stefania
>Priority: Blocker
> Fix For: 3.0.0 rc2
>
>
> When creating a new LogTransaction we try to create the new logfile in the 
> same directory as the one we are writing to, but as we use 
> {{[directories.getDirectoryForNewSSTables()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogTransaction.java#L125]}}
>  this might end up in "any" of the configured data directories. If it does, 
> we will not be able to clean up leftovers as we check for files in the same 
> directory as the logfile was created: 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L163
> cc [~Stefania]



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

[jira] [Commented] (CASSANDRA-10459) Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10459:
-

The test was checking if total off-heap memory usage since node start was below 
the large column size (66060288 bytes), and it was passing on cassandra 2.2 
However, on 3.0 it was not passing, so I modified the test to check the memory 
usage delta instead (before and after stress), which should be sufficient to 
identify if heap usage grows proportional to column size.

[cassandra-dtest PR|https://github.com/riptano/cassandra-dtest/pull/585] 
created. Would you mind reviewing, [~aweisberg]? Thanks.

> Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest
> --
>
> Key: CASSANDRA-10459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10459
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This test on large columns is failing:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/largecolumn_test/TestLargeColumn/cleanup_test/
> and it's been failing for a while:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/junit/largecolumn_test/TestLargeColumn/cleanup_test/history/
> I've reproduced the failure on OpenStack, so it's not just a CassCI problem.



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

[jira] [Created] (CASSANDRA-10475) skip protocol v2 test on versions that don't support it

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10475:


 Summary: skip protocol v2 test on versions that don't support it
 Key: CASSANDRA-10475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10475
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Jim Witschey


This ticket tracks the following failure:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/lastCompletedBuild/testReport/upgrade_tests.cql_tests/TestCQL/test_v2_protocol_IN_with_tuples/

It's caused by a bug in the dtests, which is addressed in this PR:

https://github.com/riptano/cassandra-dtest/pull/587

Just adding this ticket for others' reference when they're looking at CassCI 
failures.



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

[jira] [Created] (CASSANDRA-10476) Fix upgrade paging dtest failures on 2.2->3.0 path

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10476:


 Summary: Fix upgrade paging dtest failures on 2.2->3.0 path
 Key: CASSANDRA-10476
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10476
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey


The following upgrade tests for paging features fail or flap on the upgrade 
path from 2.2 to 3.0:

- {{upgrade_tests/paging_test.py:TestPagingData.static_columns_paging_test}}
- 
{{upgrade_tests/paging_test.py:TestPagingSize.test_undefined_page_size_default}}
- 
{{upgrade_tests/paging_test.py:TestPagingSize.test_with_more_results_than_page_size}}
- 
{{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_failure_threshold_deletions}}
- 
{{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_multiple_cell_deletions}}
- 
{{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_cell_deletions}}
- 
{{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_row_deletions}}

I've grouped them all together because I don't know how to tell if they're 
related; once someone triages them, it may be appropriate to break this out 
into multiple tickets.

The failures can be found here:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingData/static_columns_paging_test/history/
http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingSize/test_undefined_page_size_default/history/
http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.paging_test/TestPagingSize/test_with_more_results_than_page_size/history/
http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_failure_threshold_deletions/history/
http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_multiple_cell_deletions/history/
http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_single_cell_deletions/history/
http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_single_row_deletions/history/

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs. 
Until then, you can run them with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 
upgrade_tests/paging_test.py:TestPagingData.static_columns_paging_test 
upgrade_tests/paging_test.py:TestPagingSize.test_undefined_page_size_default 
upgrade_tests/paging_test.py:TestPagingSize.test_with_more_results_than_page_size
 
upgrade_tests/paging_test.py:TestPagingWithDeletions.test_failure_threshold_deletions
 
upgrade_tests/paging_test.py:TestPagingWithDeletions.test_multiple_cell_deletions
 
upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_cell_deletions 
upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_row_deletions
{code}



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

[jira] [Commented] (CASSANDRA-10466) json2sstable import failing

[Brandon Williams (JIRA)]

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

Brandon Williams commented on CASSANDRA-10466:
--

This turned out to be a schema mismatch... it would be still be nice to have a 
better error, however.

> json2sstable import failing
> ---
>
> Key: CASSANDRA-10466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10466
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
> Fix For: 2.1.x
>
>
> In CASSANDRA-7477 we fixed part of this, but it's still possible to have a 
> variant of this problem:
> {noformat}
> Importing 1 keys...
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
> at 
> org.apache.cassandra.tools.SSTableImport$JsonColumn.(SSTableImport.java:145)
> at 
> org.apache.cassandra.tools.SSTableImport.addColumnsToCF(SSTableImport.java:213)
> at 
> org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:327)
> at 
> org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:287)
> at 
> org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:514)
> ERROR: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
> {noformat}
> I can provide the schema and json file offline if needed.



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

[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[yukim]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 397145219727e0651db3102b7837146c3e8dfad1
Parents: dc6f5bd 9415c84
Author: Yuki Morishita 
Authored: Wed Oct 7 16:54:31 2015 -0500
Committer: Yuki Morishita 
Committed: Wed Oct 7 16:54:31 2015 -0500

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java | 6 --
 .../cassandra/io/sstable/CQLSSTableWriterClientTest.java   | 2 +-
 3 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/39714521/CHANGES.txt
--
diff --cc CHANGES.txt
index 16958a1,72c09d3..b819e11
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 +3.2
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +
 +
  3.0
+  * Do not load keyspace when creating sstable writer (CASSANDRA-10443)
   * If node is not yet gossiping write all MV updates to batchlog only 
(CASSANDRA-10413)
   * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
   * Provide additional metrics for materialized views (CASSANDRA-10323)

[1/3] cassandra git commit: Do not load keyspace when creating sstable writer

[yukim]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 6c3fa8e30 -> 9415c8460
  refs/heads/trunk dc6f5bdb0 -> 397145219


Do not load keyspace when creating sstable writer

patch by carlyeks; reviewed by yukim for CASSANDRA-10443


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

Branch: refs/heads/cassandra-3.0
Commit: 9415c8460ce2bd72502cc35dd74a9e0e0358998c
Parents: 6c3fa8e
Author: Carl Yeksigian 
Authored: Wed Oct 7 16:53:55 2015 -0500
Committer: Yuki Morishita 
Committed: Wed Oct 7 16:53:55 2015 -0500

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java | 6 --
 .../cassandra/io/sstable/CQLSSTableWriterClientTest.java   | 2 +-
 3 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9415c846/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0bac64e..72c09d3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Do not load keyspace when creating sstable writer (CASSANDRA-10443)
  * If node is not yet gossiping write all MV updates to batchlog only 
(CASSANDRA-10413)
  * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
  * Provide additional metrics for materialized views (CASSANDRA-10323)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9415c846/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
index 0b50901..9ad5a80 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
@@ -104,12 +104,6 @@ public class SSTableTxnWriter extends 
Transactional.AbstractTransactional implem
 @SuppressWarnings("resource") // log and writer closed during postCleanup
 public static SSTableTxnWriter create(CFMetaData cfm, Descriptor 
descriptor, long keyCount, long repairedAt, int sstableLevel, 
SerializationHeader header)
 {
-if (Keyspace.open(cfm.ksName).hasColumnFamilyStore(cfm.cfId))
-{
-ColumnFamilyStore cfs = 
Keyspace.open(cfm.ksName).getColumnFamilyStore(cfm.cfId);
-return create(cfs, descriptor, keyCount, repairedAt, sstableLevel, 
header);
-}
-
 // if the column family store does not exist, we create a new default 
SSTableMultiWriter to use:
 LifecycleTransaction txn = 
LifecycleTransaction.offline(OperationType.WRITE, descriptor.directory);
 MetadataCollector collector = new 
MetadataCollector(cfm.comparator).sstableLevel(sstableLevel);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9415c846/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java 
b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
index a9165f7..d38276f 100644
--- a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
@@ -45,7 +45,7 @@ public class CQLSSTableWriterClientTest
 public void setUp()
 {
 this.testDirectory = Files.createTempDir();
-Keyspace.setInitialized();
+Config.setClientMode(true);
 }
 
 @After

[2/3] cassandra git commit: Do not load keyspace when creating sstable writer

[yukim]

Do not load keyspace when creating sstable writer

patch by carlyeks; reviewed by yukim for CASSANDRA-10443


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

Branch: refs/heads/trunk
Commit: 9415c8460ce2bd72502cc35dd74a9e0e0358998c
Parents: 6c3fa8e
Author: Carl Yeksigian 
Authored: Wed Oct 7 16:53:55 2015 -0500
Committer: Yuki Morishita 
Committed: Wed Oct 7 16:53:55 2015 -0500

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java | 6 --
 .../cassandra/io/sstable/CQLSSTableWriterClientTest.java   | 2 +-
 3 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9415c846/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0bac64e..72c09d3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Do not load keyspace when creating sstable writer (CASSANDRA-10443)
  * If node is not yet gossiping write all MV updates to batchlog only 
(CASSANDRA-10413)
  * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
  * Provide additional metrics for materialized views (CASSANDRA-10323)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9415c846/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
index 0b50901..9ad5a80 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableTxnWriter.java
@@ -104,12 +104,6 @@ public class SSTableTxnWriter extends 
Transactional.AbstractTransactional implem
 @SuppressWarnings("resource") // log and writer closed during postCleanup
 public static SSTableTxnWriter create(CFMetaData cfm, Descriptor 
descriptor, long keyCount, long repairedAt, int sstableLevel, 
SerializationHeader header)
 {
-if (Keyspace.open(cfm.ksName).hasColumnFamilyStore(cfm.cfId))
-{
-ColumnFamilyStore cfs = 
Keyspace.open(cfm.ksName).getColumnFamilyStore(cfm.cfId);
-return create(cfs, descriptor, keyCount, repairedAt, sstableLevel, 
header);
-}
-
 // if the column family store does not exist, we create a new default 
SSTableMultiWriter to use:
 LifecycleTransaction txn = 
LifecycleTransaction.offline(OperationType.WRITE, descriptor.directory);
 MetadataCollector collector = new 
MetadataCollector(cfm.comparator).sstableLevel(sstableLevel);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9415c846/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java 
b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
index a9165f7..d38276f 100644
--- a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterClientTest.java
@@ -45,7 +45,7 @@ public class CQLSSTableWriterClientTest
 public void setUp()
 {
 this.testDirectory = Files.createTempDir();
-Keyspace.setInitialized();
+Config.setClientMode(true);
 }
 
 @After

[jira] [Created] (CASSANDRA-10469) Fix collection indexing upgrade dtest

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10469:


 Summary: Fix collection indexing upgrade dtest
 Key: CASSANDRA-10469
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10469
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
 Fix For: 3.0.0 rc2


{{upgrade_tests/cql_tests.py:TestCQL.collection_indexing_test}} fails on the 
upgrade path from 2.2 to 3.0. You can see the failure on CassCI here:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.cql_tests/TestCQL/collection_indexing_test/

Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
merged, these tests should also run with this upgrade path on normal 3.0 jobs. 
Until then, you can run it with the following command:

{code}
SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.collection_indexing_test
{code}

Note that this test fails most of the time, but does occasionally succeed:

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/44/testReport/upgrade_tests.cql_tests/TestCQL/collection_indexing_test/history/



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

[jira] [Commented] (CASSANDRA-10434) Problem upgrading to 3.0 with UDA

[Andrew Hust (JIRA)]

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

Andrew Hust commented on CASSANDRA-10434:
-

Confirmed patch fixes issue with exception post upgrade and UDA performs as 
expected post upgrade.  Once this has been merged I'll update the upgrading 
dtest to include UDA's in setup and verification.

Ran with:
apache/cassandra-2.2 {{be89dae3ecfd98b2170732c45d7f95807d5c19af}}
snazy/10434-uda-migration-3.0 {{b83a088f252e906faa9924def8e24997e072c109}}

> Problem upgrading to 3.0 with UDA
> -
>
> Key: CASSANDRA-10434
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10434
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Fix For: 3.0.0 rc2
>
>
> Copy-pasting from [~nutbunnies] comment on CASSANDRA-9756:
> {quote}
> upgrading from 2.2 to 3.0 with a UDA defined will throw the exception below 
> and fail to start when upgraded to 3.0.
> Used:
> 2.2: {{ae9b7e05222b2a25eda5618cf9eb17103e4d6d8b}}
> 3.0: {{5c2912d1ce95aacdacb59ccc840b12cd9aa0c8f8}}
> {noformat}
> org.apache.cassandra.exceptions.UnrecognizedEntityException: Undefined name 
> function_name in where clause ('function_name = ?')
> at 
> org.apache.cassandra.cql3.Relation.toColumnDefinition(Relation.java:259) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.SingleColumnRelation.newEQRestriction(SingleColumnRelation.java:160)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.Relation.toRestriction(Relation.java:137) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:151)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepareRestrictions(SelectStatement.java:817)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:764)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:752)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:504)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:241)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:336)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.query(LegacySchemaMigrator.java:882)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readAggregateMetadata(LegacySchemaMigrator.java:849)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readAggregate(LegacySchemaMigrator.java:830)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readAggregates$216(LegacySchemaMigrator.java:823)
>  ~[main/:na]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_60]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readAggregates(LegacySchemaMigrator.java:823)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:166)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$207(LegacySchemaMigrator.java:154)
>  ~[main/:na]
> at java.util.ArrayList.forEach(ArrayList.java:1249) ~[na:1.8.0_60]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:154)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.migrate(LegacySchemaMigrator.java:77)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:223) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:542)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:668) 
> [main/:na]
> {noformat}
> Can be reproduced with:
> {noformat}
> ccm stop
> ccm remove uda_upgrade
> ccm create -n 1 -v git:cassandra-2.2 uda_upgrade
> ccm updateconf 'enable_user_defined_functions: true'
> ccm start
> cat << EOF | ccm node1 cqlsh
> create keyspace ks WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> USE ks;
> CREATE FUNCTION func_1(current int, candidate int)
> CALLED ON NULL INPUT
> RETURNS int LANGUAGE java AS
> 'if (current == null) return candidate; else return 
> Math.max(current, candidate);';
> CREATE AGGREGATE agg_1(int)
> SFUNC func_1
> STYPE int
> INITCOND null;
> EOF
> sleep 10
> echo "Draining all nodes"
> ccm node1 nodetool drain
> ccm stop
> 

[jira] [Updated] (CASSANDRA-10468) Fix class-casting error in mixed clusters for 2.2->3.0 upgrades

[Jim Witschey (JIRA)]

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

Jim Witschey updated CASSANDRA-10468:
-
Summary: Fix class-casting error in mixed clusters for 2.2->3.0 upgrades  
(was: Fix class-casting error in mixed clusters)

> Fix class-casting error in mixed clusters for 2.2->3.0 upgrades
> ---
>
> Key: CASSANDRA-10468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10468
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
> Fix For: 3.0.0 rc2
>
>
> Three upgrade tests:
> - {{upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test}}
> - {{upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test}}
> - {{upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test}}
> fail on the upgrade path from 2.2 to 3.0. The failures can be found on CassCI 
> here:
> [cas_and_list_index_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/cas_and_list_index_test/]
> [collection_and_regular_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/collection_and_regular_test/]
> [composite_index_collections_test|http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/43/testReport/upgrade_tests.cql_tests/TestCQL/composite_index_collections_test/]
> You can run these tests with the following command:
> {code}
> SKIP=false CASSANDRA_VERSION=binary:2.2.0 UPGRADE_TO=git:cassandra-3.0 
> nosetests 2>&1 upgrade_tests/cql_tests.py:TestCQL.cas_and_list_index_test 
> upgrade_tests/cql_tests.py:TestCQL.collection_and_regular_test 
> upgrade_tests/cql_tests.py:TestCQL.composite_index_collections_test
> {code}
> Once [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/586] is 
> merged, these tests should also run with this upgrade path on normal 3.0 jobs.



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

[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap due to long GC pause

[Robbie Strickland (JIRA)]

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

Robbie Strickland commented on CASSANDRA-10449:
---

I am going to try again after increasing streaming_socket_timeout_in_ms and 
memtable_flush_writers.  I had not touched these values, so it's possible that 
was hurting me.

> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
>  Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and 
> 500-700GB per node.  SSTable counts are <10 per table.  I am attempting to 
> provision additional nodes, but bootstrapping OOMs every time after about 10 
> hours with a sudden long GC pause:
> {noformat}
> INFO  [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old 
> Generation GC in 1586126ms.  G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to 
> no avail.



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

[jira] [Commented] (CASSANDRA-10205) decommissioned_wiped_node_can_join_test fails on Jenkins

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-10205:
---

I'm +1 on C* patch and dtest patch. `markDead` makes sense for nodes that have 
LEFT because we consider LEFT a dead state elsewhere in Gossip.

A note for anyone following: in the dtest, we've switched from hardstopping the 
node to stopping the node gracefully. This is fine since it exercises the same 
code path, since LEFT is a dead state so shutting it down gracefully will leave 
it LEFT in gossip, and we'll go through `markDead`.

Sorry for how long this was stuck in limbo.

> decommissioned_wiped_node_can_join_test fails on Jenkins
> 
>
> Key: CASSANDRA-10205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10205
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.0 rc2
>
> Attachments: decommissioned_wiped_node_can_join_test.tar.gz
>
>
> This test passes locally but reliably fails on Jenkins. It seems after we 
> restart node4, it is unable to Gossip with other nodes:
> {code}
> INFO  [HANDSHAKE-/127.0.0.2] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.2
> INFO  [HANDSHAKE-/127.0.0.1] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.1
> INFO  [HANDSHAKE-/127.0.0.3] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.3
> ERROR [main] 2015-08-27 06:51:13,785 CassandraDaemon.java:635 - Exception 
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at 
> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1342) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:518)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:763)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:320) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [main/:na]
> WARN  [StorageServiceShutdownHook] 2015-08-27 06:51:13,799 Gossiper.java:1453 
> - No local state or state is in silent shutdown, not announcing shutdown
> {code}
> It seems both the addresses and port number of the seeds are correct so I 
> don't think the problem is the Amazon private addresses but I might be wrong. 
> It's also worth noting that the first time the node starts up without 
> problems. The problem only occurs during a restart.



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

[jira] [Updated] (CASSANDRA-10415) Fix cqlsh bugs

[Jim Witschey (JIRA)]

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

Jim Witschey updated CASSANDRA-10415:
-
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-10166

> Fix cqlsh bugs
> --
>
> Key: CASSANDRA-10415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10415
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.0.0 rc2
>
>
> This is followup to CASSANDRA-10289
> The tests currently failing should be:
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_columnfamily}}
> ** uses {{create_columnfamily_table_template}}. Stefania says "the {{(}} 
> after {{CREATE ... IF}} does not look valid to me."
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_table}}
> ** uses {{create_columnfamily_table_template}}, see above.
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_delete}}
> ** Stefania says: "I don't think keyspaces are a valid completion after 
> {{DELETE a [}} and after {{DELETE FROM twenty_rows_composite_table USING 
> TIMESTAMP 0 WHERE TOKEN(a) >=}}. From a quick analysis of {{cqlhandling.py}} 
> I think it comes from {{}}, which picks up {{}}, which 
> was changed to include {{ks.}} by CASSANDRA-7556.
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_drop_keyspace}}
> ** Stefania says: "the {{;}} after {{DROP KEYSPACE IF}} is not valid.
> * {{cqlshlib.test.test_cqlsh_output.TestCqlshOutput.test_timestamp_output}}
> ** already documented with CASSANDRA-10313 and CASSANDRA-10397
> I'm happy to break these out into separate tickets if necessary. 
> To run the tests locally, I cd to {{cassandra/pylib/cqlshlib}} and run the 
> following:
> {code}
> ccm create -n 1 --install-dir=../.. test
> ccm start --wait-for-binary-proto
> nosetests test 2>&1
> ccm remove
> {code}
> This requires nose and ccm. Until CASSANDRA-10289 is resolved, you'll have to 
> use my branch here: https://github.com/mambocab/cassandra/tree/fix-cqlsh-tests
> Tests for this branch are run (non-continuously) here:
> http://cassci.datastax.com/job/scratch_mambocab-fix_cqlsh/
> Assigning [~Stefania] for now, since she's already looked at 10289, but feel 
> free to reassign.



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

[jira] [Created] (CASSANDRA-10471) fix flapping empty_in_test dtest

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10471:


 Summary: fix flapping empty_in_test dtest
 Key: CASSANDRA-10471
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10471
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey
 Fix For: 3.0.0 rc2


{{upgrade_tests/cql_tests.py:TestCQL.empty_in_test}} fails on 

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.cql_tests/TestCQL/empty_in_test/history/



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

[jira] [Updated] (CASSANDRA-10471) fix flapping empty_in_test dtest

[Jim Witschey (JIRA)]

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

Jim Witschey updated CASSANDRA-10471:
-
Description: 
{{upgrade_tests/cql_tests.py:TestCQL.empty_in_test}} fails on the upgrade path 
from 2.2 to 3.0

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.cql_tests/TestCQL/empty_in_test/history/

  was:
{{upgrade_tests/cql_tests.py:TestCQL.empty_in_test}} fails on 

http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.cql_tests/TestCQL/empty_in_test/history/


> fix flapping empty_in_test dtest
> 
>
> Key: CASSANDRA-10471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10471
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
> Fix For: 3.0.0 rc2
>
>
> {{upgrade_tests/cql_tests.py:TestCQL.empty_in_test}} fails on the upgrade 
> path from 2.2 to 3.0
> http://cassci.datastax.com/view/Upgrades/job/storage_engine_upgrade_dtest-22_tarball-30_HEAD/42/testReport/upgrade_tests.cql_tests/TestCQL/empty_in_test/history/



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

[jira] [Created] (CASSANDRA-10474) Streaming should tolerate secondary index build failure

[Yuki Morishita (JIRA)]

Yuki Morishita created CASSANDRA-10474:
--

 Summary: Streaming should tolerate secondary index build failure
 Key: CASSANDRA-10474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10474
 Project: Cassandra
  Issue Type: Bug
Reporter: Yuki Morishita
 Fix For: 2.1.x, 2.2.x, 3.0.x


When streaming failed to build secondary index at the end of streaming (like in 
CASSANDRA-10449), streaming session can hang as it throws exception without 
catching it.

Streaming should tolerate secondary index build failure, and instead of failing 
(hanging) streaming session, it should WARN user and go on.



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

[jira] [Comment Edited] (CASSANDRA-10449) OOM on bootstrap due to long GC pause

[Yuki Morishita (JIRA)]

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

Yuki Morishita edited comment on CASSANDRA-10449 at 10/7/15 11:23 PM:
--

There are couples of things going on.

{code}
ERROR [StreamReceiveTask:29] 2015-10-05 14:46:17,090 CassandraDaemon.java:223 - 
Exception in thread Thread[StreamReceiveTask:29,5,main]
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: 
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
{code}

When rebuilding secondary index after receiving files, bootstrapping node is 
experiencing TombstoneOverwhelmingException.
This can make streaming to hang, as it never completes the receiving task.
Streaming should tolerate secondary index build failure, instead of failing 
entire stream session, it should just warn user and go on, so that user can 
manually trigger secondary index rebuild later.

I'm not sure the above relates to OOM. From StatusLogger, FlushWriter task is 
glowing and that is the cause of OOM.
If you can capture stack using jstack, that would be greate help.

-I create separate JIRA for the former.- Created CASSANDRA-10474.


was (Author: yukim):
There are couples of things going on.

{code}
ERROR [StreamReceiveTask:29] 2015-10-05 14:46:17,090 CassandraDaemon.java:223 - 
Exception in thread Thread[StreamReceiveTask:29,5,main]
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: 
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
{code}

When rebuilding secondary index after receiving files, bootstrapping node is 
experiencing TombstoneOverwhelmingException.
This can make streaming to hang, as it never completes the receiving task.
Streaming should tolerate secondary index build failure, instead of failing 
entire stream session, it should just warn user and go on, so that user can 
manually trigger secondary index rebuild later.

I'm not sure the above relates to OOM. From StatusLogger, FlushWriter task is 
glowing and that is the cause of OOM.
If you can capture stack using jstack, that would be greate help.

I create separate JIRA for the former.

> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
>  Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and 
> 500-700GB per node.  SSTable counts are <10 per table.  I am attempting to 
> provision additional nodes, but bootstrapping OOMs every time after about 10 
> hours with a sudden long GC pause:
> {noformat}
> INFO  [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old 
> Generation GC in 1586126ms.  G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to 
> no avail.



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

[jira] [Commented] (CASSANDRA-10421) Potential issue with LogTransaction as it only checks in a single directory for files

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10421:
--

[~aweisberg], [~benedict] : I've attached a 
[patch|https://github.com/stef1927/cassandra/commits/10421-windows-3.0] and it 
is ready for review. Don't be confused by the word _windows_ in the branch 
name, it's just so that we can have CI on Windows as well as on Linux.

We don't duplicate all records to all files, only the final commit or abort 
flag is written to all files. When we read the files on startup we collect all 
the sstable records from all existing txn files and check that the final flag 
record is the same in all files (but we do accept if some files are missing the 
last record and in this case we just warn). Therefore, if a file is lost we 
continue with the transaction processing but we do not touch the sstables in 
the folder of that file. Chances are either the entire disk was lost or the 
user deleted the file and in this case the user probably wanted to keep the 
sstables. Does this make sense?

When writing the final commit or abort record we throw _only if we fail to 
write to all files_. 

The abstraction names that I've chosen are {{LogFileSegment}} to represent an 
individual log file and {{LogFile}} to represent their ensemble. Feel free to 
suggest something else if you prefer, like {{LogFile}} and {{LogFile}}, I 
just could not come up with a suitable {{}} other than {{LogFiles}}, 
{{LogFileManager}}, {{LogFileEnsemble}}, none of which I really liked.

h5. CI Linux:

http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10421-windows-3.0-testall/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10421-windows-3.0-dtest/

h5. CI Windows:

http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10421-windows-3.0-utest_win32/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10421-windows-3.0-dtest_win32/

> Potential issue with LogTransaction as it only checks in a single directory 
> for files
> -
>
> Key: CASSANDRA-10421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10421
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Stefania
>Priority: Blocker
> Fix For: 3.0.0 rc2
>
>
> When creating a new LogTransaction we try to create the new logfile in the 
> same directory as the one we are writing to, but as we use 
> {{[directories.getDirectoryForNewSSTables()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogTransaction.java#L125]}}
>  this might end up in "any" of the configured data directories. If it does, 
> we will not be able to clean up leftovers as we check for files in the same 
> directory as the logfile was created: 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L163
> cc [~Stefania]



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

cassandra git commit: Cleanup whitespace for cqlsh PEP8 compliance

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 2084f3fb1 -> 22099adda


Cleanup whitespace for cqlsh PEP8 compliance

patch by philipthompson; reviewed by Stefania for CASSANDRA-10455


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

Branch: refs/heads/cassandra-3.0
Commit: 22099addaf6029656f8927ffb894c86c73bfaceb
Parents: 2084f3f
Author: Philip Thompson 
Authored: Tue Oct 6 15:30:26 2015 -0400
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:20:52 2015 +0200

--
 bin/cqlsh.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/22099add/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 46210da..56b709f 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -2554,9 +2554,10 @@ class SwitchCommand(object):
 print 'Disabled %s.' % (self.description,)
 return False
 
+
 class SwitchCommandWithValue(SwitchCommand):
 """The same as SwitchCommand except it also accepts a value in place of ON.
-
+
 This returns a tuple of the form: (SWITCH_VALUE, PASSED_VALUE)
 eg: PAGING 50 returns (True, 50)
 PAGING OFF returns (False, None)
@@ -2567,7 +2568,7 @@ class SwitchCommandWithValue(SwitchCommand):
 def __init__(self, command, desc, value_type=int):
 SwitchCommand.__init__(self, command, desc)
 self.value_type = value_type
-
+
 def execute(self, state, parsed, printerr):
 binary_switch_value = SwitchCommand.execute(self, state, parsed, 
printerr)
 switch = parsed.get_binding('switch')
@@ -2578,6 +2579,7 @@ class SwitchCommandWithValue(SwitchCommand):
 value = None
 return (binary_switch_value, value)
 
+
 def option_with_default(cparser_getter, section, option, default=None):
 try:
 return cparser_getter(section, option)

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[slebresne]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 07782aa4a525e251cb0f8ac6f6d27145066cf0ea
Parents: 587fe51 566799f
Author: Sylvain Lebresne 
Authored: Wed Oct 7 10:48:48 2015 +0200
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:48:48 2015 +0200

--
 NEWS.txt | 2 ++
 conf/cassandra.yaml  | 1 -
 src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 3 ++-
 test/conf/cassandra_pig.yaml | 2 +-
 4 files changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/07782aa4/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--

[jira] [Updated] (CASSANDRA-10437) Remove offheap_objects option until 9472 re-introduces them

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10437:
-
Labels: doc-impacting  (was: )

> Remove offheap_objects option until 9472 re-introduces them
> ---
>
> Key: CASSANDRA-10437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10437
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Trivial
>  Labels: doc-impacting
> Fix For: 3.0.0 rc2
>
> Attachments: 0001-Remove-offheap_objects-option.txt
>
>
> We need to send a meaningful error message if user try to use 
> {{offheap_objects}} in 3.0 since it's not supported currently (pending 
> CASSANDRA-9472). And document the current removal in the NEWS file.



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

cassandra git commit: Remove (unsupported) offheap_objects option

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 15334f40c -> 566799f56


Remove (unsupported) offheap_objects option

patch by slebresne; reviewed by aweisberg for CASSANDRA-10437

The 'objects offheap' allocator is currently not implemented for
Cassandra 3.0. The option will be re-introduced by CASSANDRA-9472
in a future release but in the meantime, the patch properly remove
the (now broken) option.


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

Branch: refs/heads/cassandra-3.0
Commit: 566799f567b319fdc62c94adfb8ffe4b96085649
Parents: 15334f4
Author: Sylvain Lebresne 
Authored: Wed Oct 7 10:45:40 2015 +0200
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:45:40 2015 +0200

--
 NEWS.txt | 2 ++
 conf/cassandra.yaml  | 1 -
 src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 3 ++-
 test/conf/cassandra_pig.yaml | 2 +-
 4 files changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index a7e56ec..18d61a3 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -44,6 +44,8 @@ New features
 
 Upgrading
 -
+   - The 'memtable_allocation_type: offheap_objects' option has been removed. 
It should
+ be re-introduced in a future release and you can follow CASSANDRA-9472 to 
know more.
- The LIMIT clause applies now only to the number of rows returned to the 
user,
  not to the number of row queried. By consequence, queries using 
aggregates will not
  be impacted by the LIMIT clause anymore.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 4fd249f..33ca4a8 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -403,7 +403,6 @@ concurrent_materialized_view_writes: 32
 # Options are:
 #   heap_buffers:on heap nio buffers
 #   offheap_buffers: off heap (direct) nio buffers
-#   offheap_objects: native memory, eliminating nio buffer heap overhead
 memtable_allocation_type: heap_buffers
 
 # Total space to use for commit logs on disk.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 7c062a1..ccc3dd1 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -1824,7 +1824,8 @@ public class DatabaseDescriptor
 }
 return new SlabPool(heapLimit, offHeapLimit, 
conf.memtable_cleanup_threshold, new 
ColumnFamilyStore.FlushLargestColumnFamily());
 case offheap_objects:
-return new NativePool(heapLimit, offHeapLimit, 
conf.memtable_cleanup_threshold, new 
ColumnFamilyStore.FlushLargestColumnFamily());
+throw new ConfigurationException("offheap_objects are not 
available in 3.0. They should be re-introduced in a future release, see 
https://issues.apache.org/jira/browse/CASSANDRA-9472 for details");
+// return new NativePool(heapLimit, offHeapLimit, 
conf.memtable_cleanup_threshold, new 
ColumnFamilyStore.FlushLargestColumnFamily());
 default:
 throw new AssertionError();
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/test/conf/cassandra_pig.yaml
--
diff --git a/test/conf/cassandra_pig.yaml b/test/conf/cassandra_pig.yaml
index 286434b..ce71410 100644
--- a/test/conf/cassandra_pig.yaml
+++ b/test/conf/cassandra_pig.yaml
@@ -3,7 +3,7 @@
 # Consider the effects on 'o.a.c.i.s.LegacySSTableTest' before changing 
schemas in this file.
 #
 cluster_name: Test Cluster
-memtable_allocation_type: offheap_objects
+memtable_allocation_type: heap_buffers
 commitlog_sync: batch
 commitlog_sync_batch_window_in_ms: 1.0
 commitlog_segment_size_in_mb: 5

[1/2] cassandra git commit: Remove (unsupported) offheap_objects option

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 587fe51b1 -> 07782aa4a


Remove (unsupported) offheap_objects option

patch by slebresne; reviewed by aweisberg for CASSANDRA-10437

The 'objects offheap' allocator is currently not implemented for
Cassandra 3.0. The option will be re-introduced by CASSANDRA-9472
in a future release but in the meantime, the patch properly remove
the (now broken) option.


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

Branch: refs/heads/trunk
Commit: 566799f567b319fdc62c94adfb8ffe4b96085649
Parents: 15334f4
Author: Sylvain Lebresne 
Authored: Wed Oct 7 10:45:40 2015 +0200
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:45:40 2015 +0200

--
 NEWS.txt | 2 ++
 conf/cassandra.yaml  | 1 -
 src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 3 ++-
 test/conf/cassandra_pig.yaml | 2 +-
 4 files changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index a7e56ec..18d61a3 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -44,6 +44,8 @@ New features
 
 Upgrading
 -
+   - The 'memtable_allocation_type: offheap_objects' option has been removed. 
It should
+ be re-introduced in a future release and you can follow CASSANDRA-9472 to 
know more.
- The LIMIT clause applies now only to the number of rows returned to the 
user,
  not to the number of row queried. By consequence, queries using 
aggregates will not
  be impacted by the LIMIT clause anymore.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 4fd249f..33ca4a8 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -403,7 +403,6 @@ concurrent_materialized_view_writes: 32
 # Options are:
 #   heap_buffers:on heap nio buffers
 #   offheap_buffers: off heap (direct) nio buffers
-#   offheap_objects: native memory, eliminating nio buffer heap overhead
 memtable_allocation_type: heap_buffers
 
 # Total space to use for commit logs on disk.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 7c062a1..ccc3dd1 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -1824,7 +1824,8 @@ public class DatabaseDescriptor
 }
 return new SlabPool(heapLimit, offHeapLimit, 
conf.memtable_cleanup_threshold, new 
ColumnFamilyStore.FlushLargestColumnFamily());
 case offheap_objects:
-return new NativePool(heapLimit, offHeapLimit, 
conf.memtable_cleanup_threshold, new 
ColumnFamilyStore.FlushLargestColumnFamily());
+throw new ConfigurationException("offheap_objects are not 
available in 3.0. They should be re-introduced in a future release, see 
https://issues.apache.org/jira/browse/CASSANDRA-9472 for details");
+// return new NativePool(heapLimit, offHeapLimit, 
conf.memtable_cleanup_threshold, new 
ColumnFamilyStore.FlushLargestColumnFamily());
 default:
 throw new AssertionError();
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/566799f5/test/conf/cassandra_pig.yaml
--
diff --git a/test/conf/cassandra_pig.yaml b/test/conf/cassandra_pig.yaml
index 286434b..ce71410 100644
--- a/test/conf/cassandra_pig.yaml
+++ b/test/conf/cassandra_pig.yaml
@@ -3,7 +3,7 @@
 # Consider the effects on 'o.a.c.i.s.LegacySSTableTest' before changing 
schemas in this file.
 #
 cluster_name: Test Cluster
-memtable_allocation_type: offheap_objects
+memtable_allocation_type: heap_buffers
 commitlog_sync: batch
 commitlog_sync_batch_window_in_ms: 1.0
 commitlog_segment_size_in_mb: 5

cassandra git commit: Re-populate token metadata after commit log recover

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 22099adda -> 15334f40c


Re-populate token metadata after commit log recover

patch by pauloricardomg; reviewed by carlyeks for CASSANDRA-10293


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

Branch: refs/heads/cassandra-3.0
Commit: 15334f40c6ff20dc6032bcfcd8c48e0c1ee5c955
Parents: 22099ad
Author: Paulo Motta 
Authored: Fri Sep 11 10:22:07 2015 -0300
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:41:10 2015 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 4 
 2 files changed, 5 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/15334f40/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5bf70ca..ba0012e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
  * Provide additional metrics for materialized views (CASSANDRA-10323)
  * Flush system schema tables after local schema changes (CASSANDRA-10429)
 Merged from 2.2:

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15334f40/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index f9ee9e8..d414a59 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -222,6 +222,7 @@ public class CassandraDaemon
  */
 LegacySchemaMigrator.migrate();
 
+// Populate token metadata before flushing, for token-aware sstable 
partitioning (#6696)
 StorageService.instance.populateTokenMetadata();
 
 // load schema from disk
@@ -285,6 +286,9 @@ public class CassandraDaemon
 throw new RuntimeException(e);
 }
 
+// Re-populate token metadata after commit log recover (new peers 
might be loaded onto system keyspace #10293)
+StorageService.instance.populateTokenMetadata();
+
 // migrate any legacy (pre-3.0) hints from system.hints table into the 
new store
 new LegacyHintsMigrator(DatabaseDescriptor.getHintsDirectory(), 
DatabaseDescriptor.getMaxHintsFileSize()).migrate();
 

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[slebresne]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: aebdef875b77b4f254b0808da1f63baef0342327
Parents: 9a27835 22099ad
Author: Sylvain Lebresne 
Authored: Wed Oct 7 10:26:55 2015 +0200
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:26:55 2015 +0200

--
 bin/cqlsh.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
--

[1/2] cassandra git commit: Cleanup whitespace for cqlsh PEP8 compliance

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 9a2783590 -> aebdef875


Cleanup whitespace for cqlsh PEP8 compliance

patch by philipthompson; reviewed by Stefania for CASSANDRA-10455


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

Branch: refs/heads/trunk
Commit: 22099addaf6029656f8927ffb894c86c73bfaceb
Parents: 2084f3f
Author: Philip Thompson 
Authored: Tue Oct 6 15:30:26 2015 -0400
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:20:52 2015 +0200

--
 bin/cqlsh.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/22099add/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 46210da..56b709f 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -2554,9 +2554,10 @@ class SwitchCommand(object):
 print 'Disabled %s.' % (self.description,)
 return False
 
+
 class SwitchCommandWithValue(SwitchCommand):
 """The same as SwitchCommand except it also accepts a value in place of ON.
-
+
 This returns a tuple of the form: (SWITCH_VALUE, PASSED_VALUE)
 eg: PAGING 50 returns (True, 50)
 PAGING OFF returns (False, None)
@@ -2567,7 +2568,7 @@ class SwitchCommandWithValue(SwitchCommand):
 def __init__(self, command, desc, value_type=int):
 SwitchCommand.__init__(self, command, desc)
 self.value_type = value_type
-
+
 def execute(self, state, parsed, printerr):
 binary_switch_value = SwitchCommand.execute(self, state, parsed, 
printerr)
 switch = parsed.get_binding('switch')
@@ -2578,6 +2579,7 @@ class SwitchCommandWithValue(SwitchCommand):
 value = None
 return (binary_switch_value, value)
 
+
 def option_with_default(cparser_getter, section, option, default=None):
 try:
 return cparser_getter(section, option)

[1/2] cassandra git commit: Re-populate token metadata after commit log recover

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 557bbbccb -> 587fe51b1


Re-populate token metadata after commit log recover

patch by pauloricardomg; reviewed by carlyeks for CASSANDRA-10293


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

Branch: refs/heads/trunk
Commit: 15334f40c6ff20dc6032bcfcd8c48e0c1ee5c955
Parents: 22099ad
Author: Paulo Motta 
Authored: Fri Sep 11 10:22:07 2015 -0300
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:41:10 2015 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 4 
 2 files changed, 5 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/15334f40/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5bf70ca..ba0012e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
  * Provide additional metrics for materialized views (CASSANDRA-10323)
  * Flush system schema tables after local schema changes (CASSANDRA-10429)
 Merged from 2.2:

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15334f40/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index f9ee9e8..d414a59 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -222,6 +222,7 @@ public class CassandraDaemon
  */
 LegacySchemaMigrator.migrate();
 
+// Populate token metadata before flushing, for token-aware sstable 
partitioning (#6696)
 StorageService.instance.populateTokenMetadata();
 
 // load schema from disk
@@ -285,6 +286,9 @@ public class CassandraDaemon
 throw new RuntimeException(e);
 }
 
+// Re-populate token metadata after commit log recover (new peers 
might be loaded onto system keyspace #10293)
+StorageService.instance.populateTokenMetadata();
+
 // migrate any legacy (pre-3.0) hints from system.hints table into the 
new store
 new LegacyHintsMigrator(DatabaseDescriptor.getHintsDirectory(), 
DatabaseDescriptor.getMaxHintsFileSize()).migrate();
 

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[slebresne]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 587fe51b1abb73ce0847d75dedd465a1214492a2
Parents: 557bbbc 15334f4
Author: Sylvain Lebresne 
Authored: Wed Oct 7 10:43:38 2015 +0200
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:43:38 2015 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 4 
 2 files changed, 5 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/587fe51b/CHANGES.txt
--
diff --cc CHANGES.txt
index 725da54,ba0012e..518d722
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 +3.2
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +
 +
  3.0
+  * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
   * Provide additional metrics for materialized views (CASSANDRA-10323)
   * Flush system schema tables after local schema changes (CASSANDRA-10429)
  Merged from 2.2:

http://git-wip-us.apache.org/repos/asf/cassandra/blob/587fe51b/src/java/org/apache/cassandra/service/CassandraDaemon.java
--

[jira] [Commented] (CASSANDRA-10378) Make skipping more efficient

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10378:
--

Thanks. Pushed an additional commit to the branch to address those.

bq. A static method for deciding if we have an extension byte would be nice

There was a {{isExtended()}} method already, though I added a 
{{readExtendedFlags}} that does the reading conditionally as that's probably 
cleaner. Or did I misunderstood what you meant?

> Make skipping more efficient
> 
>
> Key: CASSANDRA-10378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10378
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Benedict
>Assignee: Sylvain Lebresne
> Fix For: 3.0.0 rc2
>
>
> Following on from the impact of CASSANDRA-10322, we can improve the 
> efficiency of our calls to skipping methods. CASSANDRA-10326 is showing our 
> performance to be in-and-around the same ballpark except for seeks into the 
> middle of a large partition, which suggests (possibly) that the higher 
> density of data we're storing may simply be resulting in a more significant 
> CPU burden as we have more data to skip over (and since CASSANDRA-10322 
> improves performance here really dramatically, further improvements are 
> likely to be of similar benefit).
> I propose doing our best to flatten the skipping of macro data items into as 
> few skip invocations as necessary. One way of doing this would be to 
> introduce a special {{skipUnsignedVInts(int)}} method, that can efficiently 
> skip a number of unsigned vints. Almost the entire body of a cell and row 
> consist of vints now, each data component with their own special {{skipX}} 
> method that invokes {{readUnsignedVint}}. This would permit more efficient 
> despatch.
> We could also potentially avoid the construction of a new {{Columns}} 
> instance for each row skip, since all we need is an iterator over the 
> columns, and share the temporary space used for storing them, which should 
> further reduce the GC burden for skipping many rows.



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

[2/2] cassandra git commit: Abort in-progress queries that time out

[slebresne]

Abort in-progress queries that time out

patch by Stefania; reviewed by aweisberg for CASSANDRA-7392


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

Branch: refs/heads/trunk
Commit: 557bbbccb0eddc9f2ba6431b023b3ded253de056
Parents: aebdef8
Author: Stefania Alborghetti 
Authored: Fri Jul 3 15:16:15 2015 +0800
Committer: Sylvain Lebresne 
Committed: Wed Oct 7 10:28:37 2015 +0200

--
 CHANGES.txt |   1 +
 .../concurrent/ScheduledExecutors.java  |   5 +
 .../apache/cassandra/cql3/UntypedResultSet.java |   3 +-
 .../cql3/statements/ModificationStatement.java  |   6 +-
 .../cql3/statements/SelectStatement.java|  18 +-
 .../cassandra/db/PartitionRangeReadCommand.java |   2 +-
 .../org/apache/cassandra/db/ReadCommand.java|  73 +++-
 .../cassandra/db/ReadCommandVerbHandler.java|  13 +-
 .../cassandra/db/ReadExecutionController.java   | 132 +++
 .../org/apache/cassandra/db/ReadOrderGroup.java | 127 ---
 src/java/org/apache/cassandra/db/ReadQuery.java |  14 +-
 .../db/SinglePartitionNamesCommand.java |   2 +-
 .../db/SinglePartitionReadCommand.java  |  29 +-
 .../db/SinglePartitionSliceCommand.java |   2 +-
 src/java/org/apache/cassandra/db/Slices.java|   2 +-
 .../db/filter/ClusteringIndexNamesFilter.java   |   2 +-
 .../cassandra/db/filter/ColumnFilter.java   |   7 +-
 .../db/monitoring/ApproximateTime.java  |  61 
 .../db/monitoring/ConstructionTime.java |  41 +++
 .../cassandra/db/monitoring/Monitorable.java|  33 ++
 .../db/monitoring/MonitorableImpl.java  | 104 ++
 .../db/monitoring/MonitoringState.java  |  26 ++
 .../cassandra/db/monitoring/MonitoringTask.java | 264 ++
 src/java/org/apache/cassandra/db/view/View.java |   8 +-
 .../apache/cassandra/db/view/ViewBuilder.java   |   4 +-
 src/java/org/apache/cassandra/index/Index.java  |   2 +-
 .../index/internal/CassandraIndexSearcher.java  |  12 +-
 .../internal/composites/CompositesSearcher.java |   6 +-
 .../index/internal/keys/KeysSearcher.java   |   6 +-
 .../apache/cassandra/net/IAsyncCallback.java|   4 +-
 .../net/IAsyncCallbackWithFailure.java  |   2 +-
 .../org/apache/cassandra/net/IVerbHandler.java  |   4 +-
 .../cassandra/net/IncomingTcpConnection.java|  15 +-
 .../cassandra/net/MessageDeliveryTask.java  |  12 +-
 .../org/apache/cassandra/net/MessageIn.java |  55 ++-
 .../apache/cassandra/net/MessagingService.java  |   9 +-
 .../apache/cassandra/schema/SchemaKeyspace.java |  10 +-
 .../cassandra/serializers/ByteSerializer.java   |   2 +-
 .../apache/cassandra/service/ReadCallback.java  |   3 +-
 .../apache/cassandra/service/StorageProxy.java  |  30 +-
 .../service/pager/AbstractQueryPager.java   |   8 +-
 .../service/pager/MultiPartitionPager.java  |  16 +-
 .../cassandra/service/pager/QueryPager.java |  16 +-
 .../org/apache/cassandra/utils/FBUtilities.java |  12 +
 .../utils/NanoTimeToCurrentTimeMillis.java  |  48 +--
 test/conf/logback-test.xml  |   6 +-
 test/unit/org/apache/cassandra/Util.java|  24 +-
 .../org/apache/cassandra/db/KeyspaceTest.java   |   9 +-
 .../apache/cassandra/db/ReadCommandTest.java| 145 
 .../db/RepairedDataTombstonesTest.java  |   9 +-
 .../apache/cassandra/db/SecondaryIndexTest.java |   7 +-
 .../db/SinglePartitionSliceCommandTest.java |   8 +-
 .../db/monitoring/MonitoringTaskTest.java   | 341 +++
 .../org/apache/cassandra/hints/HintTest.java|   4 +-
 .../org/apache/cassandra/index/StubIndex.java   |   4 +-
 .../index/internal/CassandraIndexTest.java  |   4 +-
 .../cassandra/io/sstable/SSTableReaderTest.java |   5 +-
 .../cassandra/service/DataResolverTest.java |   3 +-
 .../cassandra/service/QueryPagerTest.java   |   3 +-
 .../utils/NanoTimeToCurrentTimeMillisTest.java  |   5 +-
 60 files changed, 1494 insertions(+), 334 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/557bbbcc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 95a940b..725da54 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.2
+ * Abort in-progress queries that time out (CASSANDRA-7392)
  * Add transparent data encryption core classes (CASSANDRA-9945)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/557bbbcc/src/java/org/apache/cassandra/concurrent/ScheduledExecutors.java

[1/2] cassandra git commit: Abort in-progress queries that time out

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/trunk aebdef875 -> 557bbbccb


http://git-wip-us.apache.org/repos/asf/cassandra/blob/557bbbcc/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java 
b/src/java/org/apache/cassandra/net/MessagingService.java
index 810d086..1ef35f4 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -789,7 +789,7 @@ public final class MessagingService implements 
MessagingServiceMBean
 }
 }
 
-public void receive(MessageIn message, int id, long timestamp, boolean 
isCrossNodeTimestamp)
+public void receive(MessageIn message, int id)
 {
 TraceState state = Tracing.instance.initializeFromMessage(message);
 if (state != null)
@@ -800,7 +800,7 @@ public final class MessagingService implements 
MessagingServiceMBean
 if (!ms.allowIncomingMessage(message, id))
 return;
 
-Runnable runnable = new MessageDeliveryTask(message, id, timestamp, 
isCrossNodeTimestamp);
+Runnable runnable = new MessageDeliveryTask(message, id);
 TracingAwareExecutorService stage = 
StageManager.getStage(message.getMessageType());
 assert stage != null : "No stage for message type " + message.verb;
 
@@ -937,6 +937,11 @@ public final class MessagingService implements 
MessagingServiceMBean
 incrementDroppedMessages(verb, false);
 }
 
+public void incrementDroppedMessages(MessageIn message)
+{
+incrementDroppedMessages(message.verb, 
message.constructionTime.isCrossNode);
+}
+
 public void incrementDroppedMessages(Verb verb, boolean isCrossNodeTimeout)
 {
 assert DROPPABLE_VERBS.contains(verb) : "Verb " + verb + " should not 
legally be dropped";

http://git-wip-us.apache.org/repos/asf/cassandra/blob/557bbbcc/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
--
diff --git a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java 
b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
index f0bdd14..8377ead 100644
--- a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
+++ b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
@@ -270,7 +270,8 @@ public final class SchemaKeyspace
 public static List readSchemaFromSystemTables()
 {
 ReadCommand cmd = getReadCommandForTableSchema(KEYSPACES);
-try (ReadOrderGroup orderGroup = cmd.startOrderGroup(); 
PartitionIterator schema = cmd.executeInternal(orderGroup))
+try (ReadExecutionController executionController = 
cmd.executionController();
+ PartitionIterator schema = 
cmd.executeInternal(executionController))
 {
 List keyspaces = new ArrayList<>();
 
@@ -326,8 +327,8 @@ public final class SchemaKeyspace
 for (String table : ALL)
 {
 ReadCommand cmd = getReadCommandForTableSchema(table);
-try (ReadOrderGroup orderGroup = cmd.startOrderGroup();
- PartitionIterator schema = cmd.executeInternal(orderGroup))
+try (ReadExecutionController executionController = 
cmd.executionController();
+ PartitionIterator schema = 
cmd.executeInternal(executionController))
 {
 while (schema.hasNext())
 {
@@ -374,7 +375,8 @@ public final class SchemaKeyspace
 private static void convertSchemaToMutations(Map 
mutationMap, String schemaTableName)
 {
 ReadCommand cmd = getReadCommandForTableSchema(schemaTableName);
-try (ReadOrderGroup orderGroup = cmd.startOrderGroup(); 
UnfilteredPartitionIterator iter = cmd.executeLocally(orderGroup))
+try (ReadExecutionController executionController = 
cmd.executionController();
+ UnfilteredPartitionIterator iter = 
cmd.executeLocally(executionController))
 {
 while (iter.hasNext())
 {

http://git-wip-us.apache.org/repos/asf/cassandra/blob/557bbbcc/src/java/org/apache/cassandra/serializers/ByteSerializer.java
--
diff --git a/src/java/org/apache/cassandra/serializers/ByteSerializer.java 
b/src/java/org/apache/cassandra/serializers/ByteSerializer.java
index 8c736cb..9d34fbc 100644
--- a/src/java/org/apache/cassandra/serializers/ByteSerializer.java
+++ b/src/java/org/apache/cassandra/serializers/ByteSerializer.java
@@ -28,7 +28,7 @@ public class ByteSerializer implements TypeSerializer
 
 public Byte deserialize(ByteBuffer bytes)
 {
-return bytes.remaining() == 0 ? null : bytes.get(bytes.position());
+return bytes == null || bytes.remaining() == 0 ? null : 
bytes.get(bytes.position());
 }
 
 public ByteBuffer 

[jira] [Commented] (CASSANDRA-10415) Fix cqlsh bugs

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10415:
--

I confirmed with a bisect that the first two tests were broken by 
CASSANDRA-9232 but I don't know why yet.

> Fix cqlsh bugs
> --
>
> Key: CASSANDRA-10415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10415
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.0.0 rc2
>
>
> This is followup to CASSANDRA-10289
> The tests currently failing should be:
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_columnfamily}}
> ** uses {{create_columnfamily_table_template}}. Stefania says "the {{(}} 
> after {{CREATE ... IF}} does not look valid to me."
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_table}}
> ** uses {{create_columnfamily_table_template}}, see above.
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_delete}}
> ** Stefania says: "I don't think keyspaces are a valid completion after 
> {{DELETE a [}} and after {{DELETE FROM twenty_rows_composite_table USING 
> TIMESTAMP 0 WHERE TOKEN(a) >=}}. From a quick analysis of {{cqlhandling.py}} 
> I think it comes from {{}}, which picks up {{}}, which 
> was changed to include {{ks.}} by CASSANDRA-7556.
> * 
> {{cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_drop_keyspace}}
> ** Stefania says: "the {{;}} after {{DROP KEYSPACE IF}} is not valid.
> * {{cqlshlib.test.test_cqlsh_output.TestCqlshOutput.test_timestamp_output}}
> ** already documented with CASSANDRA-10313 and CASSANDRA-10397
> I'm happy to break these out into separate tickets if necessary. 
> To run the tests locally, I cd to {{cassandra/pylib/cqlshlib}} and run the 
> following:
> {code}
> ccm create -n 1 --install-dir=../.. test
> ccm start --wait-for-binary-proto
> nosetests test 2>&1
> ccm remove
> {code}
> This requires nose and ccm. Until CASSANDRA-10289 is resolved, you'll have to 
> use my branch here: https://github.com/mambocab/cassandra/tree/fix-cqlsh-tests
> Tests for this branch are run (non-continuously) here:
> http://cassci.datastax.com/job/scratch_mambocab-fix_cqlsh/
> Assigning [~Stefania] for now, since she's already looked at 10289, but feel 
> free to reassign.



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

[jira] [Updated] (CASSANDRA-10406) Nodetool supports to rebuild from specific ranges.

[Dikang Gu (JIRA)]

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

Dikang Gu updated CASSANDRA-10406:
--
Attachment: (was: rebuildranges-2.1.patch)

> Nodetool supports to rebuild from specific ranges.
> --
>
> Key: CASSANDRA-10406
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10406
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-10406.patch, rebuildranges-2.1.patch
>
>
> Add the 'nodetool rebuildrange' command, so that if `nodetool rebuild` 
> failed, we do not need to rebuild all the ranges, and can just rebuild those 
> failed ones.
> Should be easily ported to all versions.



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

[jira] [Updated] (CASSANDRA-10406) Nodetool supports to rebuild from specific ranges.

[Dikang Gu (JIRA)]

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

Dikang Gu updated CASSANDRA-10406:
--
Attachment: rebuildranges-2.1.patch

> Nodetool supports to rebuild from specific ranges.
> --
>
> Key: CASSANDRA-10406
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10406
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-10406.patch, rebuildranges-2.1.patch
>
>
> Add the 'nodetool rebuildrange' command, so that if `nodetool rebuild` 
> failed, we do not need to rebuild all the ranges, and can just rebuild those 
> failed ones.
> Should be easily ported to all versions.



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

[jira] [Commented] (CASSANDRA-10406) Nodetool supports to rebuild from specific ranges.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-10406:
---

[~yukim], thanks for the review! updated the patch. Can you please take a look 
again? Thanks!

> Nodetool supports to rebuild from specific ranges.
> --
>
> Key: CASSANDRA-10406
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10406
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-10406.patch, rebuildranges-2.1.patch
>
>
> Add the 'nodetool rebuildrange' command, so that if `nodetool rebuild` 
> failed, we do not need to rebuild all the ranges, and can just rebuild those 
> failed ones.
> Should be easily ported to all versions.



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

[jira] [Updated] (CASSANDRA-10233) IndexOutOfBoundsException in HintedHandOffManager

[J.P. Eiti Kimura (JIRA)]

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

J.P. Eiti Kimura updated CASSANDRA-10233:
-
Attachment: cassandra-2.2.1-10233-v2.txt
cassandra-2.0-10233.txt
cassandra-2.1-10233-v5.txt

[~pauloricardomg] nice! 
I changed the files as you suggested and I just added one more patch for 2.0 
version as well. The new files attached are:
cassandra-2.1-10233-v5.txt
cassandra-2.0-10233.txt
cassandra-2.2.1-10233-v2.txt

> IndexOutOfBoundsException in HintedHandOffManager
> -
>
> Key: CASSANDRA-10233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10233
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.0
>Reporter: Omri Iluz
>Assignee: J.P. Eiti Kimura
> Attachments: cassandra-2.0-10233.txt, cassandra-2.1-10233-v5.txt, 
> cassandra-2.1.8-10233-v3.txt, cassandra-2.1.8-10233-v4.txt, 
> cassandra-2.2.1-10233-v2.txt, cassandra-2.2.1-10233.txt
>
>
> After upgrading our cluster to 2.2.0, the following error started showing 
> exectly every 10 minutes on every server in the cluster:
> {noformat}
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,506 
> CompactionTask.java:142 - Compacting (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-540-big-Data.db:level=0,
>  ]
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,599 
> CompactionTask.java:224 - Compacted (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 1 
> sstables to 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-541-big,] 
> to level=0.  1,544,495 bytes to 1,544,495 (~100% of original) in 93ms = 
> 15.838121MB/s.  0 total partitions merged to 4.  Partition merge counts were 
> {1:4, }
> ERROR [HintedHandoff:1] 2015-08-31 18:31:55,600 CassandraDaemon.java:182 - 
> Exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.IndexOutOfBoundsException: null
>   at java.nio.Buffer.checkIndex(Buffer.java:538) ~[na:1.7.0_79]
>   at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:410) 
> ~[na:1.7.0_79]
>   at org.apache.cassandra.utils.UUIDGen.getUUID(UUIDGen.java:106) 
> ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:515)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:88)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:168)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_79]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_79]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {noformat}



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

[jira] [Updated] (CASSANDRA-10461) Fix sstableverify_test dtest

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-10461:
-
Labels: test  (was: )

> Fix sstableverify_test dtest
> 
>
> Key: CASSANDRA-10461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10461
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Stefania
>  Labels: test
> Fix For: 3.0.0 rc2
>
>
> The dtest for sstableverify is failing:
> http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/
> It fails in the same way when I run it on OpenStack, so I don't think it's 
> just a CassCI problem.
> [~slebresne] Looks like you made changes to this test recently:
> https://github.com/riptano/cassandra-dtest/commit/51ab085f21e01cc8e5ad88a277cb4a43abd3f880
> Could you have a look at the failure? I'm assigning you for triage, but feel 
> free to reassign.



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

[jira] [Commented] (CASSANDRA-10461) Fix sstableverify_test dtest

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10461:
--

We never created a pull request for the dtest changes required by the second 
installment of CASSANDRA-7066 where {{sstablelister}} was renamed to 
{{sstableutil}}. The tests were never 'unrequired' so we never noticed. I've 
rebased the original patch and created a pull request 
[here|https://github.com/riptano/cassandra-dtest/pull/589].

> Fix sstableverify_test dtest
> 
>
> Key: CASSANDRA-10461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10461
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Stefania
>  Labels: test
> Fix For: 3.0.0 rc2
>
>
> The dtest for sstableverify is failing:
> http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/
> It fails in the same way when I run it on OpenStack, so I don't think it's 
> just a CassCI problem.
> [~slebresne] Looks like you made changes to this test recently:
> https://github.com/riptano/cassandra-dtest/commit/51ab085f21e01cc8e5ad88a277cb4a43abd3f880
> Could you have a look at the failure? I'm assigning you for triage, but feel 
> free to reassign.



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

[jira] [Commented] (CASSANDRA-10421) Potential issue with LogTransaction as it only checks in a single directory for files

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10421:
--

bq. Is there an advantage to writing only the commit record to all the files? 
Seems conceptually easier for them to all be the same log and since it is low 
traffic there is no performance motivation. Was there a discussion somewhere 
else where it seemed like people might delete the file? Are we really ok with 
losing atomicity if they don't lose the whole disk?

There was a brief discussion on IRC between [~krummas] and [~benedict] but the 
conclusion wasn't clear to me. Here is why so far I chose not to replicate the 
entire content:

* when we add a new log file lazily, we need to duplicate the content of other 
existing files (not a problem but something extra to do and that can go wrong)
* every time we write an sstable record we risk not being able to write this 
record to a file when we've already succeeded writing to another file, at the 
moment this is necessary only for the last record and on startup we can handle 
missing file records in some files, so long as they don't conflict
* a record could become quite long due to a long relative path (it shouldn't 
matter other than for readability of the txn file)
* at startup we then have the problem of reconciling sstable records not just 
the final ones and handle the case of missing sstable files that according to 
the txn should be there (if a disk is removed or files deleted)

I didn't want to tackle all this until I was sure it is necessary, conceptually 
it seemed cleaner to have each txn file only handle its own local sstable files 
but if there are true safety issues with this (Benedict seemed to think so on 
IRC) then I am happy to change it.

bq. Can you just have it do nothing if it is called multiple times?. Maybe save 
a headache down the road.

{{readRecords}} used to be called independently, now it's only called from 
{{verify}} so I guess the assertion could go. Currently we should not attempt 
to read a file twice so I don't see why silently doing nothing is better than 
raising an assertion.

bq. Why is this check not necessary anymore?

I've changed {{record.isValid()}}, called just above. I could not hit that code 
during unit tests even with invalid records and it occurred to me that it was 
because error message and record type are both set all the time.

bq. Not part of your current work, but relying on modified time for files seems 
suspect to me, file contents should have the modified time so copying and other 
operations don't change it

There was a very long discussion about this on CASSANDRA-7066; it starts more 
or less with the last paragraph of [this 
comment|https://issues.apache.org/jira/browse/CASSANDRA-7066?focusedCommentId=14645754=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14645754].
 We delete files from oldest to newest and the update time is the maximum 
update time so it should always match with that's on disk. The reason is that 
we don't want to delete files by mistake, as in users coping files from backup 
without removing a partial txn log that happened to have obsoleted the very 
same files. There is a comment in {{deleteRecord()}} but it doesn't seem 
complete so we should probably add more comments about this.


> Potential issue with LogTransaction as it only checks in a single directory 
> for files
> -
>
> Key: CASSANDRA-10421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10421
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Stefania
>Priority: Blocker
> Fix For: 3.0.0 rc2
>
>
> When creating a new LogTransaction we try to create the new logfile in the 
> same directory as the one we are writing to, but as we use 
> {{[directories.getDirectoryForNewSSTables()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogTransaction.java#L125]}}
>  this might end up in "any" of the configured data directories. If it does, 
> we will not be able to clean up leftovers as we check for files in the same 
> directory as the logfile was created: 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L163
> cc [~Stefania]



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

[jira] [Commented] (CASSANDRA-10205) decommissioned_wiped_node_can_join_test fails on Jenkins

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10205:
--

Thank you! I've rebased and created a [pull 
request|https://github.com/riptano/cassandra-dtest/pull/588] for the dtests. 
Waiting for a committer.

> decommissioned_wiped_node_can_join_test fails on Jenkins
> 
>
> Key: CASSANDRA-10205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10205
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.0 rc2
>
> Attachments: decommissioned_wiped_node_can_join_test.tar.gz
>
>
> This test passes locally but reliably fails on Jenkins. It seems after we 
> restart node4, it is unable to Gossip with other nodes:
> {code}
> INFO  [HANDSHAKE-/127.0.0.2] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.2
> INFO  [HANDSHAKE-/127.0.0.1] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.1
> INFO  [HANDSHAKE-/127.0.0.3] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.3
> ERROR [main] 2015-08-27 06:51:13,785 CassandraDaemon.java:635 - Exception 
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at 
> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1342) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:518)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:763)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:320) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [main/:na]
> WARN  [StorageServiceShutdownHook] 2015-08-27 06:51:13,799 Gossiper.java:1453 
> - No local state or state is in silent shutdown, not announcing shutdown
> {code}
> It seems both the addresses and port number of the seeds are correct so I 
> don't think the problem is the Amazon private addresses but I might be wrong. 
> It's also worth noting that the first time the node starts up without 
> problems. The problem only occurs during a restart.



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

[jira] [Commented] (CASSANDRA-10205) decommissioned_wiped_node_can_join_test fails on Jenkins

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10205:
--

The C* patch should be applied to 2.1 and 2.2 as well so I've attached the 
corresponding branches. 

CI will eventually be available here:

http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10205-3.0-modified-dtest
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10205-3.0-dtest
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10205-3.0-testall
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10205-2.2-dtest
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10205-2.2-testall
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10205-2.1-dtest
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10205-2.1-testall

> decommissioned_wiped_node_can_join_test fails on Jenkins
> 
>
> Key: CASSANDRA-10205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10205
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.0 rc2
>
> Attachments: decommissioned_wiped_node_can_join_test.tar.gz
>
>
> This test passes locally but reliably fails on Jenkins. It seems after we 
> restart node4, it is unable to Gossip with other nodes:
> {code}
> INFO  [HANDSHAKE-/127.0.0.2] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.2
> INFO  [HANDSHAKE-/127.0.0.1] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.1
> INFO  [HANDSHAKE-/127.0.0.3] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.3
> ERROR [main] 2015-08-27 06:51:13,785 CassandraDaemon.java:635 - Exception 
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at 
> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1342) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:518)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:763)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:320) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [main/:na]
> WARN  [StorageServiceShutdownHook] 2015-08-27 06:51:13,799 Gossiper.java:1453 
> - No local state or state is in silent shutdown, not announcing shutdown
> {code}
> It seems both the addresses and port number of the seeds are correct so I 
> don't think the problem is the Amazon private addresses but I might be wrong. 
> It's also worth noting that the first time the node starts up without 
> problems. The problem only occurs during a restart.



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

[jira] [Updated] (CASSANDRA-10467) QoS for Queries

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-10467:
---
Fix Version/s: 3.x

> QoS for Queries
> ---
>
> Key: CASSANDRA-10467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10467
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Benjamin Coverston
> Fix For: 3.x
>
>
> Background: As an OLTP system that is based on pipelined execution worker 
> pools can be saturated with long(er) running calls. When the system is under 
> stress, those long running calls can make requests that should be short lived 
> requests take a much longer period of time.
> Introduce the concept of QoS into Cassandra for client queries. A few ideas:
> 1. Allow clients to specify a QoS to be sent to Cassandra from the driver as 
> part of the protocol.
> 2. Allow different requests to be tagged based on some simple criteria 
> (perhaps configured) (i.e. ALLOW FILTERING was part of the query)
> 3. QOS based on the LUN that is accessed (SSDs get higher QOS than the RAID5)



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

[jira] [Commented] (CASSANDRA-10461) Fix sstableverify_test dtest

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10461:
--

[~mambocab] I've assigned you as reviewer since the patch is exclusively for 
dtest code.

> Fix sstableverify_test dtest
> 
>
> Key: CASSANDRA-10461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10461
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Stefania
>  Labels: test
> Fix For: 3.0.0 rc2
>
>
> The dtest for sstableverify is failing:
> http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/
> It fails in the same way when I run it on OpenStack, so I don't think it's 
> just a CassCI problem.
> [~slebresne] Looks like you made changes to this test recently:
> https://github.com/riptano/cassandra-dtest/commit/51ab085f21e01cc8e5ad88a277cb4a43abd3f880
> Could you have a look at the failure? I'm assigning you for triage, but feel 
> free to reassign.



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

[jira] [Updated] (CASSANDRA-10205) decommissioned_wiped_node_can_join_test fails on Jenkins

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-10205:
-
Fix Version/s: 2.2.x
   2.1.x

> decommissioned_wiped_node_can_join_test fails on Jenkins
> 
>
> Key: CASSANDRA-10205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10205
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.0 rc2
>
> Attachments: decommissioned_wiped_node_can_join_test.tar.gz
>
>
> This test passes locally but reliably fails on Jenkins. It seems after we 
> restart node4, it is unable to Gossip with other nodes:
> {code}
> INFO  [HANDSHAKE-/127.0.0.2] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.2
> INFO  [HANDSHAKE-/127.0.0.1] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.1
> INFO  [HANDSHAKE-/127.0.0.3] 2015-08-27 06:50:42,778 
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.3
> ERROR [main] 2015-08-27 06:51:13,785 CassandraDaemon.java:635 - Exception 
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at 
> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1342) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:518)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:763)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:320) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [main/:na]
> WARN  [StorageServiceShutdownHook] 2015-08-27 06:51:13,799 Gossiper.java:1453 
> - No local state or state is in silent shutdown, not announcing shutdown
> {code}
> It seems both the addresses and port number of the seeds are correct so I 
> don't think the problem is the Amazon private addresses but I might be wrong. 
> It's also worth noting that the first time the node starts up without 
> problems. The problem only occurs during a restart.



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

[jira] [Commented] (CASSANDRA-10420) Cassandra server should throw meaningfull exception when thrift_framed_transport_size_in_mb reached

[Yuan Yao (JIRA)]

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

Yuan Yao commented on CASSANDRA-10420:
--

We're using version 2.0.10. 

Thanks

> Cassandra server should throw meaningfull exception when 
> thrift_framed_transport_size_in_mb reached
> ---
>
> Key: CASSANDRA-10420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10420
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Yuan Yao
>
> In cassandra's configuration, we set "thrift_framed_transport_size_in_mb" as 
> 15
> When send data large than some threshold max value, java.net.SocketException: 
> Connection reset will be thrown out from server. This exception doesn't 
> deliver meaningful message. Client side can't detect what's wrong with the 
> request
> Please throw out meaningful exception in this case to client.



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

[jira] [Updated] (CASSANDRA-10233) IndexOutOfBoundsException in HintedHandOffManager

[J.P. Eiti Kimura (JIRA)]

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

J.P. Eiti Kimura updated CASSANDRA-10233:
-
Attachment: (was: cassandra-2.1.8-10233-v2.txt)

> IndexOutOfBoundsException in HintedHandOffManager
> -
>
> Key: CASSANDRA-10233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10233
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.0
>Reporter: Omri Iluz
>Assignee: J.P. Eiti Kimura
> Attachments: cassandra-2.1.8-10233-v3.txt, 
> cassandra-2.1.8-10233-v4.txt, cassandra-2.2.1-10233.txt
>
>
> After upgrading our cluster to 2.2.0, the following error started showing 
> exectly every 10 minutes on every server in the cluster:
> {noformat}
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,506 
> CompactionTask.java:142 - Compacting (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-540-big-Data.db:level=0,
>  ]
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,599 
> CompactionTask.java:224 - Compacted (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 1 
> sstables to 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-541-big,] 
> to level=0.  1,544,495 bytes to 1,544,495 (~100% of original) in 93ms = 
> 15.838121MB/s.  0 total partitions merged to 4.  Partition merge counts were 
> {1:4, }
> ERROR [HintedHandoff:1] 2015-08-31 18:31:55,600 CassandraDaemon.java:182 - 
> Exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.IndexOutOfBoundsException: null
>   at java.nio.Buffer.checkIndex(Buffer.java:538) ~[na:1.7.0_79]
>   at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:410) 
> ~[na:1.7.0_79]
>   at org.apache.cassandra.utils.UUIDGen.getUUID(UUIDGen.java:106) 
> ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:515)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:88)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:168)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_79]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_79]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {noformat}



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

[jira] [Commented] (CASSANDRA-10443) CQLSStableWriter example fails on 3.0rc1

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-10443:
-

iirc, that change was to fix some utest failures. If removing it doesn't 
introduce any new failures, it should be ok.

> CQLSStableWriter example fails on 3.0rc1
> 
>
> Key: CASSANDRA-10443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10443
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, Tools
>Reporter: Jonathan Shook
>Assignee: Carl Yeksigian
> Fix For: 3.0.0 rc2
>
>
> CQLSSTableWriter which works with 2.2.1 does not work with 3.0rc1.
> Something like https://github.com/yukim/cassandra-bulkload-example should be 
> added to the test suite.
> Exception in thread "main" java.lang.RuntimeException: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter.close(SSTableSimpleUnsortedWriter.java:136)
>   at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.close(CQLSSTableWriter.java:274)
>   at com.metawiring.sandbox.BulkLoadExample.main(BulkLoadExample.java:160)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: java.lang.ExceptionInInitializerError
>   at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:372)
>   at org.apache.cassandra.db.Keyspace.(Keyspace.java:309)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:133)
>   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:110)
>   at 
> org.apache.cassandra.io.sstable.SSTableTxnWriter.create(SSTableTxnWriter.java:97)
>   at 
> org.apache.cassandra.io.sstable.AbstractSSTableSimpleWriter.createWriter(AbstractSSTableSimpleWriter.java:63)
>   at 
> org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:206)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1153)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:116)
>   ... 7 more



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

[jira] [Commented] (CASSANDRA-10233) IndexOutOfBoundsException in HintedHandOffManager

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10233:
-

[~eitikimura] thanks for your patch, I think we can keep the ttl > 0 assertion 
instead of the explicit check, since we won't run into problems if ttl <= 0 
(even though that's not the case), so the assertion should suffice. Also, in 
the 2.1 patch there are some extra lines in the imports, could you please 
remove them? Sorry for not pointing that out before.

After that it should be ready to commit!! :)

> IndexOutOfBoundsException in HintedHandOffManager
> -
>
> Key: CASSANDRA-10233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10233
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.0
>Reporter: Omri Iluz
>Assignee: J.P. Eiti Kimura
> Attachments: cassandra-2.1.8-10233-v2.txt, 
> cassandra-2.1.8-10233-v3.txt, cassandra-2.1.8-10233-v4.txt, 
> cassandra-2.2.1-10233.txt
>
>
> After upgrading our cluster to 2.2.0, the following error started showing 
> exectly every 10 minutes on every server in the cluster:
> {noformat}
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,506 
> CompactionTask.java:142 - Compacting (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-540-big-Data.db:level=0,
>  ]
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,599 
> CompactionTask.java:224 - Compacted (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 1 
> sstables to 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-541-big,] 
> to level=0.  1,544,495 bytes to 1,544,495 (~100% of original) in 93ms = 
> 15.838121MB/s.  0 total partitions merged to 4.  Partition merge counts were 
> {1:4, }
> ERROR [HintedHandoff:1] 2015-08-31 18:31:55,600 CassandraDaemon.java:182 - 
> Exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.IndexOutOfBoundsException: null
>   at java.nio.Buffer.checkIndex(Buffer.java:538) ~[na:1.7.0_79]
>   at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:410) 
> ~[na:1.7.0_79]
>   at org.apache.cassandra.utils.UUIDGen.getUUID(UUIDGen.java:106) 
> ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:515)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:88)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:168)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_79]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_79]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {noformat}



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

[jira] [Updated] (CASSANDRA-10464) "nodetool compactionhistory" output should be sorted on compacted_at column and the timestamp shown in human readable format

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-10464:

Fix Version/s: 3.x

> "nodetool compactionhistory" output should be sorted on compacted_at column 
> and the timestamp shown in human readable format
> 
>
> Key: CASSANDRA-10464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10464
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Wei Deng
>Priority: Minor
> Fix For: 3.x
>
>
> "nodetool compactionhistory" (introduced in CASSANDRA-5078) is a useful tool 
> for Cassandra DBAs. However, the current output limits its usefulness without 
> some additional parsing.
> We should improve it in the following two areas:
> 1. The output should be sorted on the compacted_at column, so that the most 
> recently finished compaction will show up last (which is what the DBAs would 
> expect);
> 2. The compacted_at column should be printed in human-readable timestamp.



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

[jira] [Commented] (CASSANDRA-10242) Validate rack information on startup

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10242:
-

+1, thanks! Marking as "Ready to Commit".

> Validate rack information on startup
> 
>
> Key: CASSANDRA-10242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10242
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> Moving to a new rack means that different data should be stored on a node.  
> We already persist rack information in a system table; we should fail startup 
> if this doesn't match what the snitch thinks it should be.  (Either the 
> snitch is wrong, and needs to be fixed, or the machine has been moved and 
> needs to be rebootstrapped.)



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

[jira] [Updated] (CASSANDRA-10466) json2sstable import failing

[Brandon Williams (JIRA)]

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

Brandon Williams updated CASSANDRA-10466:
-
Description: 
In CASSANDRA-7477 we fixed part of this, but it's still possible to have a 
variant of this problem:

{noformat}
Importing 1 keys...
java.lang.ClassCastException: 
org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
org.apache.cassandra.db.composites.CellName
at 
org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
at 
org.apache.cassandra.tools.SSTableImport$JsonColumn.(SSTableImport.java:145)
at 
org.apache.cassandra.tools.SSTableImport.addColumnsToCF(SSTableImport.java:213)
at 
org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:327)
at 
org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:287)
at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:514)
ERROR: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
org.apache.cassandra.db.composites.CellName
{noformat}

I can provide the schema and json file offline if needed.

  was:
In CASANDRA-7477 we fixed part of this, but it's still possible to have a 
variant of this problem:

{noformat}
Importing 1 keys...
java.lang.ClassCastException: 
org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
org.apache.cassandra.db.composites.CellName
at 
org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
at 
org.apache.cassandra.tools.SSTableImport$JsonColumn.(SSTableImport.java:145)
at 
org.apache.cassandra.tools.SSTableImport.addColumnsToCF(SSTableImport.java:213)
at 
org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:327)
at 
org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:287)
at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:514)
ERROR: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
org.apache.cassandra.db.composites.CellName
{noformat}

I can provide the schema and json file offline if needed.


> json2sstable import failing
> ---
>
> Key: CASSANDRA-10466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10466
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
> Fix For: 2.1.x
>
>
> In CASSANDRA-7477 we fixed part of this, but it's still possible to have a 
> variant of this problem:
> {noformat}
> Importing 1 keys...
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
> at 
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
> at 
> org.apache.cassandra.tools.SSTableImport$JsonColumn.(SSTableImport.java:145)
> at 
> org.apache.cassandra.tools.SSTableImport.addColumnsToCF(SSTableImport.java:213)
> at 
> org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:327)
> at 
> org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:287)
> at 
> org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:514)
> ERROR: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
> {noformat}
> I can provide the schema and json file offline if needed.



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

[jira] [Updated] (CASSANDRA-10242) Validate rack information on startup

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-10242:

Fix Version/s: (was: 2.1.x)
   2.1.11
   2.2.3
   3.0.0 rc2

> Validate rack information on startup
> 
>
> Key: CASSANDRA-10242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10242
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Carl Yeksigian
> Fix For: 3.0.0 rc2, 2.2.3, 2.1.11
>
>
> Moving to a new rack means that different data should be stored on a node.  
> We already persist rack information in a system table; we should fail startup 
> if this doesn't match what the snitch thinks it should be.  (Either the 
> snitch is wrong, and needs to be fixed, or the machine has been moved and 
> needs to be rebootstrapped.)



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

cassandra git commit: In mutateMV, if not yet gossiping, write all mutations to batchlog

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 e77730179 -> 6c3fa8e30


In mutateMV, if not yet gossiping, write all mutations to batchlog

Patch by Joel Knighton; reviewed by tjake for CASSANDRA-10413


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

Branch: refs/heads/cassandra-3.0
Commit: 6c3fa8e30de21aecce35032762470bfa0fb3cb5e
Parents: e777301
Author: Joel Knighton 
Authored: Wed Sep 30 04:50:19 2015 +
Committer: T Jake Luciani 
Committed: Wed Oct 7 15:46:56 2015 -0400

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/db/view/ViewUtils.java |  2 +-
 .../apache/cassandra/service/StorageProxy.java  | 91 +++-
 3 files changed, 52 insertions(+), 42 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3fa8e3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ba0012e..0bac64e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * If node is not yet gossiping write all MV updates to batchlog only 
(CASSANDRA-10413)
  * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
  * Provide additional metrics for materialized views (CASSANDRA-10323)
  * Flush system schema tables after local schema changes (CASSANDRA-10429)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3fa8e3/src/java/org/apache/cassandra/db/view/ViewUtils.java
--
diff --git a/src/java/org/apache/cassandra/db/view/ViewUtils.java 
b/src/java/org/apache/cassandra/db/view/ViewUtils.java
index 628142d..ebbae65 100644
--- a/src/java/org/apache/cassandra/db/view/ViewUtils.java
+++ b/src/java/org/apache/cassandra/db/view/ViewUtils.java
@@ -94,7 +94,7 @@ public final class ViewUtils
 
 if 
(StorageService.instance.getTokenMetadata().pendingEndpointsFor(viewToken, 
keyspaceName).size() > 0)
 {
-//Since there are pending endpoints we are going to store 
hints this in the batchlog regardless.
+//Since there are pending endpoints we are going to write to 
the batchlog regardless.
 //So we can pretend we are the views endpoint.
 
 return FBUtilities.getBroadcastAddress();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3fa8e3/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java 
b/src/java/org/apache/cassandra/service/StorageProxy.java
index d1142fc..f210951 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -660,55 +660,64 @@ public class StorageProxy implements StorageProxyMBean
 final String localDataCenter = 
DatabaseDescriptor.getEndpointSnitch().getDatacenter(FBUtilities.getBroadcastAddress());
 
 long startTime = System.nanoTime();
-List wrappers = new 
ArrayList<>(mutations.size());
+
 
 try
 {
-Token baseToken = 
StorageService.instance.getTokenMetadata().partitioner.getToken(dataKey);
-
-ConsistencyLevel consistencyLevel = ConsistencyLevel.ONE;
-
-//Since the base -> view replication is 1:1 we only need to store 
the BL locally
-final Collection batchlogEndpoints = 
Collections.singleton(FBUtilities.getBroadcastAddress());
+// if we haven't joined the ring, write everything to batchlog 
because paired replicas may be stale
 final UUID batchUUID = UUIDGen.getTimeUUID();
-BatchlogResponseHandler.BatchlogCleanup cleanup = new 
BatchlogResponseHandler.BatchlogCleanup(mutations.size(),
-   
   () -> asyncRemoveFromBatchlog(batchlogEndpoints, 
batchUUID));
 
-// add a handler for each mutation - includes checking 
availability, but doesn't initiate any writes, yet
-for (Mutation mutation : mutations)
+if (!Gossiper.instance.isEnabled())
+{
+BatchlogManager.store(Batch.createLocal(batchUUID, 
FBUtilities.timestampMicros(),
+mutations),
+  writeCommitLog);
+}
+else
 {
-String keyspaceName = mutation.getKeyspaceName();
-Token 

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[jake]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: dc6f5bdb0aa530b705873dca42a7c59bf95c96d6
Parents: 127f7c5 6c3fa8e
Author: T Jake Luciani 
Authored: Wed Oct 7 15:48:05 2015 -0400
Committer: T Jake Luciani 
Committed: Wed Oct 7 15:48:05 2015 -0400

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/db/view/ViewUtils.java |  2 +-
 .../apache/cassandra/service/StorageProxy.java  | 91 +++-
 3 files changed, 52 insertions(+), 42 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/dc6f5bdb/CHANGES.txt
--
diff --cc CHANGES.txt
index 518d722,0bac64e..16958a1
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 +3.2
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +
 +
  3.0
+  * If node is not yet gossiping write all MV updates to batchlog only 
(CASSANDRA-10413)
   * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
   * Provide additional metrics for materialized views (CASSANDRA-10323)
   * Flush system schema tables after local schema changes (CASSANDRA-10429)

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

[1/2] cassandra git commit: In mutateMV, if not yet gossiping, write all mutations to batchlog

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 127f7c584 -> dc6f5bdb0


In mutateMV, if not yet gossiping, write all mutations to batchlog

Patch by Joel Knighton; reviewed by tjake for CASSANDRA-10413


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

Branch: refs/heads/trunk
Commit: 6c3fa8e30de21aecce35032762470bfa0fb3cb5e
Parents: e777301
Author: Joel Knighton 
Authored: Wed Sep 30 04:50:19 2015 +
Committer: T Jake Luciani 
Committed: Wed Oct 7 15:46:56 2015 -0400

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/db/view/ViewUtils.java |  2 +-
 .../apache/cassandra/service/StorageProxy.java  | 91 +++-
 3 files changed, 52 insertions(+), 42 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3fa8e3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ba0012e..0bac64e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0
+ * If node is not yet gossiping write all MV updates to batchlog only 
(CASSANDRA-10413)
  * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
  * Provide additional metrics for materialized views (CASSANDRA-10323)
  * Flush system schema tables after local schema changes (CASSANDRA-10429)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3fa8e3/src/java/org/apache/cassandra/db/view/ViewUtils.java
--
diff --git a/src/java/org/apache/cassandra/db/view/ViewUtils.java 
b/src/java/org/apache/cassandra/db/view/ViewUtils.java
index 628142d..ebbae65 100644
--- a/src/java/org/apache/cassandra/db/view/ViewUtils.java
+++ b/src/java/org/apache/cassandra/db/view/ViewUtils.java
@@ -94,7 +94,7 @@ public final class ViewUtils
 
 if 
(StorageService.instance.getTokenMetadata().pendingEndpointsFor(viewToken, 
keyspaceName).size() > 0)
 {
-//Since there are pending endpoints we are going to store 
hints this in the batchlog regardless.
+//Since there are pending endpoints we are going to write to 
the batchlog regardless.
 //So we can pretend we are the views endpoint.
 
 return FBUtilities.getBroadcastAddress();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c3fa8e3/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java 
b/src/java/org/apache/cassandra/service/StorageProxy.java
index d1142fc..f210951 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -660,55 +660,64 @@ public class StorageProxy implements StorageProxyMBean
 final String localDataCenter = 
DatabaseDescriptor.getEndpointSnitch().getDatacenter(FBUtilities.getBroadcastAddress());
 
 long startTime = System.nanoTime();
-List wrappers = new 
ArrayList<>(mutations.size());
+
 
 try
 {
-Token baseToken = 
StorageService.instance.getTokenMetadata().partitioner.getToken(dataKey);
-
-ConsistencyLevel consistencyLevel = ConsistencyLevel.ONE;
-
-//Since the base -> view replication is 1:1 we only need to store 
the BL locally
-final Collection batchlogEndpoints = 
Collections.singleton(FBUtilities.getBroadcastAddress());
+// if we haven't joined the ring, write everything to batchlog 
because paired replicas may be stale
 final UUID batchUUID = UUIDGen.getTimeUUID();
-BatchlogResponseHandler.BatchlogCleanup cleanup = new 
BatchlogResponseHandler.BatchlogCleanup(mutations.size(),
-   
   () -> asyncRemoveFromBatchlog(batchlogEndpoints, 
batchUUID));
 
-// add a handler for each mutation - includes checking 
availability, but doesn't initiate any writes, yet
-for (Mutation mutation : mutations)
+if (!Gossiper.instance.isEnabled())
+{
+BatchlogManager.store(Batch.createLocal(batchUUID, 
FBUtilities.timestampMicros(),
+mutations),
+  writeCommitLog);
+}
+else
 {
-String keyspaceName = mutation.getKeyspaceName();
-Token tk = 

[jira] [Resolved] (CASSANDRA-10413) Replaying materialized view updates from commitlog after node decommission crashes Cassandra

[T Jake Luciani (JIRA)]

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

T Jake Luciani resolved CASSANDRA-10413.

Resolution: Fixed

Committed thanks!

> Replaying materialized view updates from commitlog after node decommission 
> crashes Cassandra
> 
>
> Key: CASSANDRA-10413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10413
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Critical
> Fix For: 3.0.0 rc2
>
> Attachments: n1.log, n2.log, n3.log, n4.log, n5.log
>
>
> This issue is reproducible through a Jepsen test, runnable as
> {code}
> lein with-profile +trunk test :only 
> cassandra.mv-test/mv-crash-subset-decommission
> {code}
> This test crashes/restarts nodes while decommissioning nodes. These actions 
> are not coordinated.
> In [10164|https://issues.apache.org/jira/browse/CASSANDRA-10164], we 
> introduced a change to re-apply materialized view updates on commitlog replay.
> Some nodes, upon restart, will crash in commitlog replay. They throw the 
> "Trying to get the view natural endpoint on a non-data replica" runtime 
> exception in getViewNaturalEndpoint. I added logging to 
> getViewNaturalEndpoint to show the results of 
> replicationStrategy.getNaturalEndpoints for the baseToken and viewToken.
> It can be seen that these problems occur when the baseEndpoints and 
> viewEndpoints are identical but do not contain the broadcast address of the 
> local node.
> For example, a node at 10.0.0.5 crashes on replay of a write whose base token 
> and view token replicas are both [10.0.0.2, 10.0.0.4, 10.0.0.6]. It seems we 
> try to guard against this by considering pendingEndpoints for the viewToken, 
> but this does not appear to be sufficient.
> I've attached the system.logs for a test run with added logging. In the 
> attached logs, n1 is at 10.0.0.2, n2 is at 10.0.0.3, and so on. 10.0.0.6/n5 
> is the decommissioned node.



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

[jira] [Commented] (CASSANDRA-10438) Overwrites of rows in memtable produce incorrect deltas for indexing

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-10438:


OK, so the downstream stuff isn't particularly sensitive to what the liveness 
info already was set to in past releases? I am just trying to understand how 
this is going to impact the contract between the manager and the downstream 
index implementations. I suppose the prior answer was wrong and we will have to 
fix anything that comes up downstream. I don't know how many implementations 
there are out in the wild that might be impacted.

When I looked at it it seemed like the only thing it is used for is to get the 
TTL for primary key indexes, and in that case it was for the new row only. That 
was of course the one case where it was already setting it modulo the bug. 

3.0-testall timed out during the build so I ran it again.

Otherwise +1.



> Overwrites of rows in memtable produce incorrect deltas for indexing
> 
>
> Key: CASSANDRA-10438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10438
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0 rc2
>
>
> When a row in the memtable is updated, the delta is supplied to any 
> registered indexer. This consists of two {{Row}} objects, representing the 
> old and new data in the memtable. As per its javadoc, the contract of 
> {{Index.Indexer::updateRow}} is that these old & new rows contain only the 
> changed columns, so any column which was not affected by the update will 
> appear in neither the new nor old row. The {{RowDiffListener::onCell}} method 
> in {{SecondaryIndexManager.WriteTimeTransaction::onUpdated}} which produces 
> these deltas uses a reference equality check, where it should be checking 
> object equality. This results in unchanged, prexisting cells appearing in the 
> {{toInsert}} row.



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

[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-9602:
---

The [2.2 
docs|http://docs.datastax.com/en/cassandra/2.2/cassandra/dml/dmlConfigConsistency.html?scroll=dmlConfigConsistency__dml-config-read-consistency]
 state that {{EACH_QUORUM}} is not supported for reads; the writes section 
still references it.

Caching doesn't make sense for dcEndpoints; the endpoints are going to be 
different for each token that we get and it has to include only the live 
tokens, so there isn't much benefit to caching these values.

For selecting the endpoints, this code follows the same way we do things for 
all of our other consistency levels, so that behavior is the same as we'd 
expect from, for example, running a {{LOCAL_QUORUM}} in each DC.

I have added a 
[dtest|https://github.com/carlyeks/cassandra-dtest/tree/each_quorum_read] to 
the consistency_test.py.


> EACH_QUORUM READ support needed
> ---
>
> Key: CASSANDRA-9602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9602
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Scott Guminy
>Assignee: Carl Yeksigian
>  Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> EACH_QUORUM consistency for READ should be added.
> This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not 
> needed ever, however I have a use case where I need it.  I think the decision 
> made was incorrect. Here's why...
>  
>  My application has two key pieces:
>  
>  # *End user actions* which add/modify data in the system.  End users 
> typically access the application from only one Data Center and only see their 
> own data
> # *Scheduled business logic tasks* which run from any node in any data 
> center.  These tasks process data added by the end users in an asynchronous 
> way
>  
>  *End user actions must have the highest degree of availability.*  Users must 
> always be able to add data to the system.  The data will be processed later.  
> To support this, end user actions will use *LOCAL_QUORUM Read and Write 
> Consistency*.
>  
>  Scheduled tasks don't need to have a high degree of availability but MUST 
> operate on the most up to date data.  *The tasks will run with EACH_QUORUM* 
> to ensure that no matter how many data centers we have, we always READ the 
> latest data.  This approach allows us some amount of fault tolerance. 
>  
>  The problem is that EACH_QUORUM is not a valid READ consistency level.  This 
> mean I have no alternative but to use ALL.  ALL will work, but is not the 
> best since it offers support for ZERO failures.  I would prefer EACH_QUORUM 
> since it can support some failures in each data center.



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

[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap due to long GC pause

[Robbie Strickland (JIRA)]

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

Robbie Strickland commented on CASSANDRA-10449:
---

I increased max heap to 96GB and tried again.  Now doing netstats shows 
progress ground to a halt:

9pm:

{noformat}
ubuntu@eventcass4x024:~$ nodetool netstats | grep -v 100%
Mode: JOINING
Bootstrap 45d8dec0-6c12-11e5-90ef-f7a8e02e59c0
/52.1.155.147 (using /10.239.209.15)
Receiving 139 files, 36548040412 bytes total. Already received 139 
files, 36548040412 bytes total
/52.2.9.34 (using /10.239.209.17)
Receiving 171 files, 6431853 bytes total. Already received 171 
files, 6431853 bytes total
/52.0.152.88 (using /10.239.209.44)
Receiving 147 files, 78458709168 bytes total. Already received 79 
files, 55003961646 bytes total

/var/lib/cassandra/xvdd/data/prod_analytics_events/wuevents-ffa99ad05af911e596f05987bbaaffad/prod_analytics_events-wuevents-tmp-ka-295-Data.db
 955162267/4105438496 bytes(23%) received from idx:0/52.0.152.88
/52.2.0.164 (using /10.239.209.16)
Receiving 141 files, 36700837768 bytes total. Already received 141 
files, 36700837768 bytes total
/54.152.177.161 (using /10.239.209.93)
/54.172.174.48 (using /10.239.209.49)
Receiving 176 files, 79676288976 bytes total. Already received 98 
files, 55932809644 bytes total

/var/lib/cassandra/xvdb/data/prod_analytics_events/wuevents-ffa99ad05af911e596f05987bbaaffad/prod_analytics_events-wuevents-tmp-ka-329-Data.db
 174070078/7326235809 bytes(2%) received from idx:0/54.172.174.48
/52.2.75.82 (using /10.239.208.88)
/54.165.111.69 (using /10.239.209.47)
Receiving 170 files, 85920995638 bytes total. Already received 94 
files, 54985226700 bytes total

/var/lib/cassandra/xvdd/data/prod_analytics_events/wuevents-ffa99ad05af911e596f05987bbaaffad/prod_analytics_events-wuevents-tmp-ka-265-Data.db
 4875660361/22821083384 bytes(21%) received from idx:0/54.165.111.69
/52.6.136.30 (using /10.239.209.45)
Receiving 174 files, 87064163973 bytes total. Already received 91 
files, 53930233899 bytes total

/var/lib/cassandra/xvdb/data/prod_analytics_events/wuevents-ffa99ad05af911e596f05987bbaaffad/prod_analytics_events-wuevents-tmp-ka-157-Data.db
 17064156850/25823860172 bytes(66%) received from idx:0/52.6.136.30
/52.7.14.201 (using /10.239.209.46)
Receiving 164 files, 46351636573 bytes total. Already received 164 
files, 46351636573 bytes total
/52.2.30.66 (using /10.239.209.18)
Receiving 158 files, 62899520151 bytes total. Already received 158 
files, 62899520151 bytes total
/54.175.138.33 (using /10.239.209.96)
/54.88.44.178 (using /10.239.209.91)
/52.2.109.194 (using /10.239.208.89)
/54.172.81.117 (using /10.239.209.95)
/54.172.103.46 (using /10.239.209.48)
Receiving 164 files, 48771232182 bytes total. Already received 164 
files, 48771232182 bytes total
/54.164.172.164 (using /10.239.209.94)
Read Repair Statistics:
Attempted: 0
Mismatch (Blocking): 0
Mismatch (Background): 0
Pool NameActive   Pending  Completed
Commandsn/a19 56
Responses   n/a 0   35515795
{noformat}

6am:

{noformat}
ubuntu@eventcass4x024:~$ nodetool netstats | grep -v 100%
Mode: JOINING
Bootstrap 45d8dec0-6c12-11e5-90ef-f7a8e02e59c0
/52.1.155.147 (using /10.239.209.15)
Receiving 139 files, 36548040412 bytes total. Already received 139 
files, 36548040412 bytes total
/52.2.9.34 (using /10.239.209.17)
Receiving 171 files, 6431853 bytes total. Already received 171 
files, 6431853 bytes total
/52.0.152.88 (using /10.239.209.44)
Receiving 147 files, 78458709168 bytes total. Already received 79 
files, 55003961646 bytes total

/var/lib/cassandra/xvdd/data/prod_analytics_events/wuevents-ffa99ad05af911e596f05987bbaaffad/prod_analytics_events-wuevents-tmp-ka-295-Data.db
 955162267/4105438496 bytes(23%) received from idx:0/52.0.152.88
/52.2.0.164 (using /10.239.209.16)
Receiving 141 files, 36700837768 bytes total. Already received 141 
files, 36700837768 bytes total
/54.152.177.161 (using /10.239.209.93)
/54.172.174.48 (using /10.239.209.49)
Receiving 176 files, 79676288976 bytes total. Already received 98 
files, 55932809644 bytes total

/var/lib/cassandra/xvdb/data/prod_analytics_events/wuevents-ffa99ad05af911e596f05987bbaaffad/prod_analytics_events-wuevents-tmp-ka-329-Data.db
 174070078/7326235809 bytes(2%) received from idx:0/54.172.174.48
/52.2.75.82 (using /10.239.208.88)
/54.165.111.69 (using /10.239.209.47)
Receiving 170 files, 85920995638 bytes total. Already received 94 
files, 54985226700 bytes total

[jira] [Commented] (CASSANDRA-10438) Overwrites of rows in memtable produce incorrect deltas for indexing

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-10438:
-

Thanks [~aweisberg]. You're right, the change involving 
{{onPrimaryKeyLivenessInfo}} wasn't covered because it was an afterthought 
really. When I went back to it prompted by your comment, I realised that the 
right thing to do was to always have the delta rows take their liveness info 
direct from the incoming existing/updated row data. 

Unlike cell data, a row always has to have some liveness info (even if that's 
empty) so it seemed logical to set these unconditionally rather than only doing 
it when there was a mismatch. Also, in the prior code, only {{toInsert}} was 
having its liveness set when there was a mismatch. In that case {{toRemove}} 
was defaulting to {{LivenessInfo.EMPTY}}, which was more confusing IMO. So I've 
pushed an additional commit which fixes that and also adds a condition to the 
unit test. 


> Overwrites of rows in memtable produce incorrect deltas for indexing
> 
>
> Key: CASSANDRA-10438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10438
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0 rc2
>
>
> When a row in the memtable is updated, the delta is supplied to any 
> registered indexer. This consists of two {{Row}} objects, representing the 
> old and new data in the memtable. As per its javadoc, the contract of 
> {{Index.Indexer::updateRow}} is that these old & new rows contain only the 
> changed columns, so any column which was not affected by the update will 
> appear in neither the new nor old row. The {{RowDiffListener::onCell}} method 
> in {{SecondaryIndexManager.WriteTimeTransaction::onUpdated}} which produces 
> these deltas uses a reference equality check, where it should be checking 
> object equality. This results in unchanged, prexisting cells appearing in the 
> {{toInsert}} row.



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

cassandra git commit: Update cassandra.yaml allocate_tokens_for_keyspace to match the actual config variable

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 566799f56 -> 36d0f55d4


Update cassandra.yaml allocate_tokens_for_keyspace to match the actual config 
variable


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

Branch: refs/heads/cassandra-3.0
Commit: 36d0f55d46ac0edb5a4f140c7993c6d207605fe7
Parents: 566799f
Author: Marcus Eriksson 
Authored: Wed Oct 7 13:57:13 2015 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 7 13:57:13 2015 +0200

--
 conf/cassandra.yaml  | 2 +-
 src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 4 ++--
 src/java/org/apache/cassandra/dht/BootStrapper.java  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/36d0f55d/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 33ca4a8..19ebf8a 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -33,7 +33,7 @@ num_tokens: 256
 # vnodes.
 #
 # Only supported with the Murmur3Partitioner.
-# allocate_tokens_keyspace: KEYSPACE
+# allocate_tokens_for_keyspace: KEYSPACE
 
 # initial_token allows you to specify tokens manually.  While you can use # it 
with
 # vnodes (num_tokens > 1, above) -- in which case you should provide a 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/36d0f55d/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index ccc3dd1..a43fe4e 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -912,9 +912,9 @@ public class DatabaseDescriptor
 return tokensFromString(System.getProperty("cassandra.initial_token", 
conf.initial_token));
 }
 
-public static String getAllocateTokensKeyspace()
+public static String getAllocateTokensForKeyspace()
 {
-return System.getProperty("cassandra.allocate_tokens_keyspace", 
conf.allocate_tokens_for_keyspace);
+return System.getProperty("cassandra.allocate_tokens_for_keyspace", 
conf.allocate_tokens_for_keyspace);
 }
 
 public static Collection tokensFromString(String tokenString)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/36d0f55d/src/java/org/apache/cassandra/dht/BootStrapper.java
--
diff --git a/src/java/org/apache/cassandra/dht/BootStrapper.java 
b/src/java/org/apache/cassandra/dht/BootStrapper.java
index c0f0402..8d8f5c7 100644
--- a/src/java/org/apache/cassandra/dht/BootStrapper.java
+++ b/src/java/org/apache/cassandra/dht/BootStrapper.java
@@ -156,7 +156,7 @@ public class BootStrapper extends 
ProgressEventNotifierSupport
  */
 public static Collection getBootstrapTokens(final TokenMetadata 
metadata, InetAddress address) throws ConfigurationException
 {
-String allocationKeyspace = 
DatabaseDescriptor.getAllocateTokensKeyspace();
+String allocationKeyspace = 
DatabaseDescriptor.getAllocateTokensForKeyspace();
 Collection initialTokens = 
DatabaseDescriptor.getInitialTokens();
 if (initialTokens.size() > 0 && allocationKeyspace != null)
 logger.warn("manually specified tokens override automatic 
allocation");

[1/2] cassandra git commit: Update cassandra.yaml allocate_tokens_for_keyspace to match the actual config variable

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 07782aa4a -> c2bc39f28


Update cassandra.yaml allocate_tokens_for_keyspace to match the actual config 
variable


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

Branch: refs/heads/trunk
Commit: 36d0f55d46ac0edb5a4f140c7993c6d207605fe7
Parents: 566799f
Author: Marcus Eriksson 
Authored: Wed Oct 7 13:57:13 2015 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 7 13:57:13 2015 +0200

--
 conf/cassandra.yaml  | 2 +-
 src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 4 ++--
 src/java/org/apache/cassandra/dht/BootStrapper.java  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/36d0f55d/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 33ca4a8..19ebf8a 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -33,7 +33,7 @@ num_tokens: 256
 # vnodes.
 #
 # Only supported with the Murmur3Partitioner.
-# allocate_tokens_keyspace: KEYSPACE
+# allocate_tokens_for_keyspace: KEYSPACE
 
 # initial_token allows you to specify tokens manually.  While you can use # it 
with
 # vnodes (num_tokens > 1, above) -- in which case you should provide a 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/36d0f55d/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index ccc3dd1..a43fe4e 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -912,9 +912,9 @@ public class DatabaseDescriptor
 return tokensFromString(System.getProperty("cassandra.initial_token", 
conf.initial_token));
 }
 
-public static String getAllocateTokensKeyspace()
+public static String getAllocateTokensForKeyspace()
 {
-return System.getProperty("cassandra.allocate_tokens_keyspace", 
conf.allocate_tokens_for_keyspace);
+return System.getProperty("cassandra.allocate_tokens_for_keyspace", 
conf.allocate_tokens_for_keyspace);
 }
 
 public static Collection tokensFromString(String tokenString)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/36d0f55d/src/java/org/apache/cassandra/dht/BootStrapper.java
--
diff --git a/src/java/org/apache/cassandra/dht/BootStrapper.java 
b/src/java/org/apache/cassandra/dht/BootStrapper.java
index c0f0402..8d8f5c7 100644
--- a/src/java/org/apache/cassandra/dht/BootStrapper.java
+++ b/src/java/org/apache/cassandra/dht/BootStrapper.java
@@ -156,7 +156,7 @@ public class BootStrapper extends 
ProgressEventNotifierSupport
  */
 public static Collection getBootstrapTokens(final TokenMetadata 
metadata, InetAddress address) throws ConfigurationException
 {
-String allocationKeyspace = 
DatabaseDescriptor.getAllocateTokensKeyspace();
+String allocationKeyspace = 
DatabaseDescriptor.getAllocateTokensForKeyspace();
 Collection initialTokens = 
DatabaseDescriptor.getInitialTokens();
 if (initialTokens.size() > 0 && allocationKeyspace != null)
 logger.warn("manually specified tokens override automatic 
allocation");

[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[marcuse]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: c2bc39f289794b6803fa8c89c91da857a37436bd
Parents: 07782aa 36d0f55
Author: Marcus Eriksson 
Authored: Wed Oct 7 13:57:28 2015 +0200
Committer: Marcus Eriksson 
Committed: Wed Oct 7 13:57:28 2015 +0200

--
 conf/cassandra.yaml  | 2 +-
 src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 4 ++--
 src/java/org/apache/cassandra/dht/BootStrapper.java  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c2bc39f2/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--

[jira] [Commented] (CASSANDRA-10461) Fix sstableverify_test dtest

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10461:
--

bq.  Looks like you made changes to this test recently

Yes, but those changes are pretty surely not related to that failure since the 
test fails before any of the change made by that recent commit.

>From the test failure, it seems the test doesn't found one of the sstable in 
>the output of {{sstableverify}}. However, I suspect that this may be a test 
>problem. The dtest looks the sstable that
it expects to be verified by checking the data directory. In doing so, it needs 
to excluding any temporary file, since those wouldn't be verified by 
{{sstableverify}}. In pre-3.0, excluding temporary files was as easy as 
grepping {{tmp}} in the filename, but it doesn't work in 3.0 anymore (due to 
CASSANDRA-7066 I believe). The test supposedly account for that by using a 
so-called {{sstablelister}} tool, that is supposed to be in 3.0, but as far as 
I can tell this doesn't exist and I can confirm the test does use the old 
"check for tmp in the filename" path that is bogus for 3.0.

So I think the test first needs to be updated to properly handle {{tmp}} files 
following CASSANDRA-7066 and assigned [~Stefania] since she should know better 
about anything CASSANDRA-7066.

I'll note lastly that the test actually doesn't fail for me locally so I'm only 
conjecturing that the {{tmp}} problem above is the actual problem of the test. 
In any case, there is definitively something fishing about the test trying to 
use a non existing {{sstablelister}} tool.

> Fix sstableverify_test dtest
> 
>
> Key: CASSANDRA-10461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10461
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Sylvain Lebresne
> Fix For: 3.0.0 rc2
>
>
> The dtest for sstableverify is failing:
> http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/
> It fails in the same way when I run it on OpenStack, so I don't think it's 
> just a CassCI problem.
> [~slebresne] Looks like you made changes to this test recently:
> https://github.com/riptano/cassandra-dtest/commit/51ab085f21e01cc8e5ad88a277cb4a43abd3f880
> Could you have a look at the failure? I'm assigning you for triage, but feel 
> free to reassign.



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

[jira] [Updated] (CASSANDRA-10461) Fix sstableverify_test dtest

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10461:
-
Assignee: Stefania  (was: Sylvain Lebresne)

> Fix sstableverify_test dtest
> 
>
> Key: CASSANDRA-10461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10461
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Stefania
> Fix For: 3.0.0 rc2
>
>
> The dtest for sstableverify is failing:
> http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/
> It fails in the same way when I run it on OpenStack, so I don't think it's 
> just a CassCI problem.
> [~slebresne] Looks like you made changes to this test recently:
> https://github.com/riptano/cassandra-dtest/commit/51ab085f21e01cc8e5ad88a277cb4a43abd3f880
> Could you have a look at the failure? I'm assigning you for triage, but feel 
> free to reassign.



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

[jira] [Commented] (CASSANDRA-9142) DC Local repair or -hosts should only be allowed with -full repair

[Akihiko Kawaguchi (JIRA)]

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

Akihiko Kawaguchi commented on CASSANDRA-9142:
--

Hi,

bq. Fix Version/s: 2.2.1, 3.0 beta 2

Regardless of this, can you please let me know why there is no description 
about this ticket in CHANGES.txt for Cassandra 2.2.1?


> DC Local repair or -hosts should only be allowed with -full repair
> --
>
> Key: CASSANDRA-9142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9142
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: sankalp kohli
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 2.2.1, 3.0 beta 2
>
> Attachments: trunk_9142.txt
>
>
> We should not let users mix incremental repair with dc local repair or -host 
> or any repair which does not include all replicas. 
> This will currently cause stables on some replicas to be marked as repaired. 
> The next incremental repair will not work on same set of data.



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

[jira] [Commented] (CASSANDRA-10385) Fix eclipse-warning report

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-10385:


I reran the dtests and they cleared up. Thanks for the comments on why you 
added resource annotations.

Could you rebase this to the current 3.0 branch?

+1 I'll commit once once we get a rebased test run in


> Fix eclipse-warning report
> --
>
> Key: CASSANDRA-10385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10385
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: T Jake Luciani
>Assignee: Branimir Lambov
>Priority: Trivial
> Fix For: 3.0.0 rc2
>
>
> http://cassci.datastax.com/job/cassandra-3.0_eclipse-warnings/



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

[jira] [Commented] (CASSANDRA-10233) IndexOutOfBoundsException in HintedHandOffManager

[Kenneth Failbus (JIRA)]

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

Kenneth Failbus commented on CASSANDRA-10233:
-

Folks,

I am seeing the same exception in 2.0.14 release. Any plans to apply the patch 
in that release. What is the work-around?

> IndexOutOfBoundsException in HintedHandOffManager
> -
>
> Key: CASSANDRA-10233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10233
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.0
>Reporter: Omri Iluz
>Assignee: J.P. Eiti Kimura
> Attachments: cassandra-2.1.8-10233-v2.txt, 
> cassandra-2.1.8-10233-v3.txt, cassandra-2.1.8-10233-v4.txt, 
> cassandra-2.2.1-10233.txt
>
>
> After upgrading our cluster to 2.2.0, the following error started showing 
> exectly every 10 minutes on every server in the cluster:
> {noformat}
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,506 
> CompactionTask.java:142 - Compacting (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-540-big-Data.db:level=0,
>  ]
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,599 
> CompactionTask.java:224 - Compacted (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 1 
> sstables to 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-541-big,] 
> to level=0.  1,544,495 bytes to 1,544,495 (~100% of original) in 93ms = 
> 15.838121MB/s.  0 total partitions merged to 4.  Partition merge counts were 
> {1:4, }
> ERROR [HintedHandoff:1] 2015-08-31 18:31:55,600 CassandraDaemon.java:182 - 
> Exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.IndexOutOfBoundsException: null
>   at java.nio.Buffer.checkIndex(Buffer.java:538) ~[na:1.7.0_79]
>   at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:410) 
> ~[na:1.7.0_79]
>   at org.apache.cassandra.utils.UUIDGen.getUUID(UUIDGen.java:106) 
> ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:515)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:88)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:168)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_79]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_79]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {noformat}



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

[1/2] cassandra git commit: Update python driver to 2.7.2

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 1c073e70e -> be89dae3e


Update python driver to 2.7.2

Patch by carl; reviewed by tjake for CASSANDRA-10161


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

Branch: refs/heads/cassandra-2.2
Commit: 1b08cbd817dea379ea84175381d3ef151fe65681
Parents: 78f2e7a
Author: Carl Yeksigian 
Authored: Wed Sep 30 11:13:20 2015 -0400
Committer: T Jake Luciani 
Committed: Wed Oct 7 10:11:26 2015 -0400

--
 CHANGES.txt   |   3 +++
 ...assandra-driver-internal-only-2.6.0c2.post.zip | Bin 198346 -> 0 bytes
 lib/cassandra-driver-internal-only-2.7.2.zip  | Bin 0 -> 229600 bytes
 3 files changed, 3 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eec8161..d678efe 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+2.1.11
+ * Update internal python driver used by cqlsh (CASSANDRA-10161)
+
 2.1.10
  * Bulk Loader API could not tolerate even node failure (CASSANDRA-10347)
  * Avoid misleading pushed notifications when multiple nodes

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/lib/cassandra-driver-internal-only-2.6.0c2.post.zip
--
diff --git a/lib/cassandra-driver-internal-only-2.6.0c2.post.zip 
b/lib/cassandra-driver-internal-only-2.6.0c2.post.zip
deleted file mode 100644
index 5fa57c7..000
Binary files a/lib/cassandra-driver-internal-only-2.6.0c2.post.zip and 
/dev/null differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/lib/cassandra-driver-internal-only-2.7.2.zip
--
diff --git a/lib/cassandra-driver-internal-only-2.7.2.zip 
b/lib/cassandra-driver-internal-only-2.7.2.zip
new file mode 100644
index 000..f2e75f1
Binary files /dev/null and b/lib/cassandra-driver-internal-only-2.7.2.zip differ

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

[jake]

Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
CHANGES.txt


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

Branch: refs/heads/cassandra-2.2
Commit: be89dae3ecfd98b2170732c45d7f95807d5c19af
Parents: 1c073e7 1b08cbd
Author: T Jake Luciani 
Authored: Wed Oct 7 10:13:40 2015 -0400
Committer: T Jake Luciani 
Committed: Wed Oct 7 10:13:40 2015 -0400

--
 CHANGES.txt   |   3 ++-
 ...assandra-driver-internal-only-2.6.0c2.post.zip | Bin 198346 -> 0 bytes
 lib/cassandra-driver-internal-only-2.7.2.zip  | Bin 0 -> 229600 bytes
 3 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/be89dae3/CHANGES.txt
--
diff --cc CHANGES.txt
index 47fa4c2,d678efe..82ee94d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,20 -1,7 +1,21 @@@
 -2.1.11
 +2.2.3
 + * Make Hadoop CF splits more polite to custom orderered partitioners 
(CASSANDRA-10400)
- 
++Merged from 2.1:
+  * Update internal python driver used by cqlsh (CASSANDRA-10161)
  
 -2.1.10
 +2.2.2
 + * cqlsh prompt includes name of keyspace after failed `use` statement 
(CASSANDRA-10369)
 + * Configurable page size in cqlsh (CASSANDRA-9855)
 + * Defer default role manager setup until all nodes are on 2.2+ 
(CASSANDRA-9761)
 + * Cancel transaction for sstables we wont redistribute index summary
 +   for (CASSANDRA-10270)
 + * Handle missing RoleManager in config after upgrade to 2.2 
(CASSANDRA-10209) 
 + * Retry snapshot deletion after compaction and gc on Windows 
(CASSANDRA-10222)
 + * Fix failure to start with space in directory path on Windows 
(CASSANDRA-10239)
 + * Fix repair hang when snapshot failed (CASSANDRA-10057)
 + * Fall back to 1/4 commitlog volume for commitlog_total_space on small disks
 +   (CASSANDRA-10199)
 +Merged from 2.1:
   * Bulk Loader API could not tolerate even node failure (CASSANDRA-10347)
   * Avoid misleading pushed notifications when multiple nodes
 share an rpc_address (CASSANDRA-10052)

[2/3] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[jake]

Merge branch 'cassandra-2.1' into cassandra-2.2

Conflicts:
CHANGES.txt


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

Branch: refs/heads/cassandra-3.0
Commit: be89dae3ecfd98b2170732c45d7f95807d5c19af
Parents: 1c073e7 1b08cbd
Author: T Jake Luciani 
Authored: Wed Oct 7 10:13:40 2015 -0400
Committer: T Jake Luciani 
Committed: Wed Oct 7 10:13:40 2015 -0400

--
 CHANGES.txt   |   3 ++-
 ...assandra-driver-internal-only-2.6.0c2.post.zip | Bin 198346 -> 0 bytes
 lib/cassandra-driver-internal-only-2.7.2.zip  | Bin 0 -> 229600 bytes
 3 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/be89dae3/CHANGES.txt
--
diff --cc CHANGES.txt
index 47fa4c2,d678efe..82ee94d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,20 -1,7 +1,21 @@@
 -2.1.11
 +2.2.3
 + * Make Hadoop CF splits more polite to custom orderered partitioners 
(CASSANDRA-10400)
- 
++Merged from 2.1:
+  * Update internal python driver used by cqlsh (CASSANDRA-10161)
  
 -2.1.10
 +2.2.2
 + * cqlsh prompt includes name of keyspace after failed `use` statement 
(CASSANDRA-10369)
 + * Configurable page size in cqlsh (CASSANDRA-9855)
 + * Defer default role manager setup until all nodes are on 2.2+ 
(CASSANDRA-9761)
 + * Cancel transaction for sstables we wont redistribute index summary
 +   for (CASSANDRA-10270)
 + * Handle missing RoleManager in config after upgrade to 2.2 
(CASSANDRA-10209) 
 + * Retry snapshot deletion after compaction and gc on Windows 
(CASSANDRA-10222)
 + * Fix failure to start with space in directory path on Windows 
(CASSANDRA-10239)
 + * Fix repair hang when snapshot failed (CASSANDRA-10057)
 + * Fall back to 1/4 commitlog volume for commitlog_total_space on small disks
 +   (CASSANDRA-10199)
 +Merged from 2.1:
   * Bulk Loader API could not tolerate even node failure (CASSANDRA-10347)
   * Avoid misleading pushed notifications when multiple nodes
 share an rpc_address (CASSANDRA-10052)

cassandra git commit: Update python driver to 2.7.2

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 78f2e7aa0 -> 1b08cbd81


Update python driver to 2.7.2

Patch by carl; reviewed by tjake for CASSANDRA-10161


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

Branch: refs/heads/cassandra-2.1
Commit: 1b08cbd817dea379ea84175381d3ef151fe65681
Parents: 78f2e7a
Author: Carl Yeksigian 
Authored: Wed Sep 30 11:13:20 2015 -0400
Committer: T Jake Luciani 
Committed: Wed Oct 7 10:11:26 2015 -0400

--
 CHANGES.txt   |   3 +++
 ...assandra-driver-internal-only-2.6.0c2.post.zip | Bin 198346 -> 0 bytes
 lib/cassandra-driver-internal-only-2.7.2.zip  | Bin 0 -> 229600 bytes
 3 files changed, 3 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eec8161..d678efe 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+2.1.11
+ * Update internal python driver used by cqlsh (CASSANDRA-10161)
+
 2.1.10
  * Bulk Loader API could not tolerate even node failure (CASSANDRA-10347)
  * Avoid misleading pushed notifications when multiple nodes

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/lib/cassandra-driver-internal-only-2.6.0c2.post.zip
--
diff --git a/lib/cassandra-driver-internal-only-2.6.0c2.post.zip 
b/lib/cassandra-driver-internal-only-2.6.0c2.post.zip
deleted file mode 100644
index 5fa57c7..000
Binary files a/lib/cassandra-driver-internal-only-2.6.0c2.post.zip and 
/dev/null differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/lib/cassandra-driver-internal-only-2.7.2.zip
--
diff --git a/lib/cassandra-driver-internal-only-2.7.2.zip 
b/lib/cassandra-driver-internal-only-2.7.2.zip
new file mode 100644
index 000..f2e75f1
Binary files /dev/null and b/lib/cassandra-driver-internal-only-2.7.2.zip differ

[1/3] cassandra git commit: Update python driver to 2.7.2

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 36d0f55d4 -> 5b0967d04


Update python driver to 2.7.2

Patch by carl; reviewed by tjake for CASSANDRA-10161


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

Branch: refs/heads/cassandra-3.0
Commit: 1b08cbd817dea379ea84175381d3ef151fe65681
Parents: 78f2e7a
Author: Carl Yeksigian 
Authored: Wed Sep 30 11:13:20 2015 -0400
Committer: T Jake Luciani 
Committed: Wed Oct 7 10:11:26 2015 -0400

--
 CHANGES.txt   |   3 +++
 ...assandra-driver-internal-only-2.6.0c2.post.zip | Bin 198346 -> 0 bytes
 lib/cassandra-driver-internal-only-2.7.2.zip  | Bin 0 -> 229600 bytes
 3 files changed, 3 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eec8161..d678efe 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+2.1.11
+ * Update internal python driver used by cqlsh (CASSANDRA-10161)
+
 2.1.10
  * Bulk Loader API could not tolerate even node failure (CASSANDRA-10347)
  * Avoid misleading pushed notifications when multiple nodes

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/lib/cassandra-driver-internal-only-2.6.0c2.post.zip
--
diff --git a/lib/cassandra-driver-internal-only-2.6.0c2.post.zip 
b/lib/cassandra-driver-internal-only-2.6.0c2.post.zip
deleted file mode 100644
index 5fa57c7..000
Binary files a/lib/cassandra-driver-internal-only-2.6.0c2.post.zip and 
/dev/null differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b08cbd8/lib/cassandra-driver-internal-only-2.7.2.zip
--
diff --git a/lib/cassandra-driver-internal-only-2.7.2.zip 
b/lib/cassandra-driver-internal-only-2.7.2.zip
new file mode 100644
index 000..f2e75f1
Binary files /dev/null and b/lib/cassandra-driver-internal-only-2.7.2.zip differ

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

[jake]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: 5b0967d04151ba52ff00eb117d533b698eca1ea3
Parents: 36d0f55 be89dae
Author: T Jake Luciani 
Authored: Wed Oct 7 10:14:58 2015 -0400
Committer: T Jake Luciani 
Committed: Wed Oct 7 10:14:58 2015 -0400

--

--

[jira] [Updated] (CASSANDRA-10449) OOM on bootstrap due to long GC pause

[Robbie Strickland (JIRA)]

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

Robbie Strickland updated CASSANDRA-10449:
--
Attachment: thread_dump.log

I've attached a thread dump taken after the streaming hangs.

> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
>  Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and 
> 500-700GB per node.  SSTable counts are <10 per table.  I am attempting to 
> provision additional nodes, but bootstrapping OOMs every time after about 10 
> hours with a sudden long GC pause:
> {noformat}
> INFO  [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old 
> Generation GC in 1586126ms.  G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to 
> no avail.



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

[jira] [Commented] (CASSANDRA-9126) java.lang.RuntimeException: Last written key DecoratedKey >= current key DecoratedKey

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-9126:


[~mambocab] yeah, I think we want users to actually report this issue if it 
happens - it could be a legitimate bug in LCS for example

> java.lang.RuntimeException: Last written key DecoratedKey >= current key 
> DecoratedKey
> -
>
> Key: CASSANDRA-9126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9126
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: srinivasu gottipati
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: cassandra-system.log
>
>
> Cassandra V: 2.0.14,
> Getting the following exceptions while trying to compact (I see this issue 
> was raised in earlier versions and marked as closed. However it still appears 
> in 2.0.14). In our case, compaction is not getting succeeded and keep failing 
> with this error.:
> {code}java.lang.RuntimeException: Last written key 
> DecoratedKey(3462767860784856708, 
> 354038323137333038305f3330325f31355f474d4543454f) >= current key 
> DecoratedKey(3462334604624154281, 
> 354036333036353334315f3336315f31355f474d4543454f) writing into {code}
> ...
> Stacktrace:{code}
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:143)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:166)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:167)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> Any help is greatly appreciated



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

[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap due to long GC pause

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10449:
-

What GC parameters are you using and what was your original heap size before 
increasing to 48G? Have you tried using CMS with smaller heap sizes and/or 
higher young generation sizes? What's your streaming_socket_timeout_in_ms and 
memtable_flush_writers parameters?

ps: I'm not a gc expert, just trying to understand a bit more GC behavior on 
cassandra.

> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
>  Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and 
> 500-700GB per node.  SSTable counts are <10 per table.  I am attempting to 
> provision additional nodes, but bootstrapping OOMs every time after about 10 
> hours with a sudden long GC pause:
> {noformat}
> INFO  [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old 
> Generation GC in 1586126ms.  G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380 
> CassandraDaemon.java:223 - Exception in thread 
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to 
> no avail.



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

[jira] [Commented] (CASSANDRA-10463) Fix failing compaction tests

[Jim Witschey (JIRA)]

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

Jim Witschey commented on CASSANDRA-10463:
--

Sorry, I didn't include a CassCI link:

http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/227/testReport/

> Fix failing compaction tests
> 
>
> Key: CASSANDRA-10463
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10463
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Yuki Morishita
> Fix For: 3.0.0 rc2
>
>
> A bunch of compaction tests started failing after some changes to how logs 
> are handled in ccm:
> - 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_throughput_test
> - 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.data_size_test
> - 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_alter_and_nodetool_test
> - 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_alter_test
> - 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_nodetool_test
> - 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_schema_test
> - 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.sstable_deletion_test
> - 
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_throughput_test
> - compaction_test.TestCompaction_with_LeveledCompactionStrategy.data_size_test
> - 
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_alter_and_nodetool_test
> - 
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_alter_test
> - 
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_nodetool_test
> - 
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_schema_test
> - 
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.sstable_deletion_test
> - 
> compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.compaction_throughput_test
> - 
> compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.data_size_test
> - 
> compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_alter_and_nodetool_test
> - 
> compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_alter_test
> - 
> compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_nodetool_test
> - 
> compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_schema_test
> - 
> compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.sstable_deletion_test
> I haven't dug into it much, but it looks like the following tests:
> - compaction_throughput_test
> - data_size_test
> - disable_autocompaction_alter_and_nodetool_test
> - disable_autocompaction_alter_test
> - disable_autocompaction_nodetool_test
> - disable_autocompaction_schema_test
> - sstable_deletion_test
> grep logs to check if operations happened successfully, and that something in 
> the new log-handling code broke this.
> I'm assigning [~yukim], since I believe you wrote the changes to ccm, but 
> feel free to find a new assignee. 



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

[jira] [Commented] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10412:


Pushed a new version of the ticket which just has the changes to 
{{CassandraDaemon.activate}}, along with a comment there. 
{{DatabaseDescriptor}} is also used in the offline tools, so I made changes to 
the offline tools to make sure they properly call {{forceStaticInitialization}}.

> Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
> -
>
> Key: CASSANDRA-10412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10412
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: OS: Windows 2012 R2
> Java JRE: 1.8.0_51
>Reporter: Eric Simmons
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: cassandra-env.ps1, cassandra.yaml
>
>
> We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however 
> we can use the same environment to start version 2.1.2
> I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference.  
> I have also attached the system.log file displaying the error.
> I have also included an excerpt of the log file showing the stack trace of 
> the error.
> ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482 
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.cassandra.config.DatabaseDescriptor
>   at 
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57)
>  ~[apache-cassandra-2.2.1.jar:2.2.1]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122)
>  ~[apache-cassandra-2.2.1.jar:2.2.1]
>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.runAndReset(Unknown Source) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
>  Source) ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
>  Source) ~[na:1.8.0_51]
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
> [na:1.8.0_51]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> [na:1.8.0_51]
>   at java.lang.Thread.run(Unknown Source) [na:1.8.0_51]



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

[jira] [Comment Edited] (CASSANDRA-10233) IndexOutOfBoundsException in HintedHandOffManager

[J.P. Eiti Kimura (JIRA)]

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

J.P. Eiti Kimura edited comment on CASSANDRA-10233 at 10/7/15 2:28 PM:
---

Hello [~kf200467] the workaround is just truncat the system.hints table. 

The exception occurs due to inconsistent data in hints table, as described in 
my comments above, I found records where the hints primary key were null. 
Probably it was caused by assertions being disabled when running on production 
setup. 

The patch I code and we discussed here is to prevent inconsistent data being 
persisted in to the hints table. 
 I'll code a patch  to 2.0.X version as soo as possible. 


was (Author: eitikimura):
Hello [~kf200467] the workaround is just truncat the system.hints table. 

The exception occurs due to inconsistent data in hints table, as described in 
my comments above, I found records where the hints primary key were null. 
Probably it was caused by assertions being disabled when running on production 
setup. 

The patch I code and we discussed here is to prevent inconsistent data being 
persisted in to the hints table. 
For now, you can truncate system.hints table to stop with exceptions, I'll code 
a patch  to 2.0.X version as soo as possible. 

> IndexOutOfBoundsException in HintedHandOffManager
> -
>
> Key: CASSANDRA-10233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10233
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.0
>Reporter: Omri Iluz
>Assignee: J.P. Eiti Kimura
> Attachments: cassandra-2.1.8-10233-v2.txt, 
> cassandra-2.1.8-10233-v3.txt, cassandra-2.1.8-10233-v4.txt, 
> cassandra-2.2.1-10233.txt
>
>
> After upgrading our cluster to 2.2.0, the following error started showing 
> exectly every 10 minutes on every server in the cluster:
> {noformat}
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,506 
> CompactionTask.java:142 - Compacting (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-540-big-Data.db:level=0,
>  ]
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,599 
> CompactionTask.java:224 - Compacted (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 1 
> sstables to 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-541-big,] 
> to level=0.  1,544,495 bytes to 1,544,495 (~100% of original) in 93ms = 
> 15.838121MB/s.  0 total partitions merged to 4.  Partition merge counts were 
> {1:4, }
> ERROR [HintedHandoff:1] 2015-08-31 18:31:55,600 CassandraDaemon.java:182 - 
> Exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.IndexOutOfBoundsException: null
>   at java.nio.Buffer.checkIndex(Buffer.java:538) ~[na:1.7.0_79]
>   at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:410) 
> ~[na:1.7.0_79]
>   at org.apache.cassandra.utils.UUIDGen.getUUID(UUIDGen.java:106) 
> ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:515)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:88)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:168)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_79]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_79]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {noformat}



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

[jira] [Created] (CASSANDRA-10465) Pig tests are failing on CI

[Sylvain Lebresne (JIRA)]

Sylvain Lebresne created CASSANDRA-10465:


 Summary: Pig tests are failing on CI
 Key: CASSANDRA-10465
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10465
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Sylvain Lebresne
Assignee: Philip Thompson
 Fix For: 3.0.0 rc2


Pretty much all pig tests are failing on 3.0 so we should fix them.

I'll note that until recently they were failing hard due to the configuration 
using {{offheap_objects}} but I changed that recently and it's now failing with 
something that sound more PIG related. I'll also note that I'm pretty sure I've 
seen those test passing post-CASSANDRA-8099 so the failure is not _too_ old and 
we might be able to bisect it.



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

[jira] [Comment Edited] (CASSANDRA-10233) IndexOutOfBoundsException in HintedHandOffManager

[J.P. Eiti Kimura (JIRA)]

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

J.P. Eiti Kimura edited comment on CASSANDRA-10233 at 10/7/15 2:27 PM:
---

Hello [~kf200467] the workaround is just truncat the system.hints table. 

The exception occurs due to inconsistent data in hints table, as described in 
my comments above, I found records where the hints primary key were null. 
Probably it was caused by assertions being disabled when running on production 
setup. 

The patch I code and we discussed here is to prevent inconsistent data being 
persisted in to the hints table. 
For now, you can truncate system.hints table to stop with exceptions, I'll code 
a patch  to 2.0.X version as soo as possible. 


was (Author: eitikimura):
Hello [~kf200467] the workaround is just truncat the system.hints table. 

The exception occurs due to inconsistent data in hints table, as described in 
my comments above, I found records where the hints primary key were null. 
Probably it was caused by assertions being disabled when running on production 
setup. 

The patch I code and we discussed here is to prevent inconsistent data being 
persisted in to the hints table. 
For now, you can truncate system.hints table to stop with exceptions, I'll code 
a patch version for 2.0.X version as soo as possible. 

> IndexOutOfBoundsException in HintedHandOffManager
> -
>
> Key: CASSANDRA-10233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10233
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.0
>Reporter: Omri Iluz
>Assignee: J.P. Eiti Kimura
> Attachments: cassandra-2.1.8-10233-v2.txt, 
> cassandra-2.1.8-10233-v3.txt, cassandra-2.1.8-10233-v4.txt, 
> cassandra-2.2.1-10233.txt
>
>
> After upgrading our cluster to 2.2.0, the following error started showing 
> exectly every 10 minutes on every server in the cluster:
> {noformat}
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,506 
> CompactionTask.java:142 - Compacting (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-540-big-Data.db:level=0,
>  ]
> INFO  [CompactionExecutor:1381] 2015-08-31 18:31:55,599 
> CompactionTask.java:224 - Compacted (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 1 
> sstables to 
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-541-big,] 
> to level=0.  1,544,495 bytes to 1,544,495 (~100% of original) in 93ms = 
> 15.838121MB/s.  0 total partitions merged to 4.  Partition merge counts were 
> {1:4, }
> ERROR [HintedHandoff:1] 2015-08-31 18:31:55,600 CassandraDaemon.java:182 - 
> Exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.IndexOutOfBoundsException: null
>   at java.nio.Buffer.checkIndex(Buffer.java:538) ~[na:1.7.0_79]
>   at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:410) 
> ~[na:1.7.0_79]
>   at org.apache.cassandra.utils.UUIDGen.getUUID(UUIDGen.java:106) 
> ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:515)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:88)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:168)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
>  ~[apache-cassandra-2.2.0.jar:2.2.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_79]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_79]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_79]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {noformat}



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