[jira] [Comment Edited] (CASSANDRA-8694) Repair of empty keyspace hangs rather than ignoring the request
[
https://issues.apache.org/jira/browse/CASSANDRA-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295470#comment-14295470
]
Jeff Jirsa edited comment on CASSANDRA-8694 at 1/31/15 5:26 AM:
There's already a check for empty cfnames in repair.RepairSession:
assert cfnames.length > 0 : "Repairing no column families seems
pointless, doesn't it";
We can check cfnames.length prior to getting there to prevent the hang
{noformat}
bash-3.2# ccm create --install-dir ./cassandra/ --nodes 3 --start 300snapshot
Current cluster is now: 300snapshot
bash-3.2#
bash-3.2# ccm node1 nodetool -- repair
[2015-01-28 09:28:18,899] Nothing to repair for keyspace 'system_auth'
[2015-01-28 09:28:18,904] Starting repair command #1, repairing keyspace
system_traces with repair options (parallelism: parallel, primary range: false,
incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts:
[], # of ranges: 2)
[2015-01-28 09:28:18,954] Repair session 0cd1c9d0-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:18,968] Repair session 0cd488f0-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:18,972] Repair command #1 finished in 0 seconds
bash-3.2# ccm node1 cqlsh
Connected to 300snapshot at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.0.0-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 2}; create KEYSPACE test_with_table WITH replication =
{'class': 'SimpleStrategy', 'replication_factor': 2}; use test_with_table;
CREATE TABLE users ( user_name varchar PRIMARY KEY, password varchar,
gender varchar, session_token varchar, state varchar, birth_year bigint );
cqlsh:test_with_table> ^D
bash-3.2# ccm node1 nodetool -- repair
[2015-01-28 09:28:36,803] Starting repair command #2, repairing keyspace
test_with_table with repair options (parallelism: parallel, primary range:
false, incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [],
hosts: [], # of ranges: 2)
[2015-01-28 09:28:36,812] Repair session 177a5d70-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:36,814] Repair session 177a8480-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:36,815] Repair command #2 finished in 0 seconds
[2015-01-28 09:28:36,825] Starting repair command #3, repairing keyspace test
with repair options (parallelism: parallel, primary range: false, incremental:
true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of
ranges: 2)
[2015-01-28 09:28:36,829] Repair command #3 finished in 0 seconds
[2015-01-28 09:28:36,834] Nothing to repair for keyspace 'system_auth'
[2015-01-28 09:28:36,837] Starting repair command #4, repairing keyspace
system_traces with repair options (parallelism: parallel, primary range: false,
incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts:
[], # of ranges: 2)
[2015-01-28 09:28:36,848] Repair session 177fb4a0-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:36,853] Repair session 177fb4a1-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:36,855] Repair command #4 finished in 0 seconds
{noformat}
Without this patch, the RepairSession() immediately below this patch throws an
unhandled AssertionError (Repair session failed Repairing no column families
seems pointless, doesn't it).
was (Author: jjirsa):
There's already a check for empty cfnames in repair.RepairSession:
assert cfnames.length > 0 : "Repairing no column families seems
pointless, doesn't it";
We can check cfnames.length prior to getting there to prevent the hang
{noformat}
bash-3.2# ccm create --install-dir ./cassandra/ --nodes 3 --start 300snapshot
Current cluster is now: 300snapshot
bash-3.2#
bash-3.2# ccm node1 nodetool -- repair
[2015-01-28 09:28:18,899] Nothing to repair for keyspace 'system_auth'
[2015-01-28 09:28:18,904] Starting repair command #1, repairing keyspace
system_traces with repair options (parallelism: parallel, primary range: false,
incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts:
[], # of ranges: 2)
[2015-01-28 09:28:18,954] Repair session 0cd1c9d0-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:18,968] Repair session 0cd488f0-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:18,972] Repair command #1 finished in 0 seconds
bash-3.2# ccm node1 cqlsh
Connected to 300snapshot at 127.0.0.1:9042.
[cqlsh
[jira] [Updated] (CASSANDRA-8711) cassandra 2.1.2 ssl client encryption not working
[
https://issues.apache.org/jira/browse/CASSANDRA-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Liu updated CASSANDRA-8711:
Description:
I have been trying to setup client encryption on a three nodes 2.1.2 version
cassandra cluster and keep getting the following error:
{noformat}
Connection error: ('Unable to connect to any servers', {'localhost':
ConnectionShutdown('Connection is already closed',)})
{noformat}
I tried with both cqlsh and datatax python cassandra-driver and no luck to
login.
I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
{noformat}
[authentication]
username =
password =
[connection]
hostname = localhost
port = 9160
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile = /root/.cassandra/localhost_user1.pem
validate = false ## Optional, true by default
{noformat}
my cassandra.yaml configuration related to client_encryptions:
{noformat}
client_encryption_options:
enabled: True
keystore: /etc/cassandra/conf/.keystore
keystore_password: cassnest
{noformat}
the keystore, truststore, cert/pem (localhost_user1.pem) key have been verified
to be working fine for datastax enterprise version.
was:
I have been trying to setup client encryption on a three nodes 2.1.2 version
cassandra cluster and keep getting the following error:
{noformat}
Connection error: ('Unable to connect to any servers', {'localhost':
ConnectionShutdown('Connection is already closed',)})
{noformat}
I tried with both cqlsh and datatax python cassandra-driver and no luck to
login.
I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
{noformat}
[authentication]
username =
password =
[connection]
hostname = localhost
port = 9160
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile = /root/.cassandra/localhost_user1.pem
validate = false ## Optional, true by default
{noformat}
my cassandra.yaml configuration related to client_encryptions:
{noformat}
client_encryption_options:
enabled: True
keystore: /etc/cassandra/conf/.keystore
keystore_password: cassnest
{noformat}
the keystore, truststore, cert/pem key have been verified to be working fine
for datastax enterprise version.
> cassandra 2.1.2 ssl client encryption not working
> --
>
> Key: CASSANDRA-8711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8711
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Liu
>
> I have been trying to setup client encryption on a three nodes 2.1.2 version
> cassandra cluster and keep getting the following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'localhost':
> ConnectionShutdown('Connection (closed)> is already closed',)})
> {noformat}
> I tried with both cqlsh and datatax python cassandra-driver and no luck to
> login.
> I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
> {noformat}
> [authentication]
> username =
> password =
> [connection]
> hostname = localhost
> port = 9160
> factory = cqlshlib.ssl.ssl_transport_factory
> [ssl]
> certfile = /root/.cassandra/localhost_user1.pem
> validate = false ## Optional, true by default
> {noformat}
> my cassandra.yaml configuration related to client_encryptions:
> {noformat}
> client_encryption_options:
> enabled: True
> keystore: /etc/cassandra/conf/.keystore
> keystore_password: cassnest
> {noformat}
> the keystore, truststore, cert/pem (localhost_user1.pem) key have been
> verified to be working fine for datastax enterprise version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8711) cassandra 2.1.2 ssl client encryption not working
Jeff Liu created CASSANDRA-8711:
---
Summary: cassandra 2.1.2 ssl client encryption not working
Key: CASSANDRA-8711
URL: https://issues.apache.org/jira/browse/CASSANDRA-8711
Project: Cassandra
Issue Type: Bug
Reporter: Jeff Liu
I have been trying to setup client encryption on a three nodes 2.1.2 version
cassandra cluster and keep getting the following error:
{noformat}
Connection error: ('Unable to connect to any servers', {'localhost':
ConnectionShutdown('Connection is already closed',)})
{noformat}
I tried with both cqlsh and datatax python cassandra-driver and no luck to
login.
I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
{/noformat}
[authentication]
username =
password =
[connection]
hostname = localhost
port = 9160
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile = /root/.cassandra/localhost_user1.pem
validate = false ## Optional, true by default
{/noformat}
my cassandra.yaml configuration related to client_encryptions:
{noformat}
client_encryption_options:
enabled: True
keystore: /etc/cassandra/conf/.keystore
keystore_password: cassnest
{noformat}
the keystore, truststore, cert/pem key have been verified to be working fine
for datastax enterprise version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8711) cassandra 2.1.2 ssl client encryption not working
[
https://issues.apache.org/jira/browse/CASSANDRA-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Liu updated CASSANDRA-8711:
Description:
I have been trying to setup client encryption on a three nodes 2.1.2 version
cassandra cluster and keep getting the following error:
{noformat}
Connection error: ('Unable to connect to any servers', {'localhost':
ConnectionShutdown('Connection is already closed',)})
{noformat}
I tried with both cqlsh and datatax python cassandra-driver and no luck to
login.
I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
{noformat}
[authentication]
username =
password =
[connection]
hostname = localhost
port = 9160
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile = /root/.cassandra/localhost_user1.pem
validate = false ## Optional, true by default
{noformat}
my cassandra.yaml configuration related to client_encryptions:
{noformat}
client_encryption_options:
enabled: True
keystore: /etc/cassandra/conf/.keystore
keystore_password: cassnest
{noformat}
the keystore, truststore, cert/pem key have been verified to be working fine
for datastax enterprise version.
was:
I have been trying to setup client encryption on a three nodes 2.1.2 version
cassandra cluster and keep getting the following error:
{noformat}
Connection error: ('Unable to connect to any servers', {'localhost':
ConnectionShutdown('Connection is already closed',)})
{noformat}
I tried with both cqlsh and datatax python cassandra-driver and no luck to
login.
I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
{noformat}
[authentication]
username =
password =
[connection]
hostname = localhost
port = 9160
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile = /root/.cassandra/localhost_user1.pem
validate = false ## Optional, true by default
{/noformat}
my cassandra.yaml configuration related to client_encryptions:
{noformat}
client_encryption_options:
enabled: True
keystore: /etc/cassandra/conf/.keystore
keystore_password: cassnest
{noformat}
the keystore, truststore, cert/pem key have been verified to be working fine
for datastax enterprise version.
> cassandra 2.1.2 ssl client encryption not working
> --
>
> Key: CASSANDRA-8711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8711
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Liu
>
> I have been trying to setup client encryption on a three nodes 2.1.2 version
> cassandra cluster and keep getting the following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'localhost':
> ConnectionShutdown('Connection (closed)> is already closed',)})
> {noformat}
> I tried with both cqlsh and datatax python cassandra-driver and no luck to
> login.
> I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
> {noformat}
> [authentication]
> username =
> password =
> [connection]
> hostname = localhost
> port = 9160
> factory = cqlshlib.ssl.ssl_transport_factory
> [ssl]
> certfile = /root/.cassandra/localhost_user1.pem
> validate = false ## Optional, true by default
> {noformat}
> my cassandra.yaml configuration related to client_encryptions:
> {noformat}
> client_encryption_options:
> enabled: True
> keystore: /etc/cassandra/conf/.keystore
> keystore_password: cassnest
> {noformat}
> the keystore, truststore, cert/pem key have been verified to be working fine
> for datastax enterprise version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8711) cassandra 2.1.2 ssl client encryption not working
[
https://issues.apache.org/jira/browse/CASSANDRA-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Liu updated CASSANDRA-8711:
Description:
I have been trying to setup client encryption on a three nodes 2.1.2 version
cassandra cluster and keep getting the following error:
{noformat}
Connection error: ('Unable to connect to any servers', {'localhost':
ConnectionShutdown('Connection is already closed',)})
{noformat}
I tried with both cqlsh and datatax python cassandra-driver and no luck to
login.
I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
{noformat}
[authentication]
username =
password =
[connection]
hostname = localhost
port = 9160
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile = /root/.cassandra/localhost_user1.pem
validate = false ## Optional, true by default
{/noformat}
my cassandra.yaml configuration related to client_encryptions:
{noformat}
client_encryption_options:
enabled: True
keystore: /etc/cassandra/conf/.keystore
keystore_password: cassnest
{noformat}
the keystore, truststore, cert/pem key have been verified to be working fine
for datastax enterprise version.
was:
I have been trying to setup client encryption on a three nodes 2.1.2 version
cassandra cluster and keep getting the following error:
{noformat}
Connection error: ('Unable to connect to any servers', {'localhost':
ConnectionShutdown('Connection is already closed',)})
{noformat}
I tried with both cqlsh and datatax python cassandra-driver and no luck to
login.
I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
{/noformat}
[authentication]
username =
password =
[connection]
hostname = localhost
port = 9160
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile = /root/.cassandra/localhost_user1.pem
validate = false ## Optional, true by default
{/noformat}
my cassandra.yaml configuration related to client_encryptions:
{noformat}
client_encryption_options:
enabled: True
keystore: /etc/cassandra/conf/.keystore
keystore_password: cassnest
{noformat}
the keystore, truststore, cert/pem key have been verified to be working fine
for datastax enterprise version.
> cassandra 2.1.2 ssl client encryption not working
> --
>
> Key: CASSANDRA-8711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8711
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Liu
>
> I have been trying to setup client encryption on a three nodes 2.1.2 version
> cassandra cluster and keep getting the following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'localhost':
> ConnectionShutdown('Connection (closed)> is already closed',)})
> {noformat}
> I tried with both cqlsh and datatax python cassandra-driver and no luck to
> login.
> I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
> {noformat}
> [authentication]
> username =
> password =
> [connection]
> hostname = localhost
> port = 9160
> factory = cqlshlib.ssl.ssl_transport_factory
> [ssl]
> certfile = /root/.cassandra/localhost_user1.pem
> validate = false ## Optional, true by default
> {/noformat}
> my cassandra.yaml configuration related to client_encryptions:
> {noformat}
> client_encryption_options:
> enabled: True
> keystore: /etc/cassandra/conf/.keystore
> keystore_password: cassnest
> {noformat}
> the keystore, truststore, cert/pem key have been verified to be working fine
> for datastax enterprise version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8689) Assertion error in 2.1.2: ERROR [IndexSummaryManager:1]
[
https://issues.apache.org/jira/browse/CASSANDRA-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299350#comment-14299350
]
Tyler Hobbs commented on CASSANDRA-8689:
[~jeffl] can you enable TRACE level logging on the IndexSummaryManager class to
see if we can get more details about what might be happening?
You should be able to do that by adding the following line to {{logback.xml}}:
{noformat}
{noformat}
The IndexSummaryManager runs a resize process once every hour (by default), so
it may take a while to see something in the logs.
> Assertion error in 2.1.2: ERROR [IndexSummaryManager:1]
> ---
>
> Key: CASSANDRA-8689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8689
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Liu
> Fix For: 2.1.3
>
>
> After upgrading a 6 nodes cassandra from 2.1.0 to 2.1.2, start getting the
> following assertion error.
> {noformat}
> ERROR [IndexSummaryManager:1] 2015-01-26 20:55:40,451
> CassandraDaemon.java:153 - Exception in thread
> Thread[IndexSummaryManager:1,1,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.io.util.Memory.size(Memory.java:307)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> org.apache.cassandra.io.sstable.IndexSummary.getOffHeapSize(IndexSummary.java:192)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> org.apache.cassandra.io.sstable.SSTableReader.getIndexSummaryOffHeapSize(SSTableReader.java:1070)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> org.apache.cassandra.io.sstable.IndexSummaryManager.redistributeSummaries(IndexSummaryManager.java:292)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> org.apache.cassandra.io.sstable.IndexSummaryManager.redistributeSummaries(IndexSummaryManager.java:238)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> org.apache.cassandra.io.sstable.IndexSummaryManager$1.runMayThrow(IndexSummaryManager.java:139)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:77)
> ~[apache-cassandra-2.1.2.jar:2.1.2]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]
> {noformat}
> cassandra service is still running despite the issue. Node has total 8G
> memory with 2G allocated to heap. We are basically running read queries to
> retrieve data out of cassandra.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8694) Repair of empty keyspace hangs rather than ignoring the request
[
https://issues.apache.org/jira/browse/CASSANDRA-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295470#comment-14295470
]
Jeff Jirsa edited comment on CASSANDRA-8694 at 1/30/15 10:57 PM:
-
There's already a check for empty cfnames in repair.RepairSession:
assert cfnames.length > 0 : "Repairing no column families seems
pointless, doesn't it";
We can check cfnames.length prior to getting there to prevent the hang
{noformat}
bash-3.2# ccm create --install-dir ./cassandra/ --nodes 3 --start 300snapshot
Current cluster is now: 300snapshot
bash-3.2#
bash-3.2# ccm node1 nodetool -- repair
[2015-01-28 09:28:18,899] Nothing to repair for keyspace 'system_auth'
[2015-01-28 09:28:18,904] Starting repair command #1, repairing keyspace
system_traces with repair options (parallelism: parallel, primary range: false,
incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts:
[], # of ranges: 2)
[2015-01-28 09:28:18,954] Repair session 0cd1c9d0-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:18,968] Repair session 0cd488f0-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:18,972] Repair command #1 finished in 0 seconds
bash-3.2# ccm node1 cqlsh
Connected to 300snapshot at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.0.0-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 2}; create KEYSPACE test_with_table WITH replication =
{'class': 'SimpleStrategy', 'replication_factor': 2}; use test_with_table;
CREATE TABLE users ( user_name varchar PRIMARY KEY, password varchar,
gender varchar, session_token varchar, state varchar, birth_year bigint );
cqlsh:test_with_table> ^D
bash-3.2# ccm node1 nodetool -- repair
[2015-01-28 09:28:36,803] Starting repair command #2, repairing keyspace
test_with_table with repair options (parallelism: parallel, primary range:
false, incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [],
hosts: [], # of ranges: 2)
[2015-01-28 09:28:36,812] Repair session 177a5d70-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:36,814] Repair session 177a8480-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:36,815] Repair command #2 finished in 0 seconds
[2015-01-28 09:28:36,825] Starting repair command #3, repairing keyspace test
with repair options (parallelism: parallel, primary range: false, incremental:
true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of
ranges: 2)
[2015-01-28 09:28:36,829] Repair command #3 finished in 0 seconds
[2015-01-28 09:28:36,834] Nothing to repair for keyspace 'system_auth'
[2015-01-28 09:28:36,837] Starting repair command #4, repairing keyspace
system_traces with repair options (parallelism: parallel, primary range: false,
incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts:
[], # of ranges: 2)
[2015-01-28 09:28:36,848] Repair session 177fb4a0-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:36,853] Repair session 177fb4a1-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:36,855] Repair command #4 finished in 0 seconds
{noformat}
was (Author: jjirsa):
There's already a check for empty cfnames in repair.RepairSession:
assert cfnames.length > 0 : "Repairing no column families seems
pointless, doesn't it";
We can check cfnames.length prior to getting there to prevent the hang
bash-3.2# ccm create --install-dir ./cassandra/ --nodes 3 --start 300snapshot
Current cluster is now: 300snapshot
bash-3.2#
bash-3.2# ccm node1 nodetool -- repair
[2015-01-28 09:28:18,899] Nothing to repair for keyspace 'system_auth'
[2015-01-28 09:28:18,904] Starting repair command #1, repairing keyspace
system_traces with repair options (parallelism: parallel, primary range: false,
incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts:
[], # of ranges: 2)
[2015-01-28 09:28:18,954] Repair session 0cd1c9d0-a713-11e4-a05c-4f27f9294abb
for range (3074457345618258602,-9223372036854775808] finished
[2015-01-28 09:28:18,968] Repair session 0cd488f0-a713-11e4-a05c-4f27f9294abb
for range (-3074457345618258603,3074457345618258602] finished
[2015-01-28 09:28:18,972] Repair command #1 finished in 0 seconds
bash-3.2# ccm node1 cqlsh
Connected to 300snapshot at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.0.0-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 2}; create K
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299318#comment-14299318 ] Aleksey Yeschenko commented on CASSANDRA-7968: -- And finally, I believe that Vishy ultimately got what he wanted in CASSANDRA-8194, which is in the released 2.0.12 now. > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/4] cassandra git commit: ninja follow-up to 8619
Repository: cassandra
Updated Branches:
refs/heads/trunk 2e4ad069d -> c1960d8b7
ninja follow-up to 8619
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6ae8adaa
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6ae8adaa
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6ae8adaa
Branch: refs/heads/trunk
Commit: 6ae8adaa3c9eef3606ef1f6a27b828066225aac2
Parents: 31324ee
Author: Benedict Elliott Smith
Authored: Thu Jan 29 09:41:49 2015 +
Committer: Benedict Elliott Smith
Committed: Thu Jan 29 09:41:49 2015 +
--
.../cassandra/io/sstable/CQLSSTableWriter.java | 2 +-
.../io/sstable/SSTableSimpleUnsortedWriter.java | 32 ++--
2 files changed, 23 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6ae8adaa/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index d58b28f..8006112 100644
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@ -534,7 +534,7 @@ public class CQLSSTableWriter implements Closeable
};
}
-protected void addColumn(Cell cell) throws IOException
+protected void addColumn(Column column) throws IOException
{
throw new UnsupportedOperationException();
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6ae8adaa/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
--
diff --git
a/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
b/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
index b58e574..db03ea1 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
@@ -23,6 +23,7 @@ import java.util.Map;
import java.util.TreeMap;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.SynchronousQueue;
+import java.util.concurrent.TimeUnit;
import com.google.common.base.Throwables;
@@ -165,17 +166,21 @@ public class SSTableSimpleUnsortedWriter extends
AbstractSSTableSimpleWriter
if (buffer.isEmpty())
return;
-checkForWriterException();
-
-columnFamily = null;
-try
+while (true)
{
-writeQueue.put(buffer);
-}
-catch (InterruptedException e)
-{
-throw new RuntimeException(e);
+checkForWriterException();
+columnFamily = null;
+try
+{
+if (writeQueue.offer(buffer, 1L, TimeUnit.SECONDS))
+break;
+}
+catch (InterruptedException e)
+{
+throw new RuntimeException(e);
+
+}
}
buffer = new Buffer();
currentSize = 0;
@@ -213,8 +218,15 @@ public class SSTableSimpleUnsortedWriter extends
AbstractSSTableSimpleWriter
return;
writer = getWriter();
+boolean first = true;
for (Map.Entry entry :
b.entrySet())
-writer.append(entry.getKey(), entry.getValue());
+{
+if (entry.getValue().getColumnCount() > 0)
+writer.append(entry.getKey(), entry.getValue());
+else if (!first)
+throw new AssertionError("Empty partition");
+first = false;
+}
writer.close();
}
}
[3/4] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: src/java/org/apache/cassandra/config/CFMetaData.java src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java src/java/org/apache/cassandra/db/marshal/CounterColumnType.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c38a103 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c38a103 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c38a103 Branch: refs/heads/trunk Commit: 9c38a103bab8244ea2887cdb821752e0c815f79b Parents: cdcf646 d0005a8 Author: Tyler Hobbs Authored: Fri Jan 30 16:41:23 2015 -0600 Committer: Tyler Hobbs Committed: Fri Jan 30 16:41:23 2015 -0600 -- CHANGES.txt | 7 --- .../apache/cassandra/cql3/statements/AlterTableStatement.java | 4 src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java | 5 + .../cassandra/cql3/statements/CreateTableStatement.java | 6 ++ 4 files changed, 19 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c38a103/CHANGES.txt -- diff --cc CHANGES.txt index 92c1a17,4754867..129e1c9 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,95 -1,13 +1,96 @@@ -2.0.13: +2.1.3 + * Upgrade libthrift to 0.9.2 (CASSANDRA-8685) + * Don't use the shared ref in sstableloader (CASSANDRA-8704) + * Purge internal prepared statements if related tables or + keyspaces are dropped (CASSANDRA-8693) + * (cqlsh) Handle unicode BOM at start of files (CASSANDRA-8638) + * Stop compactions before exiting offline tools (CASSANDRA-8623) + * Update tools/stress/README.txt to match current behaviour (CASSANDRA-7933) + * Fix schema from Thrift conversion with empty metadata (CASSANDRA-8695) + * Safer Resource Management (CASSANDRA-7705) + * Make sure we compact highly overlapping cold sstables with + STCS (CASSANDRA-8635) + * rpc_interface and listen_interface generate NPE on startup when specified + interface doesn't exist (CASSANDRA-8677) + * Fix ArrayIndexOutOfBoundsException in nodetool cfhistograms (CASSANDRA-8514) + * Switch from yammer metrics for nodetool cf/proxy histograms (CASSANDRA-8662) + * Make sure we don't add tmplink files to the compaction + strategy (CASSANDRA-8580) + * (cqlsh) Handle maps with blob keys (CASSANDRA-8372) + * (cqlsh) Handle DynamicCompositeType schemas correctly (CASSANDRA-8563) + * Duplicate rows returned when in clause has repeated values (CASSANDRA-6707) + * Add tooling to detect hot partitions (CASSANDRA-7974) + * Fix cassandra-stress user-mode truncation of partition generation (CASSANDRA-8608) + * Only stream from unrepaired sstables during inc repair (CASSANDRA-8267) + * Don't allow starting multiple inc repairs on the same sstables (CASSANDRA-8316) + * Invalidate prepared BATCH statements when related tables + or keyspaces are dropped (CASSANDRA-8652) + * Fix missing results in secondary index queries on collections + with ALLOW FILTERING (CASSANDRA-8421) + * Expose EstimatedHistogram metrics for range slices (CASSANDRA-8627) + * (cqlsh) Escape clqshrc passwords properly (CASSANDRA-8618) + * Fix NPE when passing wrong argument in ALTER TABLE statement (CASSANDRA-8355) + * Pig: Refactor and deprecate CqlStorage (CASSANDRA-8599) + * Don't reuse the same cleanup strategy for all sstables (CASSANDRA-8537) + * Fix case-sensitivity of index name on CREATE and DROP INDEX + statements (CASSANDRA-8365) + * Better detection/logging for corruption in compressed sstables (CASSANDRA-8192) + * Use the correct repairedAt value when closing writer (CASSANDRA-8570) + * (cqlsh) Handle a schema mismatch being detected on startup (CASSANDRA-8512) + * Properly calculate expected write size during compaction (CASSANDRA-8532) + * Invalidate affected prepared statements when a table's columns + are altered (CASSANDRA-7910) + * Stress - user defined writes should populate sequentally (CASSANDRA-8524) + * Fix regression in SSTableRewriter causing some rows to become unreadable + during compaction (CASSANDRA-8429) + * Run major compactions for repaired/unrepaired in parallel (CASSANDRA-8510) + * (cqlsh) Fix compression options in DESCRIBE TABLE output when compression + is disabled (CASSANDRA-8288) + * (cqlsh) Fix DESCRIBE output after keyspaces are altered (CASSANDRA-7623) + * Make sure we set lastCompactedKey correctly (CASSANDRA-8463) + * (cqlsh) Fix output of CONSISTENCY command (CASSANDRA-8507) + * (cqlsh) Fixed the handling of LIST statements (CASSANDRA-8370) + * Make sstablescrub check leveled manifest again (CASSANDRA-8432) + * Check first/last keys in sstable when giving out positions
[2/4] cassandra git commit: Disallow default_time_to_live on counter tables
Disallow default_time_to_live on counter tables
Patch by Jeff Jirsa; reviewed by Tyler Hobbs for CASSANDRA-8678
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d0005a83
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d0005a83
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d0005a83
Branch: refs/heads/trunk
Commit: d0005a83ef9bfc1042747cbe45708ded1f2002ba
Parents: 6ae8ada
Author: Jeff Jirsa
Authored: Fri Jan 30 16:33:56 2015 -0600
Committer: Tyler Hobbs
Committed: Fri Jan 30 16:33:56 2015 -0600
--
CHANGES.txt| 5 -
src/java/org/apache/cassandra/config/CFMetaData.java | 5 +
.../apache/cassandra/cql3/statements/AlterTableStatement.java | 4
src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java | 5 +
.../apache/cassandra/cql3/statements/CreateTableStatement.java | 6 ++
src/java/org/apache/cassandra/db/marshal/AbstractType.java | 5 +
.../org/apache/cassandra/db/marshal/CounterColumnType.java | 5 +
7 files changed, 34 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7fa5f63..4754867 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,8 @@
2.0.13:
- * Fix SSTableSimpleUnsortedWriter ConcurrentModificationException
(CASSANDRA-8619)
+ * Prevent non-zero default_time_to_live on tables with counters
+ (CASSANDRA-8678)
+ * Fix SSTableSimpleUnsortedWriter ConcurrentModificationException
+ (CASSANDRA-8619)
* Round up time deltas lower than 1ms in BulkLoader (CASSANDRA-8645)
* Add batch remove iterator to ABSC (CASSANDRA-8414, 8666)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 9d69710..04a5b01 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -2192,6 +2192,11 @@ public final class CFMetaData
return true;
}
+public boolean isCounter()
+{
+return defaultValidator.isCounter();
+}
+
public boolean hasStaticColumns()
{
return !staticColumns.isEmpty();
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 32f949f..f74670f 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -268,6 +268,10 @@ public class AlterTableStatement extends
SchemaAlteringStatement
throw new InvalidRequestException(String.format("ALTER
COLUMNFAMILY WITH invoked, but no parameters found"));
cfProps.validate();
+
+if (meta.isCounter() && cfProps.getDefaultTimeToLive() > 0)
+throw new InvalidRequestException("Cannot set
default_time_to_live on a table with counters");
+
cfProps.applyToCFMetadata(cfm);
break;
case RENAME:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
index 6ce6406..11aa9b2 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
@@ -138,6 +138,11 @@ public class CFPropDefs extends PropertyDefinitions
return compressionOptions;
}
+public Integer getDefaultTimeToLive() throws SyntaxException
+{
+return getInt(KW_DEFAULT_TIME_TO_LIVE, 0);
+}
+
public void applyToCFMetadata(CFMetaData cfm) throws
ConfigurationException, SyntaxException
{
if (hasProperty(KW_COMMENT))
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/CreateTableS
[4/4] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk
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/c1960d8b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c1960d8b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c1960d8b
Branch: refs/heads/trunk
Commit: c1960d8b792428d70967c6d196df11673b1533d2
Parents: 2e4ad06 9c38a10
Author: Tyler Hobbs
Authored: Fri Jan 30 16:42:21 2015 -0600
Committer: Tyler Hobbs
Committed: Fri Jan 30 16:42:21 2015 -0600
--
CHANGES.txt| 5 -
.../apache/cassandra/cql3/statements/AlterTableStatement.java | 4
src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java | 5 +
.../apache/cassandra/cql3/statements/CreateTableStatement.java | 6 ++
4 files changed, 19 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1960d8b/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1960d8b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index b340524,9d07459..5ee48b8
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@@ -257,9 -257,13 +257,13 @@@ public class AlterTableStatement extend
break;
case OPTS:
if (cfProps == null)
-throw new InvalidRequestException(String.format("ALTER
COLUMNFAMILY WITH invoked, but no parameters found"));
+throw new InvalidRequestException(String.format("ALTER
TABLE WITH invoked, but no parameters found"));
cfProps.validate();
+
+ if (meta.isCounter() && cfProps.getDefaultTimeToLive() > 0)
+ throw new InvalidRequestException("Cannot set
default_time_to_live on a table with counters");
+
cfProps.applyToCFMetadata(cfm);
break;
case RENAME:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1960d8b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1960d8b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--
[1/3] cassandra git commit: ninja follow-up to 8619
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 cdcf6461a -> 9c38a103b
ninja follow-up to 8619
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6ae8adaa
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6ae8adaa
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6ae8adaa
Branch: refs/heads/cassandra-2.1
Commit: 6ae8adaa3c9eef3606ef1f6a27b828066225aac2
Parents: 31324ee
Author: Benedict Elliott Smith
Authored: Thu Jan 29 09:41:49 2015 +
Committer: Benedict Elliott Smith
Committed: Thu Jan 29 09:41:49 2015 +
--
.../cassandra/io/sstable/CQLSSTableWriter.java | 2 +-
.../io/sstable/SSTableSimpleUnsortedWriter.java | 32 ++--
2 files changed, 23 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6ae8adaa/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index d58b28f..8006112 100644
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@ -534,7 +534,7 @@ public class CQLSSTableWriter implements Closeable
};
}
-protected void addColumn(Cell cell) throws IOException
+protected void addColumn(Column column) throws IOException
{
throw new UnsupportedOperationException();
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6ae8adaa/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
--
diff --git
a/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
b/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
index b58e574..db03ea1 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java
@@ -23,6 +23,7 @@ import java.util.Map;
import java.util.TreeMap;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.SynchronousQueue;
+import java.util.concurrent.TimeUnit;
import com.google.common.base.Throwables;
@@ -165,17 +166,21 @@ public class SSTableSimpleUnsortedWriter extends
AbstractSSTableSimpleWriter
if (buffer.isEmpty())
return;
-checkForWriterException();
-
-columnFamily = null;
-try
+while (true)
{
-writeQueue.put(buffer);
-}
-catch (InterruptedException e)
-{
-throw new RuntimeException(e);
+checkForWriterException();
+columnFamily = null;
+try
+{
+if (writeQueue.offer(buffer, 1L, TimeUnit.SECONDS))
+break;
+}
+catch (InterruptedException e)
+{
+throw new RuntimeException(e);
+
+}
}
buffer = new Buffer();
currentSize = 0;
@@ -213,8 +218,15 @@ public class SSTableSimpleUnsortedWriter extends
AbstractSSTableSimpleWriter
return;
writer = getWriter();
+boolean first = true;
for (Map.Entry entry :
b.entrySet())
-writer.append(entry.getKey(), entry.getValue());
+{
+if (entry.getValue().getColumnCount() > 0)
+writer.append(entry.getKey(), entry.getValue());
+else if (!first)
+throw new AssertionError("Empty partition");
+first = false;
+}
writer.close();
}
}
[2/3] cassandra git commit: Disallow default_time_to_live on counter tables
Disallow default_time_to_live on counter tables
Patch by Jeff Jirsa; reviewed by Tyler Hobbs for CASSANDRA-8678
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d0005a83
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d0005a83
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d0005a83
Branch: refs/heads/cassandra-2.1
Commit: d0005a83ef9bfc1042747cbe45708ded1f2002ba
Parents: 6ae8ada
Author: Jeff Jirsa
Authored: Fri Jan 30 16:33:56 2015 -0600
Committer: Tyler Hobbs
Committed: Fri Jan 30 16:33:56 2015 -0600
--
CHANGES.txt| 5 -
src/java/org/apache/cassandra/config/CFMetaData.java | 5 +
.../apache/cassandra/cql3/statements/AlterTableStatement.java | 4
src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java | 5 +
.../apache/cassandra/cql3/statements/CreateTableStatement.java | 6 ++
src/java/org/apache/cassandra/db/marshal/AbstractType.java | 5 +
.../org/apache/cassandra/db/marshal/CounterColumnType.java | 5 +
7 files changed, 34 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7fa5f63..4754867 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,8 @@
2.0.13:
- * Fix SSTableSimpleUnsortedWriter ConcurrentModificationException
(CASSANDRA-8619)
+ * Prevent non-zero default_time_to_live on tables with counters
+ (CASSANDRA-8678)
+ * Fix SSTableSimpleUnsortedWriter ConcurrentModificationException
+ (CASSANDRA-8619)
* Round up time deltas lower than 1ms in BulkLoader (CASSANDRA-8645)
* Add batch remove iterator to ABSC (CASSANDRA-8414, 8666)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 9d69710..04a5b01 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -2192,6 +2192,11 @@ public final class CFMetaData
return true;
}
+public boolean isCounter()
+{
+return defaultValidator.isCounter();
+}
+
public boolean hasStaticColumns()
{
return !staticColumns.isEmpty();
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 32f949f..f74670f 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -268,6 +268,10 @@ public class AlterTableStatement extends
SchemaAlteringStatement
throw new InvalidRequestException(String.format("ALTER
COLUMNFAMILY WITH invoked, but no parameters found"));
cfProps.validate();
+
+if (meta.isCounter() && cfProps.getDefaultTimeToLive() > 0)
+throw new InvalidRequestException("Cannot set
default_time_to_live on a table with counters");
+
cfProps.applyToCFMetadata(cfm);
break;
case RENAME:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
index 6ce6406..11aa9b2 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
@@ -138,6 +138,11 @@ public class CFPropDefs extends PropertyDefinitions
return compressionOptions;
}
+public Integer getDefaultTimeToLive() throws SyntaxException
+{
+return getInt(KW_DEFAULT_TIME_TO_LIVE, 0);
+}
+
public void applyToCFMetadata(CFMetaData cfm) throws
ConfigurationException, SyntaxException
{
if (hasProperty(KW_COMMENT))
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/Crea
[3/3] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: src/java/org/apache/cassandra/config/CFMetaData.java src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java src/java/org/apache/cassandra/db/marshal/CounterColumnType.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c38a103 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c38a103 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c38a103 Branch: refs/heads/cassandra-2.1 Commit: 9c38a103bab8244ea2887cdb821752e0c815f79b Parents: cdcf646 d0005a8 Author: Tyler Hobbs Authored: Fri Jan 30 16:41:23 2015 -0600 Committer: Tyler Hobbs Committed: Fri Jan 30 16:41:23 2015 -0600 -- CHANGES.txt | 7 --- .../apache/cassandra/cql3/statements/AlterTableStatement.java | 4 src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java | 5 + .../cassandra/cql3/statements/CreateTableStatement.java | 6 ++ 4 files changed, 19 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c38a103/CHANGES.txt -- diff --cc CHANGES.txt index 92c1a17,4754867..129e1c9 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,95 -1,13 +1,96 @@@ -2.0.13: +2.1.3 + * Upgrade libthrift to 0.9.2 (CASSANDRA-8685) + * Don't use the shared ref in sstableloader (CASSANDRA-8704) + * Purge internal prepared statements if related tables or + keyspaces are dropped (CASSANDRA-8693) + * (cqlsh) Handle unicode BOM at start of files (CASSANDRA-8638) + * Stop compactions before exiting offline tools (CASSANDRA-8623) + * Update tools/stress/README.txt to match current behaviour (CASSANDRA-7933) + * Fix schema from Thrift conversion with empty metadata (CASSANDRA-8695) + * Safer Resource Management (CASSANDRA-7705) + * Make sure we compact highly overlapping cold sstables with + STCS (CASSANDRA-8635) + * rpc_interface and listen_interface generate NPE on startup when specified + interface doesn't exist (CASSANDRA-8677) + * Fix ArrayIndexOutOfBoundsException in nodetool cfhistograms (CASSANDRA-8514) + * Switch from yammer metrics for nodetool cf/proxy histograms (CASSANDRA-8662) + * Make sure we don't add tmplink files to the compaction + strategy (CASSANDRA-8580) + * (cqlsh) Handle maps with blob keys (CASSANDRA-8372) + * (cqlsh) Handle DynamicCompositeType schemas correctly (CASSANDRA-8563) + * Duplicate rows returned when in clause has repeated values (CASSANDRA-6707) + * Add tooling to detect hot partitions (CASSANDRA-7974) + * Fix cassandra-stress user-mode truncation of partition generation (CASSANDRA-8608) + * Only stream from unrepaired sstables during inc repair (CASSANDRA-8267) + * Don't allow starting multiple inc repairs on the same sstables (CASSANDRA-8316) + * Invalidate prepared BATCH statements when related tables + or keyspaces are dropped (CASSANDRA-8652) + * Fix missing results in secondary index queries on collections + with ALLOW FILTERING (CASSANDRA-8421) + * Expose EstimatedHistogram metrics for range slices (CASSANDRA-8627) + * (cqlsh) Escape clqshrc passwords properly (CASSANDRA-8618) + * Fix NPE when passing wrong argument in ALTER TABLE statement (CASSANDRA-8355) + * Pig: Refactor and deprecate CqlStorage (CASSANDRA-8599) + * Don't reuse the same cleanup strategy for all sstables (CASSANDRA-8537) + * Fix case-sensitivity of index name on CREATE and DROP INDEX + statements (CASSANDRA-8365) + * Better detection/logging for corruption in compressed sstables (CASSANDRA-8192) + * Use the correct repairedAt value when closing writer (CASSANDRA-8570) + * (cqlsh) Handle a schema mismatch being detected on startup (CASSANDRA-8512) + * Properly calculate expected write size during compaction (CASSANDRA-8532) + * Invalidate affected prepared statements when a table's columns + are altered (CASSANDRA-7910) + * Stress - user defined writes should populate sequentally (CASSANDRA-8524) + * Fix regression in SSTableRewriter causing some rows to become unreadable + during compaction (CASSANDRA-8429) + * Run major compactions for repaired/unrepaired in parallel (CASSANDRA-8510) + * (cqlsh) Fix compression options in DESCRIBE TABLE output when compression + is disabled (CASSANDRA-8288) + * (cqlsh) Fix DESCRIBE output after keyspaces are altered (CASSANDRA-7623) + * Make sure we set lastCompactedKey correctly (CASSANDRA-8463) + * (cqlsh) Fix output of CONSISTENCY command (CASSANDRA-8507) + * (cqlsh) Fixed the handling of LIST statements (CASSANDRA-8370) + * Make sstablescrub check leveled manifest again (CASSANDRA-8432) + * Check first/last keys in sstable when giving out p
cassandra git commit: Disallow default_time_to_live on counter tables
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 6ae8adaa3 -> d0005a83e
Disallow default_time_to_live on counter tables
Patch by Jeff Jirsa; reviewed by Tyler Hobbs for CASSANDRA-8678
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d0005a83
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d0005a83
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d0005a83
Branch: refs/heads/cassandra-2.0
Commit: d0005a83ef9bfc1042747cbe45708ded1f2002ba
Parents: 6ae8ada
Author: Jeff Jirsa
Authored: Fri Jan 30 16:33:56 2015 -0600
Committer: Tyler Hobbs
Committed: Fri Jan 30 16:33:56 2015 -0600
--
CHANGES.txt| 5 -
src/java/org/apache/cassandra/config/CFMetaData.java | 5 +
.../apache/cassandra/cql3/statements/AlterTableStatement.java | 4
src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java | 5 +
.../apache/cassandra/cql3/statements/CreateTableStatement.java | 6 ++
src/java/org/apache/cassandra/db/marshal/AbstractType.java | 5 +
.../org/apache/cassandra/db/marshal/CounterColumnType.java | 5 +
7 files changed, 34 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7fa5f63..4754867 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,8 @@
2.0.13:
- * Fix SSTableSimpleUnsortedWriter ConcurrentModificationException
(CASSANDRA-8619)
+ * Prevent non-zero default_time_to_live on tables with counters
+ (CASSANDRA-8678)
+ * Fix SSTableSimpleUnsortedWriter ConcurrentModificationException
+ (CASSANDRA-8619)
* Round up time deltas lower than 1ms in BulkLoader (CASSANDRA-8645)
* Add batch remove iterator to ABSC (CASSANDRA-8414, 8666)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 9d69710..04a5b01 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -2192,6 +2192,11 @@ public final class CFMetaData
return true;
}
+public boolean isCounter()
+{
+return defaultValidator.isCounter();
+}
+
public boolean hasStaticColumns()
{
return !staticColumns.isEmpty();
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 32f949f..f74670f 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -268,6 +268,10 @@ public class AlterTableStatement extends
SchemaAlteringStatement
throw new InvalidRequestException(String.format("ALTER
COLUMNFAMILY WITH invoked, but no parameters found"));
cfProps.validate();
+
+if (meta.isCounter() && cfProps.getDefaultTimeToLive() > 0)
+throw new InvalidRequestException("Cannot set
default_time_to_live on a table with counters");
+
cfProps.applyToCFMetadata(cfm);
break;
case RENAME:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
index 6ce6406..11aa9b2 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
@@ -138,6 +138,11 @@ public class CFPropDefs extends PropertyDefinitions
return compressionOptions;
}
+public Integer getDefaultTimeToLive() throws SyntaxException
+{
+return getInt(KW_DEFAULT_TIME_TO_LIVE, 0);
+}
+
public void applyToCFMetadata(CFMetaData cfm) throws
ConfigurationException, SyntaxException
{
if (hasProperty(KW_COMMENT))
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0005a83/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
---
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299288#comment-14299288 ] Aleksey Yeschenko commented on CASSANDRA-7968: -- Can't get rid of something that's never been in, can you? I'm against adding this because I want that whole cache thing gone in favor of pushing that responsibility to individual implementations. Would be silly to add it, and almost immediately deprecate it. > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8707) Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted
[ https://issues.apache.org/jira/browse/CASSANDRA-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299286#comment-14299286 ] Benedict commented on CASSANDRA-8707: - I've pushed an update to the repository with numerous fixes to the test cases suppressing all leak detection (except in RefCountedTest, where they're intended). In doing so I came across several meaningful memory leaks that I've also fixed. The worst offender being the bloom filter from SSTableWriter, which was not being freed. Users performing bulk transformations could have presumably been badly affected by this. > Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted > > > Key: CASSANDRA-8707 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8707 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict > Fix For: 2.1.3 > > > There are still a few bugs with resource management, especially around > SSTableReader cleanup, esp. when intermixing with compaction. This migration > should help. We can simultaneously "simplify" the logic in SSTableReader to > not track the replacement chain, only to take a new reference to each of the > underlying resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299285#comment-14299285 ] Richard Low commented on CASSANDRA-7968: As Benedict says, there is at least one user who cares :) > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299283#comment-14299283 ] Benedict commented on CASSANDRA-7968: - I assume the reason it's being discussed is because somebody cares. So at least one person, rather than nobody. Then factor in it's only been a few months since it was introduced, including the holiday period, and that most people have slow release cycles, and it's probably a bit premature to be rid of it? > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299278#comment-14299278 ] Aleksey Yeschenko commented on CASSANDRA-7968: -- It failed the ultimate usefulness test - presence of anyone caring. So let's keep it that way. > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299276#comment-14299276 ] Brandon Williams commented on CASSANDRA-7968: - Maybe we should put it back... and register it this time. > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299275#comment-14299275 ] Aleksey Yeschenko commented on CASSANDRA-7968: -- Yeah. It wasn't being registered, and nobody really cared, at all. So it's gone entirely in 2.1 and trunk. > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7968) permissions_validity_in_ms should be settable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299269#comment-14299269 ] Richard Low commented on CASSANDRA-7968: How is this meant to work? The MBean is never registered so how do I call it? > permissions_validity_in_ms should be settable via JMX > - > > Key: CASSANDRA-7968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.11, 2.1.1 > > Attachments: 7968.txt > > > Oftentimes people don't think about auth problems and just run with the > default of RF=2 and 2000ms until it's too late, and at that point doing a > rolling restart to change the permissions cache can be a bit painful vs > setting it via JMX everywhere and then updating the yaml for future restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7688) Add data sizing to a system table
[ https://issues.apache.org/jira/browse/CASSANDRA-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299245#comment-14299245 ] Aleksey Yeschenko commented on CASSANDRA-7688: -- bq. Was your intent to just periodically execute this function and dump the results into system tables? Not this exact function, but yes, just periodically dump sizing info there. > Add data sizing to a system table > - > > Key: CASSANDRA-7688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7688 > Project: Cassandra > Issue Type: New Feature >Reporter: Jeremiah Jordan >Assignee: Aleksey Yeschenko > Fix For: 2.1.3 > > > Currently you can't implement something similar to describe_splits_ex purely > from the a native protocol driver. > https://datastax-oss.atlassian.net/browse/JAVA-312 is open to expose easily > getting ownership information to a client in the java-driver. But you still > need the data sizing part to get splits of a given size. We should add the > sizing information to a system table so that native clients can get to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7688) Add data sizing to a system table
[ https://issues.apache.org/jira/browse/CASSANDRA-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299242#comment-14299242 ] Matt Byrd commented on CASSANDRA-7688: -- So I suppose the reason for suggesting exposing the same call via cql, was that at least abstractly it was clear what this meant. I concede that plumbing all this through might not be straightforward. The problem with putting it in a system table is, what exactly do you put there? The current computation is a somewhat expensive on demand computation that is generally done relatively rarely. Was your intent to just periodically execute this function and dump the results into system tables? Or did you have something different in mind? > Add data sizing to a system table > - > > Key: CASSANDRA-7688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7688 > Project: Cassandra > Issue Type: New Feature >Reporter: Jeremiah Jordan >Assignee: Aleksey Yeschenko > Fix For: 2.1.3 > > > Currently you can't implement something similar to describe_splits_ex purely > from the a native protocol driver. > https://datastax-oss.atlassian.net/browse/JAVA-312 is open to expose easily > getting ownership information to a client in the java-driver. But you still > need the data sizing part to get splits of a given size. We should add the > sizing information to a system table so that native clients can get to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299238#comment-14299238 ] T Jake Luciani commented on CASSANDRA-8692: --- I also ran a test on cstar and see an improvement http://cstar.datastax.com/graph?stats=bd23e138-a8bc-11e4-acb3-42010af0688f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=172.59&ymin=0&ymax=229631.6 nagle is this patch (sorry for the bad label) nagle2 is 2.1 head with nagle on. It shows this is an improvement over just enabling nagle. > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8710) row cache: remove annoying classpath from "jemalloc not found" message
[ https://issues.apache.org/jira/browse/CASSANDRA-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299228#comment-14299228 ] Robert Stupp commented on CASSANDRA-8710: - Git branch (diff): https://github.com/snazy/cassandra/compare/8710-ohc-jemalloc?expand=1 OHC diff on github: https://github.com/snazy/ohc/compare/0.3.1...0.3.2 > row cache: remove annoying classpath from "jemalloc not found" message > -- > > Key: CASSANDRA-8710 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8710 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > > Currently ohc prints the exception message from the underlying JNA exception > when jemalloc could not be loaded. With C* this means ~40kB in one line. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8710) row cache: remove annoying classpath from "jemalloc not found" message
Robert Stupp created CASSANDRA-8710: --- Summary: row cache: remove annoying classpath from "jemalloc not found" message Key: CASSANDRA-8710 URL: https://issues.apache.org/jira/browse/CASSANDRA-8710 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Assignee: Robert Stupp Priority: Minor Currently ohc prints the exception message from the underlying JNA exception when jemalloc could not be loaded. With C* this means ~40kB in one line. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-3486) Node Tool command to stop repair
[ https://issues.apache.org/jira/browse/CASSANDRA-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299118#comment-14299118 ] Brian Flad commented on CASSANDRA-3486: --- Any updates? Much appreciated. > Node Tool command to stop repair > > > Key: CASSANDRA-3486 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3486 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: JVM >Reporter: Vijay >Assignee: Jason Brown >Priority: Minor > Labels: repair > Fix For: 2.1.3 > > Attachments: 0001-stop-repair-3583.patch > > > After CASSANDRA-1740, If the validation compaction is stopped then the repair > will hang. This ticket will allow users to kill the original repair. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299114#comment-14299114 ] Ariel Weisberg edited comment on CASSANDRA-8692 at 1/30/15 7:38 PM: That's a good point no delay off provides most of the benefits in GCE and EC2. Whenever I have tested Nagle there is no disadvantage even at low concurrency. I have even found that latency is lower at low concurrency which is counter-intuitive. I haven't measured that in C* yet. I think we still might get into trouble if we run into situations where Nagle does decide to hold messages. GCE Running with TCP no delay off 132254 132862 No delay on, no coalescing 118134 EC2 With no delay off First set of runs 390264 387958 392322 After replacing 10 instances 366579 365818 378221 No delay on 162987 was (Author: aweisberg): That's a good point no delay off provides most of the benefits in GCE and EC2. Whenever I have tested Nagle there is no disadvantage even at low concurrency. I have even found that latency is lower at low concurrency which is counter-intuitive. I haven't measured that in C* yet. I think we still might get into trouble if we run into situations where Nagle does decide to hold packets. GCE Running with TCP no delay off 132254 132862 No delay on, no coalescing 118134 EC2 With no delay off First set of runs 390264 387958 392322 After replacing 10 instances 366579 365818 378221 No delay on 162987 > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299114#comment-14299114 ] Ariel Weisberg commented on CASSANDRA-8692: --- That's a good point no delay off provides most of the benefits in GCE and EC2. Whenever I have tested Nagle there is no disadvantage even at low concurrency. I have even found that latency is lower at low concurrency which is counter-intuitive. I haven't measured that in C* yet. I think we still might get into trouble if we run into situations where Nagle does decide to hold packets. GCE Running with TCP no delay off 132254 132862 No delay on, no coalescing 118134 EC2 With no delay off First set of runs 390264 387958 392322 After replacing 10 instances 366579 365818 378221 No delay on 162987 > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299100#comment-14299100 ] Tupshin Harper commented on CASSANDRA-8692: --- At least 2.1 inclusion please. This is looking to be a pretty substantial win. > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299086#comment-14299086 ] jonathan lacefield commented on CASSANDRA-8692: --- While performance testing with a user, we noticed good results after applying this patch. Our performance testing was a simple 50/50 read/write test using 2.1 stress and the following artifacts: Simple.yaml - stress test yaml file: https://drive.google.com/file/d/0B4Imdpu2YrEbblVCVENvVTJIYjg/view?usp=sharing Stress results - https://docs.google.com/spreadsheets/d/13UFCqh-W2wK_kL97Mh_rPGw-RLv7dKvWDLKQ_SXq5Mo/edit?usp=sharing The patch was applied after "run 25" in the stress results. We were testing for SLA adherence to see how much throughput could be achieved while staying within an SLA target. After applying this patch, throughput increased from ~79k ops to ~94k ops while maintaining the SLA target. The cluster used for this exercise was a 6 node cluster hosted on ec2 on c3.8xl vms. > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299074#comment-14299074 ] T Jake Luciani edited comment on CASSANDRA-8692 at 1/30/15 7:12 PM: Running some experiments I can see a big improvement with this ticket on a 6 node RF=3 cluster writing at QUORUM. The left half is without the patch the right half is with. From steady state of 80k/sec to a steady state of 120k/sec I will mention I get similar results by using nagle. However just enabling nagle will cause small requests to slow down where as this approach adjusts. !batching-benchmark.png! was (Author: tjake): Running some experiments I can see a big improvement with this ticket on a 6 node RF=3 cluster writing at QUORUM. The left half is without the patch the right half is with. From steady state of 80k/sec to a steady state of 120k/sec I will mention I get similar results by using nagle. However just enabling nagle will cause small requests to slow down where as this approach adjusts. !batching_benchmark.png! > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299074#comment-14299074 ] T Jake Luciani edited comment on CASSANDRA-8692 at 1/30/15 7:12 PM: Running some experiments I can see a big improvement with this ticket on a 6 node RF=3 cluster writing at QUORUM. The left half is without the patch the right half is with. From steady state of 80k/sec to a steady state of 120k/sec I will mention I get similar results by using nagle. However just enabling nagle will cause small requests to slow down where as this approach adjusts. !batching_benchmark.png! was (Author: tjake): Running some experiments I can see a big improvement with this ticket on a 6 node RF=3 cluster writing at QUORUM. The left half is without the patch the right half is with. From steady state of 80k/sec to a steady state of 120k/sec I will mention I get similar results by using nagle. However just enabling nagle will cause small requests to slow down where as this approach adjusts. !batching_benchmark.png! > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8692: -- Attachment: batching-benchmark.png Running some experiments I can see a big improvement with this ticket on a 6 node RF=3 cluster writing at QUORUM. The left half is without the patch the right half is with. From steady state of 80k/sec to a steady state of 120k/sec I will mention I get similar results by using nagle. However just enabling nagle will cause small requests to slow down where as this approach adjusts. !batching_benchmark.png! > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Attachments: batching-benchmark.png > > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299062#comment-14299062 ] Ariel Weisberg edited comment on CASSANDRA-8692 at 1/30/15 7:07 PM: I've asked the two people who have tried the patch to post their experience. I personally don't have a passion for which versions it goes in, but I am willing to do whatever work is required to get it 2.1 ready. I think it's better for stakeholders to decide the risk/reward for 2.1 that is acceptable to them. It's hard to for a non-stakeholder like me to advocate for it. The one thing I will say is that there is performance and then there is doubling performance. Granted that is only in some configurations. My benchmarks are in CASSANDRA-8457 and here are some of them. https://issues.apache.org/jira/browse/CASSANDRA-8457?focusedCommentId=14266402&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14266402 In AWS without enhanced networking ||Coalesce window microseconds|Throughput|| |250| 502614| |200| 496206| |150| 487195| |100| 423415| |50| 326648| |25| 308175| |12| 292894| |6| 268456| |0| 153688| https://issues.apache.org/jira/browse/CASSANDRA-8457?focusedCommentId=14266963&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14266963 In GCE ||Coalesce window microseconds| Throughput|| |200| 149791| |150| 148755| |100| 147678| |50| 142565| |25| 144542| |12| 141679| |6| 142626| |0| 133905| |0| 132849| was (Author: aweisberg): I've asked the two people who have tried the patch to post their experience. I personally don't have a passion for which versions it goes in, but I am willing to whatever work is required to get it 2.1 ready. I think it's better for stakeholders to decide the risk/reward for 2.1 that is acceptable to them. It's hard to for a non-stakeholder like me to advocate for it. The one thing I will say is that there is performance and then there is doubling performance. Granted in only some configurations. My benchmarks are in CASSANDRA-8457 and here are some of them. https://issues.apache.org/jira/browse/CASSANDRA-8457?focusedCommentId=14266402&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14266402 In AWS without enhanced networking ||Coalesce window microseconds|Throughput|| |250| 502614| |200| 496206| |150| 487195| |100| 423415| |50| 326648| |25| 308175| |12| 292894| |6| 268456| |0| 153688| https://issues.apache.org/jira/browse/CASSANDRA-8457?focusedCommentId=14266963&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14266963 In GCE ||Coalesce window microseconds| Throughput|| |200| 149791| |150| 148755| |100| 147678| |50| 142565| |25| 144542| |12| 141679| |6| 142626| |0| 133905| |0| 132849| > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299062#comment-14299062 ] Ariel Weisberg commented on CASSANDRA-8692: --- I've asked the two people who have tried the patch to post their experience. I personally don't have a passion for which versions it goes in, but I am willing to whatever work is required to get it 2.1 ready. I think it's better for stakeholders to decide the risk/reward for 2.1 that is acceptable to them. It's hard to for a non-stakeholder like me to advocate for it. The one thing I will say is that there is performance and then there is doubling performance. Granted in only some configurations. My benchmarks are in CASSANDRA-8457 and here are some of them. https://issues.apache.org/jira/browse/CASSANDRA-8457?focusedCommentId=14266402&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14266402 In AWS without enhanced networking ||Coalesce window microseconds|Throughput|| |250| 502614| |200| 496206| |150| 487195| |100| 423415| |50| 326648| |25| 308175| |12| 292894| |6| 268456| |0| 153688| https://issues.apache.org/jira/browse/CASSANDRA-8457?focusedCommentId=14266963&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14266963 In GCE ||Coalesce window microseconds| Throughput|| |200| 149791| |150| 148755| |100| 147678| |50| 142565| |25| 144542| |12| 141679| |6| 142626| |0| 133905| |0| 132849| > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8705) cqlsh doesn't handle new line escape character inside string literals
[
https://issues.apache.org/jira/browse/CASSANDRA-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8705:
---
Labels: cqlsh (was: )
> cqlsh doesn't handle new line escape character inside string literals
> -
>
> Key: CASSANDRA-8705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8705
> Project: Cassandra
> Issue Type: Bug
>Reporter: mlowicki
> Labels: cqlsh
>
> {code}
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=
> ... ';
> count
> ---
> 1
> (1 rows)
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=\n';
> count
> ---
> 0
> (1 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8382) Procedure to Change IP Address without Data streaming is Missing in Cassandra Documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298995#comment-14298995 ] Anuj commented on CASSANDRA-8382: - Thanks > Procedure to Change IP Address without Data streaming is Missing in Cassandra > Documentation > --- > > Key: CASSANDRA-8382 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8382 > Project: Cassandra > Issue Type: Bug > Components: Documentation & website > Environment: Red Hat Linux , Cassandra 2.0.3 >Reporter: Anuj > > Use Case: > We have a Geo-Red setup with 2 DCs (DC1 and DC2) having 3 nodes each. Listen > address and seeds of all nodes are Public IPs while rpc addresses are private > IPs. Now, we want to decommission a DC2 and change public IPs in listen > address/seeds of DC1 nodes to private IPs as it will be a single DC setup. > Issue: > Cassandra doesn’t provide any standard procedure for changing IP address of > nodes in a cluster. We can bring down nodes, one by one, change their IP > address and perform the procedure mentioned in “ Replacing a Dead Node” at > http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_node_t.html > by mentioning public IP of the node in replace_address option. But > procedure recommends that you must set the auto_bootstrap option to true. We > don’t want any bootstrap and data streaming to happen as data is already > there on nodes. So, our questions is : What’s the standard procedure for > changing IP address of Cassandra nodes while making sure that no data > streaming occurs and gossip state is not corrupted. > We are using vnodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8382) Procedure to Change IP Address without Data streaming is Missing in Cassandra Documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298993#comment-14298993 ] Anuj commented on CASSANDRA-8382: - Just bouncing C* didnt remove old IPs. We finally cleared gossip state on all nodes by adding following line at end of cassandra-env.sh: JVM_OPTS="$JVM_OPTS -Dcassandra.load_ring_state=false" This solved our issue. I hope the procedure is correct and we need not clear gossip info by other methods e.g. sudo rm -r /var/lib/cassandra/data/system/peers/* or executing Gossiper.unsafeAssassinateEndpoints(ip_address) via JConsole as mentioned at http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_gossip_purge.html > Procedure to Change IP Address without Data streaming is Missing in Cassandra > Documentation > --- > > Key: CASSANDRA-8382 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8382 > Project: Cassandra > Issue Type: Bug > Components: Documentation & website > Environment: Red Hat Linux , Cassandra 2.0.3 >Reporter: Anuj > > Use Case: > We have a Geo-Red setup with 2 DCs (DC1 and DC2) having 3 nodes each. Listen > address and seeds of all nodes are Public IPs while rpc addresses are private > IPs. Now, we want to decommission a DC2 and change public IPs in listen > address/seeds of DC1 nodes to private IPs as it will be a single DC setup. > Issue: > Cassandra doesn’t provide any standard procedure for changing IP address of > nodes in a cluster. We can bring down nodes, one by one, change their IP > address and perform the procedure mentioned in “ Replacing a Dead Node” at > http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_node_t.html > by mentioning public IP of the node in replace_address option. But > procedure recommends that you must set the auto_bootstrap option to true. We > don’t want any bootstrap and data streaming to happen as data is already > there on nodes. So, our questions is : What’s the standard procedure for > changing IP address of Cassandra nodes while making sure that no data > streaming occurs and gossip state is not corrupted. > We are using vnodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8687) Keyspace should also check Config.isClientMode
[ https://issues.apache.org/jira/browse/CASSANDRA-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-8687: --- Reviewer: Yuki Morishita > Keyspace should also check Config.isClientMode > -- > > Key: CASSANDRA-8687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8687 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Jeremiah Jordan >Priority: Minor > Fix For: 2.0.13 > > Attachments: > 0001-Fix-isClientMode-check-in-Keyspace-to-also-check-Confi.txt > > > Keyspace static init code should check Config.isClientMode as well as > checking StorageService.instance.isClientMode() before trying to make > directories. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8687) Keyspace should also check Config.isClientMode
[ https://issues.apache.org/jira/browse/CASSANDRA-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan reassigned CASSANDRA-8687: -- Assignee: Jeremiah Jordan > Keyspace should also check Config.isClientMode > -- > > Key: CASSANDRA-8687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8687 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Jeremiah Jordan >Assignee: Jeremiah Jordan >Priority: Minor > Fix For: 2.0.13 > > Attachments: > 0001-Fix-isClientMode-check-in-Keyspace-to-also-check-Confi.txt > > > Keyspace static init code should check Config.isClientMode as well as > checking StorageService.instance.isClientMode() before trying to make > directories. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8687) Keyspace should also check Config.isClientMode
[ https://issues.apache.org/jira/browse/CASSANDRA-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-8687: --- Fix Version/s: (was: 2.1.3) > Keyspace should also check Config.isClientMode > -- > > Key: CASSANDRA-8687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8687 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Jeremiah Jordan >Priority: Minor > Fix For: 2.0.13 > > Attachments: > 0001-Fix-isClientMode-check-in-Keyspace-to-also-check-Confi.txt > > > Keyspace static init code should check Config.isClientMode as well as > checking StorageService.instance.isClientMode() before trying to make > directories. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Generalize IN to compound partition keys
Repository: cassandra
Updated Branches:
refs/heads/trunk 24a189ca6 -> 2e4ad069d
Generalize IN to compound partition keys
patch by blerer; reviewed by beobal for CASSANDRA-7855
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2e4ad069
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2e4ad069
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2e4ad069
Branch: refs/heads/trunk
Commit: 2e4ad069d552167d0fc06d39bc8d622573f14792
Parents: 24a189c
Author: Benjamin Lerer
Authored: Fri Jan 30 19:05:35 2015 +0100
Committer: Sylvain Lebresne
Committed: Fri Jan 30 19:05:35 2015 +0100
--
CHANGES.txt | 1 +
.../cassandra/cql3/SingleColumnRelation.java| 20 +
.../cql3/SingleColumnRelationTest.java | 31 ++--
3 files changed, 30 insertions(+), 22 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e4ad069/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fd3510c..c7c9434 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -33,6 +33,7 @@
* Remove cassandra-cli (CASSANDRA-7920)
* Accept dollar quoted strings in CQL (CASSANDRA-7769)
* Make assassinate a first class command (CASSANDRA-7935)
+ * Support IN clause on any partition key column (CASSANDRA-7855)
* Support IN clause on any clustering column (CASSANDRA-4762)
* Improve compaction logging (CASSANDRA-7818)
* Remove YamlFileNetworkTopologySnitch (CASSANDRA-7917)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e4ad069/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index 3db1195..78b4d5d 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -203,11 +203,6 @@ public final class SingleColumnRelation extends Relation
if (isIN())
{
-// For partition keys we only support IN for the last name so far
-checkFalse(columnDef.isPartitionKey() && !isLastPartitionKey(cfm,
columnDef),
- "Partition KEY part %s cannot be restricted by IN
relation (only the last part of the partition key can)",
- columnDef.name);
-
// We only allow IN on the row key and the clustering key so far,
never on non-PK columns, and this even if
// there's an index
// Note: for backward compatibility reason, we conside a IN of 1
value the same as a EQ, so we let that
@@ -262,7 +257,7 @@ public final class SingleColumnRelation extends Relation
return Collections.singletonList(receiver);
}
-private ColumnSpecification makeCollectionReceiver(ColumnSpecification
receiver, boolean forKey)
+private static ColumnSpecification
makeCollectionReceiver(ColumnSpecification receiver, boolean forKey)
{
return ((CollectionType)
receiver.type).makeCollectionReceiver(receiver, forKey);
}
@@ -277,19 +272,6 @@ public final class SingleColumnRelation extends Relation
return mapKey != null && isEQ();
}
-/**
- * Checks if the specified column is the last column of the partition key.
- *
- * @param cfm the column family meta data
- * @param columnDef the column to check
- * @return true if the specified column is the last column of
the partition key, false
- * otherwise.
- */
-private static boolean isLastPartitionKey(CFMetaData cfm, ColumnDefinition
columnDef)
-{
-return columnDef.position() == cfm.partitionKeyColumns().size() - 1;
-}
-
private boolean canHaveOnlyOneValue()
{
return isEQ() || (isIN() && inValues != null && inValues.size() == 1);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e4ad069/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
b/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
index f505a04..4e4cc50 100644
--- a/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
+++ b/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
@@ -175,18 +175,43 @@ public class SingleColumnRelationTest extends CQLTester
execute("insert into %s (a, b, c, d) values (?, ?, ?, ?)", "first", 1,
1, 1);
execute("insert into %s (a, b, c, d) values (?, ?, ?, ?)", "first", 2,
2, 2);
execute("insert into %s (a,
[jira] [Created] (CASSANDRA-8709) Convert SequentialWriter from using RandomAccessFile to nio channel
Joshua McKenzie created CASSANDRA-8709: -- Summary: Convert SequentialWriter from using RandomAccessFile to nio channel Key: CASSANDRA-8709 URL: https://issues.apache.org/jira/browse/CASSANDRA-8709 Project: Cassandra Issue Type: Improvement Reporter: Joshua McKenzie Assignee: Joshua McKenzie Fix For: 3.0 For non-mmap'ed I/O on Windows, using nio channels will give us substantially more flexibility w/regards to renaming and moving files around while writing them. This change in conjunction with CASSANDRA-4050 should allow us to remove the Windows bypass code in SSTableRewriter for non-memory-mapped I/O. In general, migrating from instances of RandomAccessFile to nio channels will help make Windows and linux behavior more consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Fix version check on CommitLogArchiver restore
Repository: cassandra
Updated Branches:
refs/heads/trunk 0b324c5e5 -> 24a189ca6
Fix version check on CommitLogArchiver restore
Patch by jmckenzie; reviewed by Sam Tunnicliffe for CASSANDRA-8293
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/24a189ca
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/24a189ca
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/24a189ca
Branch: refs/heads/trunk
Commit: 24a189ca6d2279f67ce88c28aeee5a2683ff8fbb
Parents: 0b324c5
Author: Joshua McKenzie
Authored: Fri Jan 30 11:52:17 2015 -0600
Committer: Joshua McKenzie
Committed: Fri Jan 30 11:52:17 2015 -0600
--
src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/24a189ca/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
index 6cba603..26468d4 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
@@ -211,7 +211,7 @@ public class CommitLogArchiver
descriptor = fromHeader;
else descriptor = fromName;
-if (descriptor.version > CommitLogDescriptor.VERSION_21)
+if (descriptor.version > CommitLogDescriptor.VERSION_30)
throw new IllegalStateException("Unsupported commit log
version: " + descriptor.version);
File toFile = new
File(DatabaseDescriptor.getCommitLogLocation(), descriptor.fileName());
[jira] [Assigned] (CASSANDRA-7094) Keyspace name quoting is handled inconsistently and strangely
[
https://issues.apache.org/jira/browse/CASSANDRA-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs reassigned CASSANDRA-7094:
--
Assignee: Tyler Hobbs
> Keyspace name quoting is handled inconsistently and strangely
> --
>
> Key: CASSANDRA-7094
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7094
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: cassandra 1.2.16
>Reporter: Karl Mueller
>Assignee: Tyler Hobbs
>Priority: Trivial
>
> Keyspaces which are named starting with capital letters (and perhaps other
> things) sometimes require double quotes and sometimes do not.
> For example, describe works without quotes:
> cqlsh> describe keyspace ProductGenomeLocal;
> CREATE KEYSPACE "ProductGenomeLocal" WITH replication = {
> 'class': 'SimpleStrategy',
> 'replication_factor': '3'
> };
> USE "ProductGenomeLocal";
> [...]
> But use will not:
> cqlsh> use ProductGenomeLocal;
> Bad Request: Keyspace 'productgenomelocal' does not exist
> It seems that qoutes should only really be necessary when there's spaces or
> other symbols that need to be quoted.
> At the least, the acceptance or failures of quotes should be consistent.
> Other minor annoyance: tab expansion works in use and describe with quotes,
> but will not work in either without quotes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8610) Allow IF EXISTS for UPDATE statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-8610:
---
Reviewer: Tyler Hobbs
> Allow IF EXISTS for UPDATE statements
> -
>
> Key: CASSANDRA-8610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8610
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: Cassandra 2.1.2
>Reporter: DOAN DuyHai
>Priority: Minor
> Attachments: 8610.patch
>
>
> While creating a hands-on exercice for Cassandra, I was facing a quite
> annoying limitation.
> Let's take this table:
> {code:sql}
> CREATE TABLE killrchat.chat_rooms(
> room_name text,
> creation_date timestamp,
> banner text,
> creator text,
> participants set,
> PRIMARY KEY(room_name));
> {code}
> Upon a new participant joining the room, to be concurrency-proof (avoiding
> mutating the participants set if the room is deleted concurrently), I would
> like to issue this query:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF EXISTS;
> {code}
> Unfortunately the clause IF EXISTS is not allowed for UPDATE statements.
> Similarly I tried
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF room_name='games';
> {code}
> It doesn't work either, it is not allowed to use one column of the primary
> key as condition column for LWT (why ? mystery).
> So far, the only work-around I found is:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF name='games';
> {code}
> I added an extra column called *name* which is just the duplicate of the
> partition key *room_name*. It does work but is not very elegant.
> I believe there are legit use cases for UPDATE ... IF EXISTS;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8418) Queries that require allow filtering are working without it
[
https://issues.apache.org/jira/browse/CASSANDRA-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298907#comment-14298907
]
Tyler Hobbs commented on CASSANDRA-8418:
I think you want {{NEWS.txt}}, not {{CHANGES.txt}}.
> Queries that require allow filtering are working without it
> ---
>
> Key: CASSANDRA-8418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8418
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.0
>
> Attachments: CASSANDRA-8418.txt
>
>
> The trunk dtest {{cql_tests.py:TestCQL.composite_index_with_pk_test}} has
> begun failing after the changes to CASSANDRA-7981.
> With the schema {code}CREATE TABLE blogs (
> blog_id int,
> time1 int,
> time2 int,
> author text,
> content text,
> PRIMARY KEY (blog_id, time1, time2){code}
> and {code}CREATE INDEX ON blogs(author){code}, then the query
> {code}SELECT blog_id, content FROM blogs WHERE time1 > 0 AND
> author='foo'{code} now requires ALLOW FILTERING, but did not before the
> refactor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6809) Compressed Commit Log
[ https://issues.apache.org/jira/browse/CASSANDRA-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298891#comment-14298891 ] Branimir Lambov commented on CASSANDRA-6809: Added a stress test exercising all log options to the long test suite and fixed several issues: - Initialization could fail with NPE or similar as some threads started within the CommitLog constructor could use fields which weren't initialized yet. - Made sure the length of sync sections is precise; replay could read beyond the end of the file or read stale mutations from reused compressed buffers when the length is not precise. - Made sure completed segment files are always closed. > Compressed Commit Log > - > > Key: CASSANDRA-6809 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6809 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Branimir Lambov >Priority: Minor > Labels: performance > Fix For: 3.0 > > Attachments: ComitLogStress.java, logtest.txt > > > It seems an unnecessary oversight that we don't compress the commit log. > Doing so should improve throughput, but some care will need to be taken to > ensure we use as much of a segment as possible. I propose decoupling the > writing of the records from the segments. Basically write into a (queue of) > DirectByteBuffer, and have the sync thread compress, say, ~64K chunks every X > MB written to the CL (where X is ordinarily CLS size), and then pack as many > of the compressed chunks into a CLS as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8707) Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted
[ https://issues.apache.org/jira/browse/CASSANDRA-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-8707: --- Reviewer: Marcus Eriksson > Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted > > > Key: CASSANDRA-8707 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8707 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict > Fix For: 2.1.3 > > > There are still a few bugs with resource management, especially around > SSTableReader cleanup, esp. when intermixing with compaction. This migration > should help. We can simultaneously "simplify" the logic in SSTableReader to > not track the replacement chain, only to take a new reference to each of the > underlying resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8685) Consider upgrade to thrift 0.9.2 (or later)
[ https://issues.apache.org/jira/browse/CASSANDRA-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8685: -- Priority: Minor (was: Major) > Consider upgrade to thrift 0.9.2 (or later) > --- > > Key: CASSANDRA-8685 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8685 > Project: Cassandra > Issue Type: Improvement >Reporter: Adam Hattrell >Assignee: T Jake Luciani >Priority: Minor > Fix For: 2.1.3 > > Attachments: thrift1457fix_cassandra_heap.png, > thrift1457fix_cassandra_heap_framedtransport.png > > > Folks using Astyanax and the like are subject to > https://issues.apache.org/jira/browse/THRIFT-1457 and may run into heap > pressure on the Cassandra side for larger read request, as thrift doesn't > reset its internal buffer. This can lead to larger TFramedTransport > instances will be kept on the heap. > I've seen at least one situation where this has saved around 1Gb of heap > space on average. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8685) Consider upgrade to thrift 0.9.2 (or later)
[ https://issues.apache.org/jira/browse/CASSANDRA-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8685: -- Issue Type: Improvement (was: Bug) > Consider upgrade to thrift 0.9.2 (or later) > --- > > Key: CASSANDRA-8685 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8685 > Project: Cassandra > Issue Type: Improvement >Reporter: Adam Hattrell >Assignee: T Jake Luciani > Fix For: 2.1.3 > > Attachments: thrift1457fix_cassandra_heap.png, > thrift1457fix_cassandra_heap_framedtransport.png > > > Folks using Astyanax and the like are subject to > https://issues.apache.org/jira/browse/THRIFT-1457 and may run into heap > pressure on the Cassandra side for larger read request, as thrift doesn't > reset its internal buffer. This can lead to larger TFramedTransport > instances will be kept on the heap. > I've seen at least one situation where this has saved around 1Gb of heap > space on average. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Conflicts: build.xml Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0b324c5e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0b324c5e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0b324c5e Branch: refs/heads/trunk Commit: 0b324c5e5575b6d86f7b57969e203fe80b3f6f80 Parents: caa0359 cdcf646 Author: T Jake Luciani Authored: Fri Jan 30 12:02:42 2015 -0500 Committer: T Jake Luciani Committed: Fri Jan 30 12:02:42 2015 -0500 -- CHANGES.txt | 1 + build.xml| 2 +- lib/libthrift-0.9.1.jar | Bin 217054 -> 0 bytes lib/libthrift-0.9.2.jar | Bin 0 -> 227712 bytes lib/licenses/libthrift-0.9.1.txt | 202 -- lib/licenses/libthrift-0.9.2.txt | 202 ++ 6 files changed, 204 insertions(+), 203 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b324c5e/CHANGES.txt -- diff --cc CHANGES.txt index 21d06c3,92c1a17..fd3510c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,62 -1,5 +1,63 @@@ +3.0 + * Avoid accessing partitioner through StorageProxy (CASSANDRA-8244, 8268) + * Upgrade Metrics library and remove depricated metrics (CASSANDRA-5657) + * Serializing Row cache alternative, fully off heap (CASSANDRA-7438) + * Duplicate rows returned when in clause has repeated values (CASSANDRA-6707) + * Make CassandraException unchecked, extend RuntimeException (CASSANDRA-8560) + * Support direct buffer decompression for reads (CASSANDRA-8464) + * DirectByteBuffer compatible LZ4 methods (CASSANDRA-7039) + * Add role based access control (CASSANDRA-7653) + * Group sstables for anticompaction correctly (CASSANDRA-8578) + * Add ReadFailureException to native protocol, respond + immediately when replicas encounter errors while handling + a read request (CASSANDRA-7886) + * Switch CommitLogSegment from RandomAccessFile to nio (CASSANDRA-8308) + * Allow mixing token and partition key restrictions (CASSANDRA-7016) + * Support index key/value entries on map collections (CASSANDRA-8473) + * Modernize schema tables (CASSANDRA-8261) + * Support for user-defined aggregation functions (CASSANDRA-8053) + * Fix NPE in SelectStatement with empty IN values (CASSANDRA-8419) + * Refactor SelectStatement, return IN results in natural order instead + of IN value list order and ignore duplicate values in partition key IN restrictions (CASSANDRA-7981) + * Support UDTs, tuples, and collections in user-defined + functions (CASSANDRA-7563) + * Fix aggregate fn results on empty selection, result column name, + and cqlsh parsing (CASSANDRA-8229) + * Mark sstables as repaired after full repair (CASSANDRA-7586) + * Extend Descriptor to include a format value and refactor reader/writer + APIs (CASSANDRA-7443) + * Integrate JMH for microbenchmarks (CASSANDRA-8151) + * Keep sstable levels when bootstrapping (CASSANDRA-7460) + * Add Sigar library and perform basic OS settings check on startup (CASSANDRA-7838) + * Support for aggregation functions (CASSANDRA-4914) + * Remove cassandra-cli (CASSANDRA-7920) + * Accept dollar quoted strings in CQL (CASSANDRA-7769) + * Make assassinate a first class command (CASSANDRA-7935) + * Support IN clause on any clustering column (CASSANDRA-4762) + * Improve compaction logging (CASSANDRA-7818) + * Remove YamlFileNetworkTopologySnitch (CASSANDRA-7917) + * Do anticompaction in groups (CASSANDRA-6851) + * Support user-defined functions (CASSANDRA-7395, 7526, 7562, 7740, 7781, 7929, + 7924, 7812, 8063, 7813, 7708) + * Permit configurable timestamps with cassandra-stress (CASSANDRA-7416) + * Move sstable RandomAccessReader to nio2, which allows using the + FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050) + * Remove CQL2 (CASSANDRA-5918) + * Add Thrift get_multi_slice call (CASSANDRA-6757) + * Optimize fetching multiple cells by name (CASSANDRA-6933) + * Allow compilation in java 8 (CASSANDRA-7028) + * Make incremental repair default (CASSANDRA-7250) + * Enable code coverage thru JaCoCo (CASSANDRA-7226) + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) + * Shorten SSTable path (CASSANDRA-6962) + * Use unsafe mutations for most unit tests (CASSANDRA-6969) + * Fix race condition during calculation of pending ranges (CASSANDRA-7390) + * Fail on very large batch sizes (CASSANDRA-8011) + * Improve concurrency of repair (CASSANDRA-6455, 8208) + + 2.1.3 + * Upgrade libthrift to 0.9.2 (CASSANDRA-8685) * Don't use the shared ref in sstableloader (CASSANDRA-8704) * Purge internal prepared statements if related tables or keyspaces ar
[1/2] cassandra git commit: Upgrade thrift to 0.9.2
Repository: cassandra Updated Branches: refs/heads/trunk caa035955 -> 0b324c5e5 Upgrade thrift to 0.9.2 Patch by tjake; reviewed by Philip Thompson for CASSANDRA-8685 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cdcf6461 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cdcf6461 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cdcf6461 Branch: refs/heads/trunk Commit: cdcf6461a309a4d8b6e4be1dc56cba453eef0d45 Parents: f123253 Author: T Jake Luciani Authored: Thu Jan 29 11:13:30 2015 -0500 Committer: T Jake Luciani Committed: Fri Jan 30 09:46:02 2015 -0500 -- CHANGES.txt | 1 + build.xml| 2 +- lib/libthrift-0.9.1.jar | Bin 217054 -> 0 bytes lib/libthrift-0.9.2.jar | Bin 0 -> 227712 bytes lib/licenses/libthrift-0.9.1.txt | 202 -- lib/licenses/libthrift-0.9.2.txt | 202 ++ 6 files changed, 204 insertions(+), 203 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 5113e07..92c1a17 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.1.3 + * Upgrade libthrift to 0.9.2 (CASSANDRA-8685) * Don't use the shared ref in sstableloader (CASSANDRA-8704) * Purge internal prepared statements if related tables or keyspaces are dropped (CASSANDRA-8693) http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/build.xml -- diff --git a/build.xml b/build.xml index d53a0f7..0aa8c01 100644 --- a/build.xml +++ b/build.xml @@ -374,7 +374,7 @@ - + http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/lib/libthrift-0.9.1.jar -- diff --git a/lib/libthrift-0.9.1.jar b/lib/libthrift-0.9.1.jar deleted file mode 100644 index 827ed00..000 Binary files a/lib/libthrift-0.9.1.jar and /dev/null differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/lib/libthrift-0.9.2.jar -- diff --git a/lib/libthrift-0.9.2.jar b/lib/libthrift-0.9.2.jar new file mode 100644 index 000..39143a5 Binary files /dev/null and b/lib/libthrift-0.9.2.jar differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/lib/licenses/libthrift-0.9.1.txt -- diff --git a/lib/licenses/libthrift-0.9.1.txt b/lib/licenses/libthrift-0.9.1.txt deleted file mode 100644 index d645695..000 --- a/lib/licenses/libthrift-0.9.1.txt +++ /dev/null @@ -1,202 +0,0 @@ - - Apache License - Version 2.0, January 2004 -http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shal
cassandra git commit: Upgrade thrift to 0.9.2
Repository: cassandra Updated Branches: refs/heads/cassandra-2.1 f1232532e -> cdcf6461a Upgrade thrift to 0.9.2 Patch by tjake; reviewed by Philip Thompson for CASSANDRA-8685 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cdcf6461 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cdcf6461 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cdcf6461 Branch: refs/heads/cassandra-2.1 Commit: cdcf6461a309a4d8b6e4be1dc56cba453eef0d45 Parents: f123253 Author: T Jake Luciani Authored: Thu Jan 29 11:13:30 2015 -0500 Committer: T Jake Luciani Committed: Fri Jan 30 09:46:02 2015 -0500 -- CHANGES.txt | 1 + build.xml| 2 +- lib/libthrift-0.9.1.jar | Bin 217054 -> 0 bytes lib/libthrift-0.9.2.jar | Bin 0 -> 227712 bytes lib/licenses/libthrift-0.9.1.txt | 202 -- lib/licenses/libthrift-0.9.2.txt | 202 ++ 6 files changed, 204 insertions(+), 203 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 5113e07..92c1a17 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.1.3 + * Upgrade libthrift to 0.9.2 (CASSANDRA-8685) * Don't use the shared ref in sstableloader (CASSANDRA-8704) * Purge internal prepared statements if related tables or keyspaces are dropped (CASSANDRA-8693) http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/build.xml -- diff --git a/build.xml b/build.xml index d53a0f7..0aa8c01 100644 --- a/build.xml +++ b/build.xml @@ -374,7 +374,7 @@ - + http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/lib/libthrift-0.9.1.jar -- diff --git a/lib/libthrift-0.9.1.jar b/lib/libthrift-0.9.1.jar deleted file mode 100644 index 827ed00..000 Binary files a/lib/libthrift-0.9.1.jar and /dev/null differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/lib/libthrift-0.9.2.jar -- diff --git a/lib/libthrift-0.9.2.jar b/lib/libthrift-0.9.2.jar new file mode 100644 index 000..39143a5 Binary files /dev/null and b/lib/libthrift-0.9.2.jar differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/cdcf6461/lib/licenses/libthrift-0.9.1.txt -- diff --git a/lib/licenses/libthrift-0.9.1.txt b/lib/licenses/libthrift-0.9.1.txt deleted file mode 100644 index d645695..000 --- a/lib/licenses/libthrift-0.9.1.txt +++ /dev/null @@ -1,202 +0,0 @@ - - Apache License - Version 2.0, January 2004 -http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Deriva
[jira] [Commented] (CASSANDRA-8418) Queries that require allow filtering are working without it
[
https://issues.apache.org/jira/browse/CASSANDRA-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298821#comment-14298821
]
Benjamin Lerer commented on CASSANDRA-8418:
---
It make sense. I will do it like that.
> Queries that require allow filtering are working without it
> ---
>
> Key: CASSANDRA-8418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8418
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.0
>
> Attachments: CASSANDRA-8418.txt
>
>
> The trunk dtest {{cql_tests.py:TestCQL.composite_index_with_pk_test}} has
> begun failing after the changes to CASSANDRA-7981.
> With the schema {code}CREATE TABLE blogs (
> blog_id int,
> time1 int,
> time2 int,
> author text,
> content text,
> PRIMARY KEY (blog_id, time1, time2){code}
> and {code}CREATE INDEX ON blogs(author){code}, then the query
> {code}SELECT blog_id, content FROM blogs WHERE time1 > 0 AND
> author='foo'{code} now requires ALLOW FILTERING, but did not before the
> refactor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8061) tmplink files are not removed
[
https://issues.apache.org/jira/browse/CASSANDRA-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298816#comment-14298816
]
Benedict commented on CASSANDRA-8061:
-
OK, that's not entirely unexpected. That would be the bug that was being
suppressed.
That bug I expect to be fixed by CASSANDRA-8707. There is another uncommon bug
related to compaction of LCS in CASSANDRA-8683 that I should have a patch for
by sometime on Monday. I expect between those two we should have either (1) no
bug; or (2) all of the information necessary to discover the bug and promptly
fix it.
> tmplink files are not removed
> -
>
> Key: CASSANDRA-8061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8061
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux
>Reporter: Gianluca Borello
>Assignee: Joshua McKenzie
> Fix For: 2.1.3
>
> Attachments: 8061_v1.txt, 8248-thread_dump.txt
>
>
> After installing 2.1.0, I'm experiencing a bunch of tmplink files that are
> filling my disk. I found https://issues.apache.org/jira/browse/CASSANDRA-7803
> and that is very similar, and I confirm it happens both on 2.1.0 as well as
> from the latest commit on the cassandra-2.1 branch
> (https://github.com/apache/cassandra/commit/aca80da38c3d86a40cc63d9a122f7d45258e4685
> from the cassandra-2.1)
> Even starting with a clean keyspace, after a few hours I get:
> {noformat}
> $ sudo find /raid0 | grep tmplink | xargs du -hs
> 2.7G
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Data.db
> 13M
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Index.db
> 1.8G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Data.db
> 12M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Index.db
> 5.2M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Index.db
> 822M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Data.db
> 7.3M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Index.db
> 1.2G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Data.db
> 6.7M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Index.db
> 1.1G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Data.db
> 11M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Index.db
> 1.7G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Data.db
> 812K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Index.db
> 122M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-208-Data.db
> 744K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-739-Index.db
> 660K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Index.db
> 796K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Index.db
> 137M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Data.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Data.db
> 139M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Data.db
> 940K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Index.db
> 936K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Index.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Data.db
> 672K
> /raid0/cassandra/data/draios/mounted_fs_b
[jira] [Created] (CASSANDRA-8708) inter_dc_stream_throughput_outbound_megabits_per_sec seems to default to 0 (unlimited)
Adam Hattrell created CASSANDRA-8708: Summary: inter_dc_stream_throughput_outbound_megabits_per_sec seems to default to 0 (unlimited) Key: CASSANDRA-8708 URL: https://issues.apache.org/jira/browse/CASSANDRA-8708 Project: Cassandra Issue Type: Bug Reporter: Adam Hattrell inter_dc_stream_throughput_outbound_megabits_per_sec was introduced in CASSANDRA-6596. There's some discussion in the ticket of the intention to link the default to whatever stream_throughput_outbound_megabits_per_sec is set to. However, it looks like it's just set to 0 - from /src/java/org/apache/cassandra/config/Config.java This is a bit of a pain - usually folks want to set the inter dc limits lower than the base streaming figure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8707) Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted
[ https://issues.apache.org/jira/browse/CASSANDRA-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298807#comment-14298807 ] Benedict commented on CASSANDRA-8707: - I've uploaded a patch [here|https://github.com/belliottsmith/cassandra/tree/8707-safercleanup] There are a couple of minor semi-extraneous commits tweaking slightly the design just introduced in 7705, in particular: * introducing a ref() method for those instances where we expect never to fail * Letting Ref and RefCounted hold a reference to the thing they're counting, so that Ref.referent() can be supported The patch itself then has some ground works: * Encapsulate SSTableReader.readMeter, so it isn't accessed directly * Introduce a new SharedCloseable interface that represents a Closeable that can be shared by creating a new instance via sharedCopy(); each instance can treated as distinct, but the underlying resources will only be closed once all of them are. it is backed by RefCounted, and just provides a convenient abstraction. * Make IndexSummary, IFilter and SegmentedFile implement SharedCloseable Finally we do the guts of the patch, which is refactoring the cleanup in SSTableReader so that instead of maintaining a chain of replacements, we have three tiers of resource management: instance-only, type-shared (TEMPLINK/FINAL), and global. Each have their own reference count managed to ensure safe cleanup. The instance-only fields include the major ones: dfile, ifile, summary and filter, as these are all managed directly via SharedCloseable. The type-shared and global manage general cleanup, such as dropping page cache, trashing read meter data, deleting files, etc. Hopefully only the last bit is the only that requires considerable attention, and whilst it is a little verbose the logic should be much easier to understand the before, and hence much safer. It will also give us all of the new debug info if we get it wrong. This patch exposes a number of new LEAK DETECTED warnings in unit tests which I want to work through, but I suspect mostly are down to creating and discarding sstables directly in the test methods. > Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted > > > Key: CASSANDRA-8707 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8707 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict > Fix For: 2.1.3 > > > There are still a few bugs with resource management, especially around > SSTableReader cleanup, esp. when intermixing with compaction. This migration > should help. We can simultaneously "simplify" the logic in SSTableReader to > not track the replacement chain, only to take a new reference to each of the > underlying resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8418) Queries that require allow filtering are working without it
[
https://issues.apache.org/jira/browse/CASSANDRA-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298775#comment-14298775
]
Sylvain Lebresne commented on CASSANDRA-8418:
-
{quote}
unless we specify the query that should required {{ALLOW FILTERING}} in the
message, the warning is a bit useless.
documenting the change in the {{CHANGES.txt}} file for 3.0
{quote}
Why not have a warning that use whatever you planned to put in the
{{CHANGES.txt}} file? The goal is to make it more likely that user won't be
surprised of the change once they update to 3.0, and believe it or not, people
don't always read the changelog (not saying they always read their log btw,
that's why I'm advocating having the warning in multiple places). It's true
that without the query user will have a harder time finding out which queries
are responsible, but making them aware of the issue is still better than
nothing imo (note that we can absolutely link to this issue in the warning
message).
> Queries that require allow filtering are working without it
> ---
>
> Key: CASSANDRA-8418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8418
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.0
>
> Attachments: CASSANDRA-8418.txt
>
>
> The trunk dtest {{cql_tests.py:TestCQL.composite_index_with_pk_test}} has
> begun failing after the changes to CASSANDRA-7981.
> With the schema {code}CREATE TABLE blogs (
> blog_id int,
> time1 int,
> time2 int,
> author text,
> content text,
> PRIMARY KEY (blog_id, time1, time2){code}
> and {code}CREATE INDEX ON blogs(author){code}, then the query
> {code}SELECT blog_id, content FROM blogs WHERE time1 > 0 AND
> author='foo'{code} now requires ALLOW FILTERING, but did not before the
> refactor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8706) Make it possible to configure different compaction strategies for repaired and unrepaired data
[ https://issues.apache.org/jira/browse/CASSANDRA-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8706: -- Priority: Minor (was: Major) bq. We should make it possible for users to configure different strategies for the different sets of data Is there a real-world use case driving this, or is it just for the sake of flexibility? > Make it possible to configure different compaction strategies for repaired > and unrepaired data > -- > > Key: CASSANDRA-8706 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8706 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Priority: Minor > Fix For: 3.0 > > > In CASSANDRA-8004 we introduced WrappingCompactionStrategy which handles > repaired and unrepaired sstables for compaction - it acts as there is still a > single compaction strategy, but underneath it runs 2 different instances of > the configured strategy. Main purpose of this was to remove any duplicated > repaired/unrepaired logic from the actual compaction strategies and collect > them in one place. > We should make it possible for users to configure different strategies for > the different sets of data - if a user wants to run STCS on unrepaired data > and LCS on repaired, it should be possible. > This ticket includes replacing WrappingCompactionStrategy with something that > does not extend AbstractCompactionStrategy as that part is quite confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8606) sstablesplit does not remove original sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-8606: --- Priority: Major (was: Minor) > sstablesplit does not remove original sstable > - > > Key: CASSANDRA-8606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8606 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 2.1.3 > > > sstablesplit leaves the original file on disk, it should not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8606) sstablesplit does not remove original sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298760#comment-14298760 ] J.B. Langston commented on CASSANDRA-8606: -- This also affects offline sstableupgrade. I'd say this should be a higher priority since people could fill up their disks during an upgrade. > sstablesplit does not remove original sstable > - > > Key: CASSANDRA-8606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8606 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Minor > Fix For: 2.1.3 > > > sstablesplit leaves the original file on disk, it should not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8418) Queries that require allow filtering are working without it
[
https://issues.apache.org/jira/browse/CASSANDRA-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298746#comment-14298746
]
Benjamin Lerer commented on CASSANDRA-8418:
---
[~slebresne], [~thobbs] what do you think?
> Queries that require allow filtering are working without it
> ---
>
> Key: CASSANDRA-8418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8418
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.0
>
> Attachments: CASSANDRA-8418.txt
>
>
> The trunk dtest {{cql_tests.py:TestCQL.composite_index_with_pk_test}} has
> begun failing after the changes to CASSANDRA-7981.
> With the schema {code}CREATE TABLE blogs (
> blog_id int,
> time1 int,
> time2 int,
> author text,
> content text,
> PRIMARY KEY (blog_id, time1, time2){code}
> and {code}CREATE INDEX ON blogs(author){code}, then the query
> {code}SELECT blog_id, content FROM blogs WHERE time1 > 0 AND
> author='foo'{code} now requires ALLOW FILTERING, but did not before the
> refactor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8685) Consider upgrade to thrift 0.9.2 (or later)
[ https://issues.apache.org/jira/browse/CASSANDRA-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298741#comment-14298741 ] Philip Thompson commented on CASSANDRA-8685: +1 for inclusion in 2.1, as no dtests are broken by the change. > Consider upgrade to thrift 0.9.2 (or later) > --- > > Key: CASSANDRA-8685 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8685 > Project: Cassandra > Issue Type: Bug >Reporter: Adam Hattrell >Assignee: T Jake Luciani > Fix For: 2.1.3 > > Attachments: thrift1457fix_cassandra_heap.png, > thrift1457fix_cassandra_heap_framedtransport.png > > > Folks using Astyanax and the like are subject to > https://issues.apache.org/jira/browse/THRIFT-1457 and may run into heap > pressure on the Cassandra side for larger read request, as thrift doesn't > reset its internal buffer. This can lead to larger TFramedTransport > instances will be kept on the heap. > I've seen at least one situation where this has saved around 1Gb of heap > space on average. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8693) QueryProcessor never removes internal statements from its cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298740#comment-14298740
]
Edward Ribeiro edited comment on CASSANDRA-8693 at 1/30/15 3:20 PM:
Hi Tyler, thanks! :)
+1 for leaving the tests out. Agree.
was (Author: eribeiro):
Hi Tyler, thanks! :)
> QueryProcessor never removes internal statements from its cache
> ---
>
> Key: CASSANDRA-8693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
> Labels: cql3
> Fix For: 2.1.3
>
> Attachments: qp-internal.patch
>
>
> QueryProcessor holds a reference to {{internalStatements}}, a map for
> prepared statements used internally.
> Those commands don't mix with the ones created by the user, but the problem
> is that if a KS/CF is dropped and then recreated {{internalStatements}}
> entries will point to invalid PreparedStatements (old cf_id) so any operation
> on those statements will fail thereafter. In fact, as of today, this map is
> never actually cleaned, no matter what.
> This problem is similar to the ones addressed by
> https://issues.apache.org/jira/browse/CASSANDRA-8652 and
> https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
> any further context.
> I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7855) Genralize use of IN for compound partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-7855:
--
Attachment: CASSANDRA-7855-V2.txt
I added the missing test.
Thanks for the review.
> Genralize use of IN for compound partition keys
> ---
>
> Key: CASSANDRA-7855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7855
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql, docs
> Fix For: 3.0
>
> Attachments: CASSANDRA-7855-V2.txt, CASSANDRA-7855.txt
>
>
> When you have a compount partition key, we currently only support to have a
> {{IN}} on the last column of that partition key. So given:
> {noformat}
> CREATE TABLE foo (
> k1 int,
> k2 int,
> v int,
> PRIMARY KEY ((k1, k2))
> )
> {noformat}
> we allow
> {noformat}
> SELECT * FROM foo WHERE k1 = 0 AND k2 IN (1, 2)
> {noformat}
> but not
> {noformat}
> SELECT * FROM foo WHERE k1 IN (0, 1) AND k2 IN (1, 2)
> {noformat}
> There is no particular reason for us not supporting the later (to the best of
> my knowledge) since it's reasonably straighforward, so we should fix it.
> I'll note that using {{IN}} on a partition key is not necessarily a better
> idea than parallelizing queries server client side so this syntax, when
> introduced, should probably be used sparingly, but given we do support IN on
> partition keys, I see no reason not to extend it to compound PK properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8693) QueryProcessor never removes internal statements from its cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298740#comment-14298740
]
Edward Ribeiro commented on CASSANDRA-8693:
---
Hi Tyler, thanks! :)
> QueryProcessor never removes internal statements from its cache
> ---
>
> Key: CASSANDRA-8693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
> Labels: cql3
> Fix For: 2.1.3
>
> Attachments: qp-internal.patch
>
>
> QueryProcessor holds a reference to {{internalStatements}}, a map for
> prepared statements used internally.
> Those commands don't mix with the ones created by the user, but the problem
> is that if a KS/CF is dropped and then recreated {{internalStatements}}
> entries will point to invalid PreparedStatements (old cf_id) so any operation
> on those statements will fail thereafter. In fact, as of today, this map is
> never actually cleaned, no matter what.
> This problem is similar to the ones addressed by
> https://issues.apache.org/jira/browse/CASSANDRA-8652 and
> https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
> any further context.
> I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8685) Consider upgrade to thrift 0.9.2 (or later)
[ https://issues.apache.org/jira/browse/CASSANDRA-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8685: -- Reviewer: Philip Thompson (was: Adam Hattrell) > Consider upgrade to thrift 0.9.2 (or later) > --- > > Key: CASSANDRA-8685 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8685 > Project: Cassandra > Issue Type: Bug >Reporter: Adam Hattrell >Assignee: T Jake Luciani > Fix For: 2.1.3 > > Attachments: thrift1457fix_cassandra_heap.png, > thrift1457fix_cassandra_heap_framedtransport.png > > > Folks using Astyanax and the like are subject to > https://issues.apache.org/jira/browse/THRIFT-1457 and may run into heap > pressure on the Cassandra side for larger read request, as thrift doesn't > reset its internal buffer. This can lead to larger TFramedTransport > instances will be kept on the heap. > I've seen at least one situation where this has saved around 1Gb of heap > space on average. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8707) Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted
Benedict created CASSANDRA-8707: --- Summary: Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted Key: CASSANDRA-8707 URL: https://issues.apache.org/jira/browse/CASSANDRA-8707 Project: Cassandra Issue Type: Bug Reporter: Benedict Assignee: Benedict Fix For: 2.1.3 There are still a few bugs with resource management, especially around SSTableReader cleanup, esp. when intermixing with compaction. This migration should help. We can simultaneously "simplify" the logic in SSTableReader to not track the replacement chain, only to take a new reference to each of the underlying resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6542) nodetool removenode hangs
[ https://issues.apache.org/jira/browse/CASSANDRA-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Forsberg updated CASSANDRA-6542: - Reproduced In: 2.0.1, 1.2.18, 1.2.12, 1.2.11, 1.1.11 (was: 1.1.11, 1.2.11, 1.2.12, 2.0.1) > nodetool removenode hangs > - > > Key: CASSANDRA-6542 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6542 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Ubuntu 12, 1.2.11 DSE >Reporter: Eric Lubow >Assignee: Tyler Hobbs > > Running *nodetool removenode $host-id* doesn't actually remove the node from > the ring. I've let it run anywhere from 5 minutes to 3 days and there are no > messages in the log about it hanging or failing, the command just sits there > running. So the regular response has been to run *nodetool removenode > $host-id*, give it about 10-15 minutes and then run *nodetool removenode > force*. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8705) cqlsh doesn't handle new line escape character inside string literals
[
https://issues.apache.org/jira/browse/CASSANDRA-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp resolved CASSANDRA-8705.
-
Resolution: Not a Problem
OK - resolving this one as "not a problem"
> cqlsh doesn't handle new line escape character inside string literals
> -
>
> Key: CASSANDRA-8705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8705
> Project: Cassandra
> Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=
> ... ';
> count
> ---
> 1
> (1 rows)
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=\n';
> count
> ---
> 0
> (1 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8293) Restore Commitlogs throws exception on startup on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298611#comment-14298611
]
Sam Tunnicliffe commented on CASSANDRA-8293:
[~JoshuaMcKenzie], you only need to change the second occurrence of VERSION_21,
the first is valid as it is. Also, your local mods to
conf/commitlog_archiving.properties are included in the patch. Otherwise, LGTM
> Restore Commitlogs throws exception on startup on trunk
> ---
>
> Key: CASSANDRA-8293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8293
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Fix For: 3.0
>
> Attachments: 8293_v1.txt, CommitLog-5-1415734519132.log,
> CommitLog-5-1415734519133.log, CommitLog-5-1415734519134.log,
> CommitLog-5-1415734519135.log, node1.log
>
>
> Running Cassandra from trunk, restoring commitlogs generated from trunk
> throws the following exception:
> {code}
> ERROR [main] 2014-11-11 13:47:14,738 CassandraDaemon.java:482 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unsupported commit log version: 5
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:215)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:465)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:557)
> [main/:na]
> {code}
> This is reproduced by the dtest
> {{snapshot_test.py:TestArchiveCommitlog.test_archive_commitlog}}. Attached
> are the system log of the node that threw the exception, and the commitlog
> files used. I am restoring the commitlog files by editing
> conf/commitlog_archiving.properties to look like this:{code}# Command to
> execute to make an archived commitlog live again.
> # Parameters: %from is the full path to an archived commitlog segment (from
> restore_directories)
> # %to is the live commitlog directory
> # Example: restore_command=cp -f %from %to
> restore_command=cp -f %from %to
> # Directory to scan the recovery files in.
> restore_directories=/Users/philipthompson/cstar/archived/{code}. If the files
> are placed into the live commitlog directory manually, and then C* is
> started, there are no exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order
[
https://issues.apache.org/jira/browse/CASSANDRA-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298609#comment-14298609
]
Benjamin Lerer commented on CASSANDRA-7281:
---
[~marcinszymaniuk] I am currently working on CASSANDRA-8613 and the changes
requireded for it will impact a lot the code of {{SelectStatement}} used to
build the requestedBounds.
If you can, it might be better to wait a bit before writing your patch.
> SELECT on tuple relations are broken for mixed ASC/DESC clustering order
>
>
> Key: CASSANDRA-7281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7281
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Marcin Szymaniuk
> Fix For: 2.1.3, 2.0.13
>
> Attachments:
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch,
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-v2.patch,
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-v3.patch
>
>
> As noted on
> [CASSANDRA-6875|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153],
> the tuple notation is broken when the clustering order mixes ASC and DESC
> directives because the range of data they describe don't correspond to a
> single continuous slice internally. To copy the example from CASSANDRA-6875:
> {noformat}
> cqlsh:ks> create table foo (a int, b int, c int, PRIMARY KEY (a, b, c)) WITH
> CLUSTERING ORDER BY (b DESC, c ASC);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 2, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 1);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 0, 0);
> cqlsh:ks> SELECT * FROM foo WHERE a=0;
> a | b | c
> ---+---+---
> 0 | 2 | 0
> 0 | 1 | 0
> 0 | 1 | 1
> 0 | 0 | 0
> (4 rows)
> cqlsh:ks> SELECT * FROM foo WHERE a=0 AND (b, c) > (1, 0);
> a | b | c
> ---+---+---
> 0 | 2 | 0
> (1 rows)
> {noformat}
> The last query should really return {{(0, 2, 0)}} and {{(0, 1, 1)}}.
> For that specific example we should generate 2 internal slices, but I believe
> that with more clustering columns we may have more slices.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8293) Restore Commitlogs throws exception on startup on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8293:
---
Reviewer: Sam Tunnicliffe
> Restore Commitlogs throws exception on startup on trunk
> ---
>
> Key: CASSANDRA-8293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8293
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Fix For: 3.0
>
> Attachments: 8293_v1.txt, CommitLog-5-1415734519132.log,
> CommitLog-5-1415734519133.log, CommitLog-5-1415734519134.log,
> CommitLog-5-1415734519135.log, node1.log
>
>
> Running Cassandra from trunk, restoring commitlogs generated from trunk
> throws the following exception:
> {code}
> ERROR [main] 2014-11-11 13:47:14,738 CassandraDaemon.java:482 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unsupported commit log version: 5
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:215)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:465)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:557)
> [main/:na]
> {code}
> This is reproduced by the dtest
> {{snapshot_test.py:TestArchiveCommitlog.test_archive_commitlog}}. Attached
> are the system log of the node that threw the exception, and the commitlog
> files used. I am restoring the commitlog files by editing
> conf/commitlog_archiving.properties to look like this:{code}# Command to
> execute to make an archived commitlog live again.
> # Parameters: %from is the full path to an archived commitlog segment (from
> restore_directories)
> # %to is the live commitlog directory
> # Example: restore_command=cp -f %from %to
> restore_command=cp -f %from %to
> # Directory to scan the recovery files in.
> restore_directories=/Users/philipthompson/cstar/archived/{code}. If the files
> are placed into the live commitlog directory manually, and then C* is
> started, there are no exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8706) Make it possible to configure different compaction strategies for repaired and unrepaired data
Marcus Eriksson created CASSANDRA-8706: -- Summary: Make it possible to configure different compaction strategies for repaired and unrepaired data Key: CASSANDRA-8706 URL: https://issues.apache.org/jira/browse/CASSANDRA-8706 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson Fix For: 3.0 In CASSANDRA-8004 we introduced WrappingCompactionStrategy which handles repaired and unrepaired sstables for compaction - it acts as there is still a single compaction strategy, but underneath it runs 2 different instances of the configured strategy. Main purpose of this was to remove any duplicated repaired/unrepaired logic from the actual compaction strategies and collect them in one place. We should make it possible for users to configure different strategies for the different sets of data - if a user wants to run STCS on unrepaired data and LCS on repaired, it should be possible. This ticket includes replacing WrappingCompactionStrategy with something that does not extend AbstractCompactionStrategy as that part is quite confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8394) Cassandra 3.0 Auth changes
[ https://issues.apache.org/jira/browse/CASSANDRA-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-8394: --- Description: This will be the task that will group all the 3.0 Auth changes, of which we need quite some: 1. Implement Roles (CASSANDRA-7653) 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator SASL-only, and support full SASL capabilities (incl. proxy authentication - see CASSANDRA-7686, CASSANDRA-8068) 3. Remove the current simplistic permissions cache with implementation-specific user/credentials/permissions caches, at least in the implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194) 4. Consider adding a way to split superuser-ness and the rights to manage users (CASSANDRA-7216, CASSANDRA-8650) 5. Add permissions for types and functions (CASSANDRA-7557) 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082) 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163) was: This will be the task that will group all the 3.0 Auth changes, of which we need quite some: 1. Implement Roles (CASSANDRA-7653) 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator SASL-only, and support full SASL capabilities (incl. proxy authentication - see CASSANDRA-7686, CASSANDRA-8068) 3. Remove the current simplistic permissions cache with implementation-specific user/credentials/permissions caches, at least in the implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194) 4. Consider adding a way to split superuser-ness and the rights to manage users (CASSANDRA-7216) 5. Add permissions for types and functions (CASSANDRA-7557) 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082) 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163) > Cassandra 3.0 Auth changes > -- > > Key: CASSANDRA-8394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8394 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Sam Tunnicliffe > Fix For: 3.0 > > > This will be the task that will group all the 3.0 Auth changes, of which we > need quite some: > 1. Implement Roles (CASSANDRA-7653) > 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator > SASL-only, and support full SASL capabilities (incl. proxy authentication - > see CASSANDRA-7686, CASSANDRA-8068) > 3. Remove the current simplistic permissions cache with > implementation-specific user/credentials/permissions caches, at least in the > implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194) > 4. Consider adding a way to split superuser-ness and the rights to manage > users (CASSANDRA-7216, CASSANDRA-8650) > 5. Add permissions for types and functions (CASSANDRA-7557) > 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082) > 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7557) User permissions for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7557:
Assignee: Sam Tunnicliffe (was: Robert Stupp)
> User permissions for UDFs
> -
>
> Key: CASSANDRA-7557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7557
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Sam Tunnicliffe
> Labels: client-impacting, cql, udf
> Fix For: 3.0
>
>
> We probably want some new permissions for user defined functions. Most
> RDBMSes split function permissions roughly into {{EXECUTE}} and
> {{CREATE}}/{{ALTER}}/{{DROP}} permissions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8394) Cassandra 3.0 Auth changes
[ https://issues.apache.org/jira/browse/CASSANDRA-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8394: - Assignee: Sam Tunnicliffe > Cassandra 3.0 Auth changes > -- > > Key: CASSANDRA-8394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8394 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Sam Tunnicliffe > Fix For: 3.0 > > > This will be the task that will group all the 3.0 Auth changes, of which we > need quite some: > 1. Implement Roles (CASSANDRA-7653) > 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator > SASL-only, and support full SASL capabilities (incl. proxy authentication - > see CASSANDRA-7686, CASSANDRA-8068) > 3. Remove the current simplistic permissions cache with > implementation-specific user/credentials/permissions caches, at least in the > implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194) > 4. Consider adding a way to split superuser-ness and the rights to manage > users (CASSANDRA-7216) > 5. Add permissions for types and functions (CASSANDRA-7557) > 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082) > 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8610) Allow IF EXISTS for UPDATE statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prajakta Bhosale updated CASSANDRA-8610:
Attachment: 8610.patch
Check for if Exists
> Allow IF EXISTS for UPDATE statements
> -
>
> Key: CASSANDRA-8610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8610
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: Cassandra 2.1.2
>Reporter: DOAN DuyHai
>Priority: Minor
> Attachments: 8610.patch
>
>
> While creating a hands-on exercice for Cassandra, I was facing a quite
> annoying limitation.
> Let's take this table:
> {code:sql}
> CREATE TABLE killrchat.chat_rooms(
> room_name text,
> creation_date timestamp,
> banner text,
> creator text,
> participants set,
> PRIMARY KEY(room_name));
> {code}
> Upon a new participant joining the room, to be concurrency-proof (avoiding
> mutating the participants set if the room is deleted concurrently), I would
> like to issue this query:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF EXISTS;
> {code}
> Unfortunately the clause IF EXISTS is not allowed for UPDATE statements.
> Similarly I tried
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF room_name='games';
> {code}
> It doesn't work either, it is not allowed to use one column of the primary
> key as condition column for LWT (why ? mystery).
> So far, the only work-around I found is:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF name='games';
> {code}
> I added an extra column called *name* which is just the duplicate of the
> partition key *room_name*. It does work but is not very elegant.
> I believe there are legit use cases for UPDATE ... IF EXISTS;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8704) IllegalStateException when running SSTableLoader
[
https://issues.apache.org/jira/browse/CASSANDRA-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson resolved CASSANDRA-8704.
Resolution: Fixed
> IllegalStateException when running SSTableLoader
>
>
> Key: CASSANDRA-8704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8704
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
> Attachments: 0001-8704.patch
>
>
> The sstableloader dtests are failing on 2.1-HEAD and trunk:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/696/testReport/sstable_generation_loading_test/
> The stack trace is as follows:
> {code}
> Streaming relevant part of
> /var/folders/v3/z4wf_34n1q506_xjdy49gb78gn/T/dtest-4JCAxa/test/node1/data_copy/ks/counter1-86be6170a81911e4bb5177c771bcee1a/la-1-big-Data.db
> to [/127.0.0.1, /127.0.0.2]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)ERROR 00:47:51 BAD RELEASE: attempted to release a shared
> reference (org.apache.cassandra.utils.concurrent.Ref$State@47a2174b) that has
> already been released
> ERROR 00:47:51 [Stream #9dbdade0-a819-11e4-bad4-473c1159ad6e] Streaming error
> occurred
> java.lang.IllegalStateException: Attempted to release a reference that has
> already been released
> at org.apache.cassandra.utils.concurrent.Ref$State.release(Ref.java:73)
> ~[main/:na]
> at org.apache.cassandra.utils.concurrent.Ref.release(Ref.java:32)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:559)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:441)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)WARN 00:47:51 [Stream
> #9dbdade0-a819-11e4-bad4-473c1159ad6e] Stream failed
> Streaming to the following hosts failed:
> [/127.0.0.2]
> java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:121)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:209)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:185)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:394)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:586)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:450)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Git bisect points to #7705 as the first commit where the failures begin,
> though 7705 may have simply uncovered a bug, rather than caused it.
> /cc [~krummas]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8704) IllegalStateException when running SSTableLoader
[
https://issues.apache.org/jira/browse/CASSANDRA-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298527#comment-14298527
]
Marcus Eriksson commented on CASSANDRA-8704:
committed
> IllegalStateException when running SSTableLoader
>
>
> Key: CASSANDRA-8704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8704
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
> Attachments: 0001-8704.patch
>
>
> The sstableloader dtests are failing on 2.1-HEAD and trunk:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/696/testReport/sstable_generation_loading_test/
> The stack trace is as follows:
> {code}
> Streaming relevant part of
> /var/folders/v3/z4wf_34n1q506_xjdy49gb78gn/T/dtest-4JCAxa/test/node1/data_copy/ks/counter1-86be6170a81911e4bb5177c771bcee1a/la-1-big-Data.db
> to [/127.0.0.1, /127.0.0.2]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)ERROR 00:47:51 BAD RELEASE: attempted to release a shared
> reference (org.apache.cassandra.utils.concurrent.Ref$State@47a2174b) that has
> already been released
> ERROR 00:47:51 [Stream #9dbdade0-a819-11e4-bad4-473c1159ad6e] Streaming error
> occurred
> java.lang.IllegalStateException: Attempted to release a reference that has
> already been released
> at org.apache.cassandra.utils.concurrent.Ref$State.release(Ref.java:73)
> ~[main/:na]
> at org.apache.cassandra.utils.concurrent.Ref.release(Ref.java:32)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:559)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:441)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)WARN 00:47:51 [Stream
> #9dbdade0-a819-11e4-bad4-473c1159ad6e] Stream failed
> Streaming to the following hosts failed:
> [/127.0.0.2]
> java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:121)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:209)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:185)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:394)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:586)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:450)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Git bisect points to #7705 as the first commit where the failures begin,
> though 7705 may have simply uncovered a bug, rather than caused it.
> /cc [~krummas]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8704) IllegalStateException when running SSTableLoader
[
https://issues.apache.org/jira/browse/CASSANDRA-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-8704:
---
Reviewer: Benedict
Assignee: Marcus Eriksson (was: Benedict)
> IllegalStateException when running SSTableLoader
>
>
> Key: CASSANDRA-8704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8704
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
> Attachments: 0001-8704.patch
>
>
> The sstableloader dtests are failing on 2.1-HEAD and trunk:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/696/testReport/sstable_generation_loading_test/
> The stack trace is as follows:
> {code}
> Streaming relevant part of
> /var/folders/v3/z4wf_34n1q506_xjdy49gb78gn/T/dtest-4JCAxa/test/node1/data_copy/ks/counter1-86be6170a81911e4bb5177c771bcee1a/la-1-big-Data.db
> to [/127.0.0.1, /127.0.0.2]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)ERROR 00:47:51 BAD RELEASE: attempted to release a shared
> reference (org.apache.cassandra.utils.concurrent.Ref$State@47a2174b) that has
> already been released
> ERROR 00:47:51 [Stream #9dbdade0-a819-11e4-bad4-473c1159ad6e] Streaming error
> occurred
> java.lang.IllegalStateException: Attempted to release a reference that has
> already been released
> at org.apache.cassandra.utils.concurrent.Ref$State.release(Ref.java:73)
> ~[main/:na]
> at org.apache.cassandra.utils.concurrent.Ref.release(Ref.java:32)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:559)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:441)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)WARN 00:47:51 [Stream
> #9dbdade0-a819-11e4-bad4-473c1159ad6e] Stream failed
> Streaming to the following hosts failed:
> [/127.0.0.2]
> java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:121)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:209)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:185)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:394)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:586)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:450)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Git bisect points to #7705 as the first commit where the failures begin,
> though 7705 may have simply uncovered a bug, rather than caused it.
> /cc [~krummas]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/caa03595 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/caa03595 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/caa03595 Branch: refs/heads/trunk Commit: caa0359555282fb2e44db6f2769e3ab77d06e841 Parents: 806facc f123253 Author: Marcus Eriksson Authored: Fri Jan 30 12:48:39 2015 +0100 Committer: Marcus Eriksson Committed: Fri Jan 30 12:48:39 2015 +0100 -- CHANGES.txt | 1 + .../cassandra/io/sstable/SSTableLoader.java | 51 +++- 2 files changed, 30 insertions(+), 22 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/caa03595/CHANGES.txt -- diff --cc CHANGES.txt index a85a6e7,5113e07..21d06c3 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,62 -1,5 +1,63 @@@ +3.0 + * Avoid accessing partitioner through StorageProxy (CASSANDRA-8244, 8268) + * Upgrade Metrics library and remove depricated metrics (CASSANDRA-5657) + * Serializing Row cache alternative, fully off heap (CASSANDRA-7438) + * Duplicate rows returned when in clause has repeated values (CASSANDRA-6707) + * Make CassandraException unchecked, extend RuntimeException (CASSANDRA-8560) + * Support direct buffer decompression for reads (CASSANDRA-8464) + * DirectByteBuffer compatible LZ4 methods (CASSANDRA-7039) + * Add role based access control (CASSANDRA-7653) + * Group sstables for anticompaction correctly (CASSANDRA-8578) + * Add ReadFailureException to native protocol, respond + immediately when replicas encounter errors while handling + a read request (CASSANDRA-7886) + * Switch CommitLogSegment from RandomAccessFile to nio (CASSANDRA-8308) + * Allow mixing token and partition key restrictions (CASSANDRA-7016) + * Support index key/value entries on map collections (CASSANDRA-8473) + * Modernize schema tables (CASSANDRA-8261) + * Support for user-defined aggregation functions (CASSANDRA-8053) + * Fix NPE in SelectStatement with empty IN values (CASSANDRA-8419) + * Refactor SelectStatement, return IN results in natural order instead + of IN value list order and ignore duplicate values in partition key IN restrictions (CASSANDRA-7981) + * Support UDTs, tuples, and collections in user-defined + functions (CASSANDRA-7563) + * Fix aggregate fn results on empty selection, result column name, + and cqlsh parsing (CASSANDRA-8229) + * Mark sstables as repaired after full repair (CASSANDRA-7586) + * Extend Descriptor to include a format value and refactor reader/writer + APIs (CASSANDRA-7443) + * Integrate JMH for microbenchmarks (CASSANDRA-8151) + * Keep sstable levels when bootstrapping (CASSANDRA-7460) + * Add Sigar library and perform basic OS settings check on startup (CASSANDRA-7838) + * Support for aggregation functions (CASSANDRA-4914) + * Remove cassandra-cli (CASSANDRA-7920) + * Accept dollar quoted strings in CQL (CASSANDRA-7769) + * Make assassinate a first class command (CASSANDRA-7935) + * Support IN clause on any clustering column (CASSANDRA-4762) + * Improve compaction logging (CASSANDRA-7818) + * Remove YamlFileNetworkTopologySnitch (CASSANDRA-7917) + * Do anticompaction in groups (CASSANDRA-6851) + * Support user-defined functions (CASSANDRA-7395, 7526, 7562, 7740, 7781, 7929, + 7924, 7812, 8063, 7813, 7708) + * Permit configurable timestamps with cassandra-stress (CASSANDRA-7416) + * Move sstable RandomAccessReader to nio2, which allows using the + FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050) + * Remove CQL2 (CASSANDRA-5918) + * Add Thrift get_multi_slice call (CASSANDRA-6757) + * Optimize fetching multiple cells by name (CASSANDRA-6933) + * Allow compilation in java 8 (CASSANDRA-7028) + * Make incremental repair default (CASSANDRA-7250) + * Enable code coverage thru JaCoCo (CASSANDRA-7226) + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) + * Shorten SSTable path (CASSANDRA-6962) + * Use unsafe mutations for most unit tests (CASSANDRA-6969) + * Fix race condition during calculation of pending ranges (CASSANDRA-7390) + * Fail on very large batch sizes (CASSANDRA-8011) + * Improve concurrency of repair (CASSANDRA-6455, 8208) + + 2.1.3 + * Don't use the shared ref in sstableloader (CASSANDRA-8704) * Purge internal prepared statements if related tables or keyspaces are dropped (CASSANDRA-8693) * (cqlsh) Handle unicode BOM at start of files (CASSANDRA-8638) http://git-wip-us.apache.org/repos/asf/cassandra/blob/caa03595/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java --
[1/2] cassandra git commit: Don't use the shared ref in sstableloader
Repository: cassandra
Updated Branches:
refs/heads/trunk 806facc8c -> caa035955
Don't use the shared ref in sstableloader
Patch by marcuse; reviewed by benedict for CASSANDRA-8704
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f1232532
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f1232532
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f1232532
Branch: refs/heads/trunk
Commit: f1232532e61080096a92e0044b572a1314be2bf5
Parents: 05bbefd
Author: Marcus Eriksson
Authored: Fri Jan 30 11:04:44 2015 +0100
Committer: Marcus Eriksson
Committed: Fri Jan 30 12:46:53 2015 +0100
--
CHANGES.txt | 1 +
.../cassandra/io/sstable/SSTableLoader.java | 51 +++-
2 files changed, 30 insertions(+), 22 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f1232532/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e3e19cf..5113e07 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.3
+ * Don't use the shared ref in sstableloader (CASSANDRA-8704)
* Purge internal prepared statements if related tables or
keyspaces are dropped (CASSANDRA-8693)
* (cqlsh) Handle unicode BOM at start of files (CASSANDRA-8638)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f1232532/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
index 1cab8c7..06f71d8 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
@@ -131,8 +131,10 @@ public class SSTableLoader implements StreamEventHandler
List> sstableSections =
sstable.getPositionsForRanges(tokenRanges);
long estimatedKeys =
sstable.estimatedKeysForRanges(tokenRanges);
-
-StreamSession.SSTableStreamingSections details = new
StreamSession.SSTableStreamingSections(sstable, sstable.sharedRef(),
sstableSections, estimatedKeys, ActiveRepairService.UNREPAIRED_SSTABLE);
+Ref ref = sstable.tryRef();
+if (ref == null)
+throw new IllegalStateException("Could not acquire
ref for "+sstable);
+StreamSession.SSTableStreamingSections details = new
StreamSession.SSTableStreamingSections(sstable, ref, sstableSections,
estimatedKeys, ActiveRepairService.UNREPAIRED_SSTABLE);
streamingDetails.put(endpoint, details);
}
@@ -178,34 +180,39 @@ public class SSTableLoader implements StreamEventHandler
continue;
List endpointDetails = new
LinkedList<>();
-List refs = new ArrayList<>();
-try
-{
-// transferSSTables assumes references have been acquired
-for (StreamSession.SSTableStreamingSections details :
streamingDetails.get(remote))
-{
-Ref ref = details.sstable.tryRef();
-if (ref == null)
-throw new IllegalStateException();
-
-refs.add(ref);
-endpointDetails.add(details);
-}
-plan.transferFiles(remote, endpointDetails);
-}
-finally
+// references are acquired when constructing the
SSTableStreamingSections above
+for (StreamSession.SSTableStreamingSections details :
streamingDetails.get(remote))
{
-for (Ref ref : refs)
-ref.release();
+endpointDetails.add(details);
}
+
+plan.transferFiles(remote, endpointDetails);
}
plan.listeners(this, listeners);
return plan.execute();
}
-public void onSuccess(StreamState finalState) {}
-public void onFailure(Throwable t) {}
+public void onSuccess(StreamState finalState)
+{
+releaseReferences();
+}
+public void onFailure(Throwable t)
+{
+releaseReferences();
+}
+
+/**
+ * releases the shared reference for all sstables, we acquire this when
opening the sstable
+ */
+private void releaseReferences()
+{
+for (SSTableReader sstable : sstables)
+{
+sstable.sharedRef().release();
+assert sstable.sharedRef().globalCount() == 0;
+}
+}
public void handleStreamEvent(StreamEvent event)
{
cassandra git commit: Don't use the shared ref in sstableloader
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 05bbefd50 -> f1232532e
Don't use the shared ref in sstableloader
Patch by marcuse; reviewed by benedict for CASSANDRA-8704
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f1232532
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f1232532
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f1232532
Branch: refs/heads/cassandra-2.1
Commit: f1232532e61080096a92e0044b572a1314be2bf5
Parents: 05bbefd
Author: Marcus Eriksson
Authored: Fri Jan 30 11:04:44 2015 +0100
Committer: Marcus Eriksson
Committed: Fri Jan 30 12:46:53 2015 +0100
--
CHANGES.txt | 1 +
.../cassandra/io/sstable/SSTableLoader.java | 51 +++-
2 files changed, 30 insertions(+), 22 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f1232532/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e3e19cf..5113e07 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.3
+ * Don't use the shared ref in sstableloader (CASSANDRA-8704)
* Purge internal prepared statements if related tables or
keyspaces are dropped (CASSANDRA-8693)
* (cqlsh) Handle unicode BOM at start of files (CASSANDRA-8638)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f1232532/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
index 1cab8c7..06f71d8 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
@@ -131,8 +131,10 @@ public class SSTableLoader implements StreamEventHandler
List> sstableSections =
sstable.getPositionsForRanges(tokenRanges);
long estimatedKeys =
sstable.estimatedKeysForRanges(tokenRanges);
-
-StreamSession.SSTableStreamingSections details = new
StreamSession.SSTableStreamingSections(sstable, sstable.sharedRef(),
sstableSections, estimatedKeys, ActiveRepairService.UNREPAIRED_SSTABLE);
+Ref ref = sstable.tryRef();
+if (ref == null)
+throw new IllegalStateException("Could not acquire
ref for "+sstable);
+StreamSession.SSTableStreamingSections details = new
StreamSession.SSTableStreamingSections(sstable, ref, sstableSections,
estimatedKeys, ActiveRepairService.UNREPAIRED_SSTABLE);
streamingDetails.put(endpoint, details);
}
@@ -178,34 +180,39 @@ public class SSTableLoader implements StreamEventHandler
continue;
List endpointDetails = new
LinkedList<>();
-List refs = new ArrayList<>();
-try
-{
-// transferSSTables assumes references have been acquired
-for (StreamSession.SSTableStreamingSections details :
streamingDetails.get(remote))
-{
-Ref ref = details.sstable.tryRef();
-if (ref == null)
-throw new IllegalStateException();
-
-refs.add(ref);
-endpointDetails.add(details);
-}
-plan.transferFiles(remote, endpointDetails);
-}
-finally
+// references are acquired when constructing the
SSTableStreamingSections above
+for (StreamSession.SSTableStreamingSections details :
streamingDetails.get(remote))
{
-for (Ref ref : refs)
-ref.release();
+endpointDetails.add(details);
}
+
+plan.transferFiles(remote, endpointDetails);
}
plan.listeners(this, listeners);
return plan.execute();
}
-public void onSuccess(StreamState finalState) {}
-public void onFailure(Throwable t) {}
+public void onSuccess(StreamState finalState)
+{
+releaseReferences();
+}
+public void onFailure(Throwable t)
+{
+releaseReferences();
+}
+
+/**
+ * releases the shared reference for all sstables, we acquire this when
opening the sstable
+ */
+private void releaseReferences()
+{
+for (SSTableReader sstable : sstables)
+{
+sstable.sharedRef().release();
+assert sstable.sharedRef().globalCount() == 0;
+}
+}
public void handleStreamEvent(StreamEvent event)
{
[jira] [Commented] (CASSANDRA-7855) Genralize use of IN for compound partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298515#comment-14298515
]
Sam Tunnicliffe commented on CASSANDRA-7855:
+1
Just for completeness I would add one more test case where all permutations of
the conditions provide matches, but I'm nitpicking
{code}
execute("insert into %s (a, b, c, d) values (?, ?, ?, ?)", "second", 1, 1, 1);
...
assertRows(execute("select * from %s where a in (?, ?) and b in (?, ?)",
"first", "second", 1, 4),
row("first", 1, 1, 1),
row("first", 4, 4, 4),
row("second", 1, 1, 1),
row("second", 4, 4, 4));
{code}
> Genralize use of IN for compound partition keys
> ---
>
> Key: CASSANDRA-7855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7855
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql, docs
> Fix For: 3.0
>
> Attachments: CASSANDRA-7855.txt
>
>
> When you have a compount partition key, we currently only support to have a
> {{IN}} on the last column of that partition key. So given:
> {noformat}
> CREATE TABLE foo (
> k1 int,
> k2 int,
> v int,
> PRIMARY KEY ((k1, k2))
> )
> {noformat}
> we allow
> {noformat}
> SELECT * FROM foo WHERE k1 = 0 AND k2 IN (1, 2)
> {noformat}
> but not
> {noformat}
> SELECT * FROM foo WHERE k1 IN (0, 1) AND k2 IN (1, 2)
> {noformat}
> There is no particular reason for us not supporting the later (to the best of
> my knowledge) since it's reasonably straighforward, so we should fix it.
> I'll note that using {{IN}} on a partition key is not necessarily a better
> idea than parallelizing queries server client side so this syntax, when
> introduced, should probably be used sparingly, but given we do support IN on
> partition keys, I see no reason not to extend it to compound PK properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8705) cqlsh doesn't handle new line escape character inside string literals
[
https://issues.apache.org/jira/browse/CASSANDRA-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298510#comment-14298510
]
mlowicki edited comment on CASSANDRA-8705 at 1/30/15 11:21 AM:
---
I haven't heard about DevCenter. Tried and works really cool! It'll definitely
alleviate some issues with cqlsh. Thanks!
was (Author: mlowicki):
I haven't heard about DevCenter. Tried and works really cool! I'll definitely
alleviate some issues with cqlsh. Thanks!
> cqlsh doesn't handle new line escape character inside string literals
> -
>
> Key: CASSANDRA-8705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8705
> Project: Cassandra
> Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=
> ... ';
> count
> ---
> 1
> (1 rows)
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=\n';
> count
> ---
> 0
> (1 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8705) cqlsh doesn't handle new line escape character inside string literals
[
https://issues.apache.org/jira/browse/CASSANDRA-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298510#comment-14298510
]
mlowicki commented on CASSANDRA-8705:
-
I haven't heard about DevCenter. Tried and works really cool! I'll definitely
alleviate some issues with cqlsh. Thanks!
> cqlsh doesn't handle new line escape character inside string literals
> -
>
> Key: CASSANDRA-8705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8705
> Project: Cassandra
> Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=
> ... ';
> count
> ---
> 1
> (1 rows)
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=\n';
> count
> ---
> 0
> (1 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8704) IllegalStateException when running SSTableLoader
[
https://issues.apache.org/jira/browse/CASSANDRA-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298490#comment-14298490
]
Benedict commented on CASSANDRA-8704:
-
Hmm. Looking at the translation I made when writing that code more closely now,
it is nonsense.
+1
> IllegalStateException when running SSTableLoader
>
>
> Key: CASSANDRA-8704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8704
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benedict
> Fix For: 2.1.3
>
> Attachments: 0001-8704.patch
>
>
> The sstableloader dtests are failing on 2.1-HEAD and trunk:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/696/testReport/sstable_generation_loading_test/
> The stack trace is as follows:
> {code}
> Streaming relevant part of
> /var/folders/v3/z4wf_34n1q506_xjdy49gb78gn/T/dtest-4JCAxa/test/node1/data_copy/ks/counter1-86be6170a81911e4bb5177c771bcee1a/la-1-big-Data.db
> to [/127.0.0.1, /127.0.0.2]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)ERROR 00:47:51 BAD RELEASE: attempted to release a shared
> reference (org.apache.cassandra.utils.concurrent.Ref$State@47a2174b) that has
> already been released
> ERROR 00:47:51 [Stream #9dbdade0-a819-11e4-bad4-473c1159ad6e] Streaming error
> occurred
> java.lang.IllegalStateException: Attempted to release a reference that has
> already been released
> at org.apache.cassandra.utils.concurrent.Ref$State.release(Ref.java:73)
> ~[main/:na]
> at org.apache.cassandra.utils.concurrent.Ref.release(Ref.java:32)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:559)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:441)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)WARN 00:47:51 [Stream
> #9dbdade0-a819-11e4-bad4-473c1159ad6e] Stream failed
> Streaming to the following hosts failed:
> [/127.0.0.2]
> java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:121)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:209)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:185)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:394)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:586)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:450)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Git bisect points to #7705 as the first commit where the failures begin,
> though 7705 may have simply uncovered a bug, rather than caused it.
> /cc [~krummas]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7557) User permissions for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298452#comment-14298452
]
Robert Stupp commented on CASSANDRA-7557:
-
Currently we allow creation of different kinds of resources using the same name.
{{CREATE TABLE foo …}}
{{CREATE TYPE foo …}}
{{CREATE FUNCTION/AGGREGATE foo …}}
This means that a granted permission like {{GRANT ALTER ON foo TO sheldon}}
cannot distinguish whether it means the table, the type or the
function/aggregate.
I’m not sure whether we should enforce unique names for tables, types and
functions in a keyspace (I don’t think it’s necessary - at least for now).
But we should be precise (be able to distinguish) with permissions.
To achieve this, I propose to change permissions in {{Permission}} enum:
* {{CREATE}} to {{CREATE_KEYSPACE}}, {{CREATE_TABLE}}, {{CREATE_FUNCTION}},
{{CREATE_AGGREGATE}}
* {{ALTER}} to {{ALTER_KEYSPACE}}, {{ALTER_TABLE}}, {{ALTER_FUNCTION}},
{{ALTER_AGGREGATE}}
* {{DROP}} to {{DROP_KEYSPACE}}, {{DROP_TABLE}}, {{DROP_FUNCTION}},
{{DROP_AGGREGATE}}
* add new {{EXECUTE}} permission in {{Permission}} enum (global, per keyspace,
per function name).
I’m not sure whether different resources for functions and aggregates should be
used. But since we have different statements for functions and aggregates, I’d
like to have different resources for them (new {{FunctionResource implements
IResource}}.
The ”old” {{CREATE}} permission would then be migrated in
{{o.a.c.auth.CassandraAuthorizer#convertLegacyData}} to {{CREATE_KEYSPACE}} +
{{CREATE_TABLE}} (or just {{CREATE_TABLE}} if the resource is a keyspace).
Similar for {{ALTER}} + {{DROP}}.
Alternative is to leave {{CREATE}}, {{ALTER}} and {{DROP}} permissions and
imply that these are only meant for data (keyspaces + tables + types).
Drawback of my proposal is that the {{LIST (permissions)}} statement would
return a non-backwards compatible result.
> User permissions for UDFs
> -
>
> Key: CASSANDRA-7557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7557
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Robert Stupp
> Labels: client-impacting, cql, udf
> Fix For: 3.0
>
>
> We probably want some new permissions for user defined functions. Most
> RDBMSes split function permissions roughly into {{EXECUTE}} and
> {{CREATE}}/{{ALTER}}/{{DROP}} permissions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8704) IllegalStateException when running SSTableLoader
[
https://issues.apache.org/jira/browse/CASSANDRA-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-8704:
---
Attachment: 0001-8704.patch
Problem is that we passed in the shared reference when creating the
SSTableStreamingSections - this gets released when the file has been
transferred and if we transfer to > 1 host, it will release the shared ref
several times.
I think we are good in the general streaming/repair case since we get new
references for the sstables in StreamSession.getSSTableSectionsForRanges
> IllegalStateException when running SSTableLoader
>
>
> Key: CASSANDRA-8704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8704
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benedict
> Fix For: 2.1.3
>
> Attachments: 0001-8704.patch
>
>
> The sstableloader dtests are failing on 2.1-HEAD and trunk:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/696/testReport/sstable_generation_loading_test/
> The stack trace is as follows:
> {code}
> Streaming relevant part of
> /var/folders/v3/z4wf_34n1q506_xjdy49gb78gn/T/dtest-4JCAxa/test/node1/data_copy/ks/counter1-86be6170a81911e4bb5177c771bcee1a/la-1-big-Data.db
> to [/127.0.0.1, /127.0.0.2]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)ERROR 00:47:51 BAD RELEASE: attempted to release a shared
> reference (org.apache.cassandra.utils.concurrent.Ref$State@47a2174b) that has
> already been released
> ERROR 00:47:51 [Stream #9dbdade0-a819-11e4-bad4-473c1159ad6e] Streaming error
> occurred
> java.lang.IllegalStateException: Attempted to release a reference that has
> already been released
> at org.apache.cassandra.utils.concurrent.Ref$State.release(Ref.java:73)
> ~[main/:na]
> at org.apache.cassandra.utils.concurrent.Ref.release(Ref.java:32)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:559)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:441)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> progress: [/127.0.0.1]0:1/1 100% [/127.0.0.2]0:1/1 100% total: 100% 0
> MB/s(avg: 0 MB/s)WARN 00:47:51 [Stream
> #9dbdade0-a819-11e4-bad4-473c1159ad6e] Stream failed
> Streaming to the following hosts failed:
> [/127.0.0.2]
> java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:121)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:209)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:185)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:394)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:586)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:450)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:252)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Git bisect points to #7705 as the first commit where the failures begin,
> though 7705 may have simply uncovered a bug, rather than caused it.
> /cc [~krummas]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8705) cqlsh doesn't handle new line escape character inside string literals
[
https://issues.apache.org/jira/browse/CASSANDRA-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298449#comment-14298449
]
Robert Stupp commented on CASSANDRA-8705:
-
If we would allow escapes, it would break a lot of existing applications.
TBH I don't think that newlines are a good choice to use in parts of the
primary key. IMO you will run into problems when developing on mixed
environments that use different line endings like CR-LF or LF (e.g. in script
files).
The easier solution, if you really want to do it with newlines, might be to use
Devcenter from datastax.com web site.
> cqlsh doesn't handle new line escape character inside string literals
> -
>
> Key: CASSANDRA-8705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8705
> Project: Cassandra
> Issue Type: Bug
>Reporter: mlowicki
>
> {code}
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=
> ... ';
> count
> ---
> 1
> (1 rows)
> cqlsh:sync> select count(*) from entity where user_id='255824802' and
> parent_id='MzI5MDReMV48c2VydmVyIHRhZz50cmFzaF9ib29rbWFya3M=\n';
> count
> ---
> 0
> (1 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8595) Emit timeouts per endpoint
[ https://issues.apache.org/jira/browse/CASSANDRA-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298445#comment-14298445 ] sankalp kohli commented on CASSANDRA-8595: -- When we see timeouts at SP level, this map will help in knowing which machines are slow/timing out > Emit timeouts per endpoint > -- > > Key: CASSANDRA-8595 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8595 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Priority: Minor > > We currently emit number of timeouts experienced by a co-ordinator while > doing reads and writes. This does not tell us which replica or endpoint is > responsible for the timeouts. > We can keep a map of endpoint to number of timeouts which could be emitted > via JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7557) User permissions for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7557:
Assignee: Robert Stupp
> User permissions for UDFs
> -
>
> Key: CASSANDRA-7557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7557
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Robert Stupp
> Labels: client-impacting, cql, udf
> Fix For: 3.0
>
>
> We probably want some new permissions for user defined functions. Most
> RDBMSes split function permissions roughly into {{EXECUTE}} and
> {{CREATE}}/{{ALTER}}/{{DROP}} permissions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8492) Support "IF NOT EXISTS" for "ALTER TABLE ADD COLUMN"
[ https://issues.apache.org/jira/browse/CASSANDRA-8492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298437#comment-14298437 ] Sachin Janani commented on CASSANDRA-8492: -- Hi All, I am taking up this jira will upload a patch soon. > Support "IF NOT EXISTS" for "ALTER TABLE ADD COLUMN" > > > Key: CASSANDRA-8492 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8492 > Project: Cassandra > Issue Type: Improvement >Reporter: Peter Mädel >Priority: Minor > > would enable creation of schema update scripts that can be repeatable > executed without having to worry about invalid query exceptions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8692) Coalesce intra-cluster network messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298427#comment-14298427 ] Sylvain Lebresne commented on CASSANDRA-8692: - I'll note that this touch pretty critical parts of the code and is "just a performance improvement" so I personally would like to see at least some numbers of how effictive this actually is in practice before considering inclusion to 2.1. Everyone is always complaining that new releases take a long time to get really stable but it won't change until we stop waiting for the .7 or .8 version of a particular release to consider only bug fix for admission. > Coalesce intra-cluster network messages > --- > > Key: CASSANDRA-8692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8692 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > > While researching CASSANDRA-8457 we found that it is effective and can be > done without introducing additional latency at low concurrency/throughput. > The patch from that was used and found to be useful in a real life scenario > so I propose we implement this in 2.1 in addition to 3.0. > The change set is a single file and is small enough to be reviewable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
