date:20140617


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033582#comment-14033582
 ] 

Marco Tulio Avila Cerón commented on CASSANDRA-7398:


The user then will see the following in the logs:

INFO  [main] 2014-06-17 11:06:35,063 Hostname: marcoavilac-win
ERROR [main] 2014-06-17 11:06:50,639 Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: Not a UNIX environment 
detected and file:/// not supplied in the start of path
at 
org.apache.cassandra.config.YamlConfigurationLoader.getStorageConfigURL(YamlConfigurationLoader.java:62)
 ~[main/:na]
at 
org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:87)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:153)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.clinit(DatabaseDescriptor.java:129)
 ~[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:109) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:455) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:544) 
[main/:na]

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL


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

Marco Tulio Avila Cerón updated CASSANDRA-7398:
---

Comment: was deleted

(was: The user then will see the following in the logs:

INFO  [main] 2014-06-17 11:06:35,063 Hostname: marcoavilac-win
ERROR [main] 2014-06-17 11:06:50,639 Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: Not a UNIX environment 
detected and file:/// not supplied in the start of path
at 
org.apache.cassandra.config.YamlConfigurationLoader.getStorageConfigURL(YamlConfigurationLoader.java:62)
 ~[main/:na]
at 
org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:87)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:153)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.clinit(DatabaseDescriptor.java:129)
 ~[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:109) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:455) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:544) 
[main/:na])

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033585#comment-14033585
 ] 

Marco Tulio Avila Cerón commented on CASSANDRA-7398:


The user will see the following in the logs:

{code}
INFO  [main] 2014-06-17 11:06:35,063 Hostname: marcoavilac-win
ERROR [main] 2014-06-17 11:06:50,639 Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: Not a UNIX environment 
detected and file:/// not supplied in the start of path
at 
org.apache.cassandra.config.YamlConfigurationLoader.getStorageConfigURL(YamlConfigurationLoader.java:62)
 ~[main/:na]
at 
org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:87)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:153)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.clinit(DatabaseDescriptor.java:129)
 ~[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:109) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:455) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:544) 
[main/:na]
{code}

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL


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

Marco Tulio Avila Cerón updated CASSANDRA-7398:
---

Attachment: CASSANDRA-7398_prefix_v3.patch

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch, 
 CASSANDRA-7398_prefix_v3.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033599#comment-14033599
 ] 

Marco Tulio Avila Cerón commented on CASSANDRA-7398:


Version 3 of patch does not throw exception and modifies the url and avoid 
having to carry out try-catches after an exception is thrown.

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch, 
 CASSANDRA-7398_prefix_v3.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033599#comment-14033599
 ] 

Marco Tulio Avila Cerón edited comment on CASSANDRA-7398 at 6/17/14 9:24 AM:
-

Version 3 of patch does not throw exception and modifies the url


was (Author: totopo_loco):
Version 3 of patch does not throw exception and modifies the url and avoid 
having to carry out try-catches after an exception is thrown.

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch, 
 CASSANDRA-7398_prefix_v3.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL


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

Marco Tulio Avila Cerón updated CASSANDRA-7398:
---

Attachment: CASSANDRA-7398_prefix_v4.patch

Added version, only difference to v3 is that logs before appending file prefix 
to the config file.

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch, 
 CASSANDRA-7398_prefix_v3.patch, CASSANDRA-7398_prefix_v4.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033603#comment-14033603
 ] 

Marco Tulio Avila Cerón edited comment on CASSANDRA-7398 at 6/17/14 9:29 AM:
-

Added version 4, only difference to v3 is that logs before appending file 
prefix to the config file.


was (Author: totopo_loco):
Added version, only difference to v3 is that logs before appending file prefix 
to the config file.

 Using the -Dcassandra.config VM param needs a file:/// prefix for the 
 supplied URL
 

 Key: CASSANDRA-7398
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment:  Cassandra 2.1.0-rc1-SNAPSHOT, Win 7
Reporter: Marco Tulio Avila Cerón
Priority: Minor
  Labels: lhf, patch
 Fix For: 2.1 rc2

 Attachments: CASSANDRA-7398_prefix_v2.patch, 
 CASSANDRA-7398_prefix_v3.patch, CASSANDRA-7398_prefix_v4.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The parameter in the VM options -Dcassandra.config= needs file:///
 Allow the user to have optional file:/// when loading the config file from 
 the filesystem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7353) Java heap being set too large on Windows with 32-bit JVM

2014-06-17 Thread Joshua McKenzie (JIRA)

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

Joshua McKenzie updated CASSANDRA-7353:
---

Attachment: 7353_v3.txt

Slipped my mind - we have MAX_HEAP_SIZE and HEAP_NEWSIZE available to be tuned
in conf/cassandra-env.ps1, so adding more logic on top of that to facilitate an
edge-case like this is unnecessary.

That said, I've tidied up a few things, tossed a 100 ms sleep in the launch
process to catch JVM init errors (catches it at 10 on my machine but figured a
little breathing room wouldn't hurt), and changed the logic we use to check to
see if a process started correctly (v3 patch attached).

Philip, will this launch delay potentially cause us headaches in ccm or dtests?

Java heap being set too large on Windows with 32-bit JVM

Key: CASSANDRA-7353
URL: https://issues.apache.org/jira/browse/CASSANDRA-7353
Project: Cassandra
Issue Type: Bug
Environment: Windows Server 2008, 8G RAM, 32-bit JVM
Reporter: Philip Thompson
Assignee: Joshua McKenzie
Priority: Minor
Labels: Windows
Attachments: 7353_v1.txt, 7353_v2.txt, 7353_v3.txt

On windows, the JVM settings for max heap size and new gen heap size are set
based on the total system memory. When the system has 8G of RAM, the max heap
size is set to 2048M. However, according to http://goo.gl/1ElbLm, the
recommended max heap for a 32 bit JVM on Windows is 1.8G.
When cassandra is started on Windows under these conditions, the following
error is seen:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Switching to a 64-bit JVM on the same machine solves the issue. If a 32-bit
JVM is being used, cassandra should be started up with a smaller heap than
would be normally used to prevent the error.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms

2014-06-17 Thread Michael Shuler (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033803#comment-14033803
 ] 

Michael Shuler commented on CASSANDRA-7156:
---

I sent [~pyritschard] a direct email to work on validation testing.

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Assignee: Michael Shuler
Priority: Minor
 Fix For: 2.0.9, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency and together with CASSANDRA-7147 gives an 
 easy way of getting started on cloudstack platforms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7156) Add a new seed provider for Apache Cloudstack platforms

2014-06-17 Thread Tupshin Harper (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033815#comment-14033815
 ] 

Tupshin Harper commented on CASSANDRA-7156:
---

I'm fine with linking to external github repos to provide additional seed 
providers, at least initially. There just needs to be very clear and 
straightforward instructions for building and deploying them.

 Add a new seed provider for Apache Cloudstack platforms
 ---

 Key: CASSANDRA-7156
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7156
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
 Environment: needs access to a cloudstack API endpoint
Reporter: Pierre-Yves Ritschard
Assignee: Michael Shuler
Priority: Minor
 Fix For: 2.0.9, 2.1.1

 Attachments: 0001-initial-work-on-a-cloudstack-seed-provider.patch


 The attached patch adds a new seed provider which queries a cloudstack API 
 endpoint for instances having a specific tag.
 The tag key and value can be controlled in the configuration file and 
 
 will default to 'cassandra_seed' and 'default'.   
 
 The Cloudstack endpoint is configured by three parameters in the  
 
 configuration file: 'cloudstack_api_endpoint', 'cloudstack_api_key' and   
 
 'cloudstack_api_secret'   
 
 By default, CloudstackSeedProvider fetchs the ipaddress of the first  
 
 interface, if another index should be used, the nic_index parameter will hold 
 it.
 A typical configuration file would thus have:
 {code:yaml}
 seed_provider:
 - class_name: org.apache.cassandra.locator.CloudstackSeedProvider
   parameters:
   - cloudstack_api_endpoint: https://some.cloudstack.host;
 cloudstack_api_key: X
 cloudstack_api_secret: X
 tag_value: my_cluster_name
 {code}
 This introduces no new dependency and together with CASSANDRA-7147 gives an 
 easy way of getting started on cloudstack platforms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7407) COPY command does not work properly with collections causing failure to import data

2014-06-17 Thread Jose Martinez Poblete (JIRA)

Jose Martinez Poblete created CASSANDRA-7407:


 Summary: COPY command does not work properly with collections 
causing failure to import data
 Key: CASSANDRA-7407
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7407
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cqlsh 4.1.1, 
Cassandra 2.0.7.31,
CQL spec 3.1.1,
Thrift protocol 19.39.0
Reporter: Jose Martinez Poblete


The COPY command does not properly format collections in the output CSV - to be 
able to re-import the data.

Here is how you can replicate the problem:

{noformat}
CREATE TABLE user_colors ( 
user_id int PRIMARY KEY, 
colors listascii 
);

UPDATE user_colors SET colors = ['red','blue'] WHERE user_id=5; 
UPDATE user_colors SET colors = ['purple','yellow'] WHERE user_id=6; 
UPDATE user_colors SET colors = ['black''] WHERE user_id=7;

COPY user_colors (user_id, colors) TO 'output.csv';

CREATE TABLE user_colors2 ( 
user_id int PRIMARY KEY, 
colors listascii 
);

COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
Bad Request: line 1:68 no viable alternative at input ']'
Aborting import at record #0 (line 1). Previously-inserted values still present.
0 rows imported in 0.007 seconds.
{noformat}

The CSV file seems to be malformed
- The single quotes within the collection are missing
- The double quotes for collection on user_id=7 are missing and causing COPY to 
fail.
{noformat}
5,[red, blue]
7,[black]
6,[purple, yellow]
{noformat}

Should be like this
{noformat}
5,['red', 'blue']
7,['black']
6,['purple', 'yellow']
{noformat}

Once the file is changed, the import works
{noformat}
COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
3 rows imported in 0.012 seconds.
SELECT * FROM user_colors2;

 user_id | colors
-+--
   5 |  [red, blue]
   7 |  [black]
   6 | [purple, yellow]

(3 rows)
{noformat}




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7353) Java heap being set too large on Windows with 32-bit JVM

[
https://issues.apache.org/jira/browse/CASSANDRA-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033870#comment-14033870
]

Philip Thompson commented on CASSANDRA-7353:

Josh, that increase, even if it took the full 100ms each time is pretty
negligible. 30s when a full dtest run takes 2 hours. However, saying that we
just don't support a 32 bit jvm on a 64 bit machine could be an acceptable
resolution if Dave's opinion is the consensus. I'll get v3 tested and let you
know if it works though.

Java heap being set too large on Windows with 32-bit JVM

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7353) Java heap being set too large on Windows with 32-bit JVM

[
https://issues.apache.org/jira/browse/CASSANDRA-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033876#comment-14033876
]

Philip Thompson commented on CASSANDRA-7353:

v3 gives me the same error message with the same Xms, Xmx, and Xmn values.

Java heap being set too large on Windows with 32-bit JVM

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7353) Java heap being set too large on Windows with 32-bit JVM

2014-06-17 Thread Joshua McKenzie (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033887#comment-14033887
]

Joshua McKenzie commented on CASSANDRA-7353:

Yep - sorry I wasn't more clear on v3 totally taking a left-turn when it came
to implementation.

Java heap being set too large on Windows with 32-bit JVM

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7353) Java heap being set too large on Windows with 32-bit JVM

[
https://issues.apache.org/jira/browse/CASSANDRA-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033885#comment-14033885
]

Philip Thompson commented on CASSANDRA-7353:

If my understanding is correct and the user is now responsible for setting
their own MAX_HEAP_SIZE and HEAP_NEWSIZE variables, then this is working
correctly. There is a helpful error message when C* does not start correctly,
and the environment variables properly coerce the heap. +1.

Java heap being set too large on Windows with 32-bit JVM

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7407) COPY command does not work properly with collections causing failure to import data


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033898#comment-14033898
 ] 

Brandon Williams commented on CASSANDRA-7407:
-

I'm not sure I understand the problem here.  It sounds like the CSV was 
malformed, so fix the CSV?

 COPY command does not work properly with collections causing failure to 
 import data
 ---

 Key: CASSANDRA-7407
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7407
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cqlsh 4.1.1, 
 Cassandra 2.0.7.31,
 CQL spec 3.1.1,
 Thrift protocol 19.39.0
Reporter: Jose Martinez Poblete
  Labels: patch

 The COPY command does not properly format collections in the output CSV - to 
 be able to re-import the data.
 Here is how you can replicate the problem:
 {noformat}
 CREATE TABLE user_colors ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 UPDATE user_colors SET colors = ['red','blue'] WHERE user_id=5; 
 UPDATE user_colors SET colors = ['purple','yellow'] WHERE user_id=6; 
 UPDATE user_colors SET colors = ['black''] WHERE user_id=7;
 COPY user_colors (user_id, colors) TO 'output.csv';
 CREATE TABLE user_colors2 ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 Bad Request: line 1:68 no viable alternative at input ']'
 Aborting import at record #0 (line 1). Previously-inserted values still 
 present.
 0 rows imported in 0.007 seconds.
 {noformat}
 The CSV file seems to be malformed
 - The single quotes within the collection are missing
 - The double quotes for collection on user_id=7 are missing and causing COPY 
 to fail.
 {noformat}
 5,[red, blue]
 7,[black]
 6,[purple, yellow]
 {noformat}
 Should be like this
 {noformat}
 5,['red', 'blue']
 7,['black']
 6,['purple', 'yellow']
 {noformat}
 Once the file is changed, the import works
 {noformat}
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 3 rows imported in 0.012 seconds.
 SELECT * FROM user_colors2;
  user_id | colors
 -+--
5 |  [red, blue]
7 |  [black]
6 | [purple, yellow]
 (3 rows)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7273) expose global ColumnFamily metrics

2014-06-17 Thread Yuki Morishita (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033926#comment-14033926
]

Yuki Morishita commented on CASSANDRA-7273:
---

First of all, thanks Chris for taking a look at this one.
I'm not a fan of aggregating all CF metrics to global level (as I pointed out
in CASSANDRA-6539).
Aggregated histograms can be misleading, we already have node-level latency
metrics, etc.
I think the way to do here is just sum Keyspace metrics.

{quote}
* tried to automate some of the releasing of metrics since seems error prone
(WaitingOnFreeMemtableSpace was missing).
* renamed MemtableHeapSize since there were 2 metrics with that name
{quote}

Thanks for pointing these out. I noticed there are some release/naming problem
in CF metrics.
I will fix these in separate commit.

expose global ColumnFamily metrics
--

Key: CASSANDRA-7273
URL: https://issues.apache.org/jira/browse/CASSANDRA-7273
Project: Cassandra
Issue Type: New Feature
Reporter: Richard Wagner
Assignee: Brandon Williams
Priority: Minor
Labels: lhf
Fix For: 1.2.17

Attachments: 7273-2_1_branch-v1.txt

It would be very useful to have cassandra expose ColumnFamily metrics that
span all column families. A general purpose cassandra monitoring system built
up around the current ColumnFamily metrics really only has a couple of
choices right now: publish metrics for all column families or fetch metrics
for all column families, aggregate them and then publish the aggregated
metrics. The first can be quite expensive for the downstream monitoring
system and the second is a piece of work that it seems is better pushed into
cassandra itself.
Perhaps these global ColumnFamily metrics could be published under a name of:
org.apache.cassandra.metrics:type=(ColumnFamily|IndexColumnFamily),name=(Metric
name)
(Same as existing ColumnFamily metrics, but with no keyspace or scope.)

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7273) expose global ColumnFamily metrics


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033928#comment-14033928
 ] 

Brandon Williams commented on CASSANDRA-7273:
-

I have to admit, this is not how I envisioned this patch at all, but I like 
what you've done!  Especially in the releasing of metrics, since that always 
felt error prone (and indeed, I screwed it up.)  One nit: please set your IDE 
to collapse imports when there are 3 or more to asterisk instead (it actually 
undid some existing instances of this.)

There are now a bunch of stats in GCF that aren't in KS... we should have 
parity there, though at this point I feel like the KS level is out of place 
somehow, perhaps because GCF is so much more elegant ;)  We should probably at 
least apply your releasing pattern there as well.

 expose global ColumnFamily metrics
 --

 Key: CASSANDRA-7273
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7273
 Project: Cassandra
  Issue Type: New Feature
Reporter: Richard Wagner
Assignee: Brandon Williams
Priority: Minor
  Labels: lhf
 Fix For: 1.2.17

 Attachments: 7273-2_1_branch-v1.txt


 It would be very useful to have cassandra expose ColumnFamily metrics that 
 span all column families. A general purpose cassandra monitoring system built 
 up around the current ColumnFamily metrics really only has a couple of 
 choices right now: publish metrics for all column families or fetch metrics 
 for all column families, aggregate them and then publish the aggregated 
 metrics. The first can be quite expensive for the downstream monitoring 
 system and the second is a piece of work that it seems is better pushed into 
 cassandra itself.
 Perhaps these global ColumnFamily metrics could be published under a name of:
 org.apache.cassandra.metrics:type=(ColumnFamily|IndexColumnFamily),name=(Metric
  name)
 (Same as existing ColumnFamily metrics, but with no keyspace or scope.)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7401) Memtable.maybeUpdateLiveRatio goes into an endless loop when currentOperations is zero

2014-06-17 Thread Christian Spriegel (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033894#comment-14033894
 ] 

Christian Spriegel commented on CASSANDRA-7401:
---

Tonight, one of our servers was hanging again.

I now deployed a custom-cassandra with the patch on our systems. I will report 
if it still happens...

 Memtable.maybeUpdateLiveRatio goes into an endless loop when 
 currentOperations is zero
 --

 Key: CASSANDRA-7401
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7401
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Christian Spriegel
Assignee: Christian Spriegel
 Fix For: 2.0.9

 Attachments: MemtableFixV1.patch


 Hi,
 I was describing an error the other day on the mailing list, where the 
 MemoryMeter would go into an endless loop. This happened multiple times last 
 week, unfortunetaly I cannot reproduce it at the moment.
 The whole cassandra server got unresponsive and logged about 7000k messages 
 per second into the log:
 {quote}
 ...
  INFO [MemoryMeter:1] 2014-06-14 19:24:09,488 Memtable.java (line 481) 
 CFS(Keyspace='MDS', ColumnFamily='ResponsePortal') liveRatio is 64.0 
 (just-counted was 64.0).  calculation took 0ms for 0 cells
 ...
 {quote}
 The cause for this seems to be Memtable.maybeUpdateLiveRatio(), which cannot 
 handle currentOperations (and liveRatioComputedAt) to be zero. The loop will 
 iterate endlessly:
 {code}
 ...
 if (operations  2 * last) // does never break when zero: 0  0 
 is not true
 break;
 ...
 {code}
 One thing I cannot explain: How can the operationcount be zero when 
 maybeUpdateLiveRatio() gets called?
 is it possible that addAndGet in resolve() increases by 0  in some cases?
 {code}
 currentOperations.addAndGet(cf.getColumnCount() + (cf.isMarkedForDelete() ? 1 
 : 0) + cf.deletionInfo().rangeCount()); // can this be zero? 
 {code}
 Nevertheless, the attached patch fixes the endless loop. Feel free to 
 reassign this ticket or create a followup ticket if currentOperations should 
 not be zero.
 kind regards,
 Christian



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7273) expose global ColumnFamily metrics


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033932#comment-14033932
 ] 

Brandon Williams commented on CASSANDRA-7273:
-

bq. I'm not a fan of aggregating all CF metrics to global level

I wasn't either, but Richard convinced me it's useful in practice in some 
scenarios.

 expose global ColumnFamily metrics
 --

 Key: CASSANDRA-7273
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7273
 Project: Cassandra
  Issue Type: New Feature
Reporter: Richard Wagner
Assignee: Brandon Williams
Priority: Minor
  Labels: lhf
 Fix For: 1.2.17

 Attachments: 7273-2_1_branch-v1.txt


 It would be very useful to have cassandra expose ColumnFamily metrics that 
 span all column families. A general purpose cassandra monitoring system built 
 up around the current ColumnFamily metrics really only has a couple of 
 choices right now: publish metrics for all column families or fetch metrics 
 for all column families, aggregate them and then publish the aggregated 
 metrics. The first can be quite expensive for the downstream monitoring 
 system and the second is a piece of work that it seems is better pushed into 
 cassandra itself.
 Perhaps these global ColumnFamily metrics could be published under a name of:
 org.apache.cassandra.metrics:type=(ColumnFamily|IndexColumnFamily),name=(Metric
  name)
 (Same as existing ColumnFamily metrics, but with no keyspace or scope.)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7351) Make BEGIN COUNTER BATCH syntax optional

2014-06-17 Thread T Jake Luciani (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033943#comment-14033943
 ] 

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

bq. Should not allow mixing regular and counter mutations in UNLOGGED batches.

Why?  is there a technical reason?

 Make BEGIN COUNTER BATCH syntax optional
 

 Key: CASSANDRA-7351
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7351
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Trivial
  Labels: cql3
 Fix For: 2.1.0

 Attachments: 7351-rebase.txt, 7351.txt


 AFAIK there is no need to supply COUNTER in Batch statements.
 The server should just throw an syntax error if you try to mix counter and 
 non counter statements in the same batch.
 What value does this keyword add?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7273) expose global ColumnFamily metrics

2014-06-17 Thread Chris Lohfink (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033982#comment-14033982
]

Chris Lohfink commented on CASSANDRA-7273:
--

bq. Aggregated histograms can be misleading

Whys that? higher rate of inserts does shorten the window when using exp.
decaying reservoir but its ultimately the same as say - the client request
metrics. I didn't merge the histograms, I created a new ones and replicated
all the updates to them. Some of those histograms would be really helpful too.
ie things like sstables per read and tombstones would be huge win for me
personally when reviewing a new cluster so I can retire a bunch of fabric
scripts.

expose global ColumnFamily metrics
--

Attachments: 7273-2_1_branch-v1.txt

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7405) Optimize cqlsh COPY TO and COPY FROM


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

Sylvain Lebresne updated CASSANDRA-7405:


Fix Version/s: (was: 2.1.0)
   2.1.1

 Optimize cqlsh COPY TO and COPY FROM
 

 Key: CASSANDRA-7405
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7405
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Mikhail Stepura
 Fix For: 2.1.1


 Now that we are using native proto via python-driver, we can, and should, at 
 the very least:
 1. Use proto paging in COPY TO
 2. Use async writes in COPY FROM



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-6766) allow now() - uuid compatibility


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

Sylvain Lebresne updated CASSANDRA-6766:


Labels: cql  (was: )

 allow now() - uuid compatibility
 -

 Key: CASSANDRA-6766
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6766
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
Priority: Minor
  Labels: cql
 Fix For: 2.0.9


 Bad Request: Type error: cannot assign result of function now (type timeuuid) 
 to id (type uuid)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-4762) Support IN clause for any clustering column


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

Sylvain Lebresne updated CASSANDRA-4762:


Labels: cql  (was: cql3)

 Support IN clause for any clustering column
 ---

 Key: CASSANDRA-4762
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4762
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: T Jake Luciani
  Labels: cql
 Fix For: 3.0

 Attachments: 4762-1.txt


 Given CASSANDRA-3885
 It seems it should be possible to store multiple ranges for many predicates 
 even the inner parts of a composite column.
 They could be expressed as a expanded set of filter queries.
 example:
 {code}
 CREATE TABLE test (
name text,
tdate timestamp,
tdate2 timestamp,
tdate3 timestamp,
num double,
PRIMARY KEY(name,tdate,tdate2,tdate3)
  ) WITH COMPACT STORAGE;
 SELECT * FROM test WHERE 
   name IN ('a','b') and
   tdate IN ('2010-01-01','2011-01-01') and
   tdate2 IN ('2010-01-01','2011-01-01') and
   tdate3 IN ('2010-01-01','2011-01-01') 
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-4987) Support more queries when ALLOW FILTERING is used.


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

Sylvain Lebresne updated CASSANDRA-4987:


Labels: cql  (was: )

 Support more queries when ALLOW FILTERING is used.
 --

 Key: CASSANDRA-4987
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4987
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
  Labels: cql
 Fix For: 3.0


 Even after CASSANDRA-4915, there is still a bunch of queries that we don't 
 support even if {{ALLOW FILTERING}} is used. Typically, pretty much any 
 queries with restriction on a non-primary-key column unless we have one of 
 those restriction that is an EQ on an indexed column.
 If {{ALLOW FILTERING}} is used, we could allow those queries out of 
 convenience.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-4914) Custom aggregate and filtering functions in CQL


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

Sylvain Lebresne updated CASSANDRA-4914:


Labels: cql  (was: )

 Custom aggregate and filtering functions in CQL
 ---

 Key: CASSANDRA-4914
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4914
 Project: Cassandra
  Issue Type: New Feature
Reporter: Vijay
  Labels: cql
 Fix For: 3.0


 The requirement is to do aggregation of data in Cassandra (Wide row of column 
 values of int, double, float etc).
 With some basic agree gate functions like AVG, SUM, Mean, Min, Max, etc (for 
 the columns within a row).
 Example:
 SELECT * FROM emp WHERE empID IN (130) ORDER BY deptID DESC;  
   
  empid | deptid | first_name | last_name | salary
 ---+++---+
130 |  3 | joe| doe   |   10.1
130 |  2 | joe| doe   |100
130 |  1 | joe| doe   |  1e+03
  
 SELECT sum(salary), empid FROM emp WHERE empID IN (130);  
   
  sum(salary) | empid
 -+
1110.1|  130



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-4476) Support 2ndary index queries with only non-EQ clauses


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

Sylvain Lebresne updated CASSANDRA-4476:


Labels: cql  (was: )

 Support 2ndary index queries with only non-EQ clauses
 -

 Key: CASSANDRA-4476
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4476
 Project: Cassandra
  Issue Type: Improvement
  Components: API, Core
Reporter: Sylvain Lebresne
Priority: Minor
  Labels: cql
 Fix For: 2.1.1


 Currently, a query that uses 2ndary indexes must have at least one EQ clause 
 (on an indexed column). Given that indexed CFs are local (and use 
 LocalPartitioner that order the row by the type of the indexed column), we 
 should extend 2ndary indexes to allow querying indexed columns even when no 
 EQ clause is provided.
 As far as I can tell, the main problem to solve for this is to update 
 KeysSearcher.highestSelectivityPredicate(). I.e. how do we estimate the 
 selectivity of non-EQ clauses? I note however that if we can do that estimate 
 reasonably accurately, this might provide better performance even for index 
 queries that both EQ and non-EQ clauses, because some non-EQ clauses may have 
 a much better selectivity than EQ ones (say you index both the user country 
 and birth date, for SELECT * FROM users WHERE country = 'US' AND birthdate  
 'Jan 2009' AND birtdate  'July 2009', you'd better use the birthdate index 
 first).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-6382) Allow indexing nested types


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

Sylvain Lebresne updated CASSANDRA-6382:


Labels: cql  (was: )

 Allow indexing nested types
 ---

 Key: CASSANDRA-6382
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6382
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
  Labels: cql
 Fix For: 2.1.1






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-6377) ALLOW FILTERING should allow seq scan filtering


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

Sylvain Lebresne updated CASSANDRA-6377:


Labels: cql  (was: )

 ALLOW FILTERING should allow seq scan filtering
 ---

 Key: CASSANDRA-6377
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6377
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
  Labels: cql
 Fix For: 3.0


 CREATE TABLE emp_table2 (
 empID int PRIMARY KEY,
 firstname text,
 lastname text,
 b_mon text,
 b_day text,
 b_yr text,
 );
 INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
VALUES (100,'jane','doe','oct','31','1980');
 INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
VALUES (101,'john','smith','jan','01','1981');
 INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
VALUES (102,'mary','jones','apr','15','1982');
 INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr) 
VALUES (103,'tim','best','oct','25','1982');

 SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2 
 WHERE b_mon='oct' ALLOW FILTERING;
 Bad Request: No indexed columns present in by-columns clause with Equal 
 operator



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7407) COPY command does not work properly with collections causing failure to import data

2014-06-17 Thread Jose Martinez Poblete (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034024#comment-14034024
 ] 

Jose Martinez Poblete commented on CASSANDRA-7407:
--

Yes, the problem is that COPY command is creating a malformed CSV file.   
That is what needs to be fixed.  Sorry for the confusion!

 COPY command does not work properly with collections causing failure to 
 import data
 ---

 Key: CASSANDRA-7407
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7407
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cqlsh 4.1.1, 
 Cassandra 2.0.7.31,
 CQL spec 3.1.1,
 Thrift protocol 19.39.0
Reporter: Jose Martinez Poblete
  Labels: patch

 The COPY command does not properly format collections in the output CSV - to 
 be able to re-import the data.
 Here is how you can replicate the problem:
 {noformat}
 CREATE TABLE user_colors ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 UPDATE user_colors SET colors = ['red','blue'] WHERE user_id=5; 
 UPDATE user_colors SET colors = ['purple','yellow'] WHERE user_id=6; 
 UPDATE user_colors SET colors = ['black''] WHERE user_id=7;
 COPY user_colors (user_id, colors) TO 'output.csv';
 CREATE TABLE user_colors2 ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 Bad Request: line 1:68 no viable alternative at input ']'
 Aborting import at record #0 (line 1). Previously-inserted values still 
 present.
 0 rows imported in 0.007 seconds.
 {noformat}
 The CSV file seems to be malformed
 - The single quotes within the collection are missing
 - The double quotes for collection on user_id=7 are missing and causing COPY 
 to fail.
 {noformat}
 5,[red, blue]
 7,[black]
 6,[purple, yellow]
 {noformat}
 Should be like this
 {noformat}
 5,['red', 'blue']
 7,['black']
 6,['purple', 'yellow']
 {noformat}
 Once the file is changed, the import works
 {noformat}
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 3 rows imported in 0.012 seconds.
 SELECT * FROM user_colors2;
  user_id | colors
 -+--
5 |  [red, blue]
7 |  [black]
6 | [purple, yellow]
 (3 rows)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CASSANDRA-7401) Memtable.maybeUpdateLiveRatio goes into an endless loop when currentOperations is zero


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

Jonathan Ellis reassigned CASSANDRA-7401:
-

Assignee: Aleksey Yeschenko  (was: Christian Spriegel)

Looks related to the start new memtable w/ the old memtable's liveRatio thing 
we were talking about.

 Memtable.maybeUpdateLiveRatio goes into an endless loop when 
 currentOperations is zero
 --

 Key: CASSANDRA-7401
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7401
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Christian Spriegel
Assignee: Aleksey Yeschenko
 Fix For: 2.0.9

 Attachments: MemtableFixV1.patch


 Hi,
 I was describing an error the other day on the mailing list, where the 
 MemoryMeter would go into an endless loop. This happened multiple times last 
 week, unfortunetaly I cannot reproduce it at the moment.
 The whole cassandra server got unresponsive and logged about 7000k messages 
 per second into the log:
 {quote}
 ...
  INFO [MemoryMeter:1] 2014-06-14 19:24:09,488 Memtable.java (line 481) 
 CFS(Keyspace='MDS', ColumnFamily='ResponsePortal') liveRatio is 64.0 
 (just-counted was 64.0).  calculation took 0ms for 0 cells
 ...
 {quote}
 The cause for this seems to be Memtable.maybeUpdateLiveRatio(), which cannot 
 handle currentOperations (and liveRatioComputedAt) to be zero. The loop will 
 iterate endlessly:
 {code}
 ...
 if (operations  2 * last) // does never break when zero: 0  0 
 is not true
 break;
 ...
 {code}
 One thing I cannot explain: How can the operationcount be zero when 
 maybeUpdateLiveRatio() gets called?
 is it possible that addAndGet in resolve() increases by 0  in some cases?
 {code}
 currentOperations.addAndGet(cf.getColumnCount() + (cf.isMarkedForDelete() ? 1 
 : 0) + cf.deletionInfo().rangeCount()); // can this be zero? 
 {code}
 Nevertheless, the attached patch fixes the endless loop. Feel free to 
 reassign this ticket or create a followup ticket if currentOperations should 
 not be zero.
 kind regards,
 Christian



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7353) Java heap being set too large on Windows with 32-bit JVM


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

Philip Thompson updated CASSANDRA-7353:
---

Labels: Windows qa-resolved  (was: Windows)

 Java heap being set too large on Windows with 32-bit JVM
 

 Key: CASSANDRA-7353
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7353
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows Server 2008, 8G RAM, 32-bit JVM
Reporter: Philip Thompson
Assignee: Joshua McKenzie
Priority: Minor
  Labels: Windows, qa-resolved
 Attachments: 7353_v1.txt, 7353_v2.txt, 7353_v3.txt


 On windows, the JVM settings for max heap size and new gen heap size are set 
 based on the total system memory. When the system has 8G of RAM, the max heap 
 size is set to 2048M. However, according to http://goo.gl/1ElbLm, the 
 recommended max heap for a 32 bit JVM on Windows is 1.8G.
 When cassandra is started on Windows under these conditions, the following 
 error is seen:
 Error occurred during initialization of VM
 Could not reserve enough space for object heap
 Error: Could not create the Java Virtual Machine.
 Error: A fatal exception has occurred. Program will exit.
 Switching to a 64-bit JVM on the same machine solves the issue. If a 32-bit 
 JVM is being used, cassandra should be started up with a smaller heap than 
 would be normally used to prevent the error.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7273) expose global ColumnFamily metrics

2014-06-17 Thread Yuki Morishita (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034069#comment-14034069
 ] 

Yuki Morishita commented on CASSANDRA-7273:
---

I was trying to say that some metrics can be meaningless if combined together.  
For example, 95%tile of global sstables per read can shadow certain column 
family's high sstable read. Or bloom filter false positive ratio. If one is 
high and the other is low, then the global average cannot tell certain CF has 
low fp ratio. (Correct me if I'm wrong.)

So what I'm suggesting is we shuold choose what metrics to be summalized 
globaly.

Also, there already node level latency metrics in StorageProxy, so I don't feel 
the need for one in global CF.

 expose global ColumnFamily metrics
 --

 Key: CASSANDRA-7273
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7273
 Project: Cassandra
  Issue Type: New Feature
Reporter: Richard Wagner
Assignee: Brandon Williams
Priority: Minor
  Labels: lhf
 Fix For: 1.2.17

 Attachments: 7273-2_1_branch-v1.txt


 It would be very useful to have cassandra expose ColumnFamily metrics that 
 span all column families. A general purpose cassandra monitoring system built 
 up around the current ColumnFamily metrics really only has a couple of 
 choices right now: publish metrics for all column families or fetch metrics 
 for all column families, aggregate them and then publish the aggregated 
 metrics. The first can be quite expensive for the downstream monitoring 
 system and the second is a piece of work that it seems is better pushed into 
 cassandra itself.
 Perhaps these global ColumnFamily metrics could be published under a name of:
 org.apache.cassandra.metrics:type=(ColumnFamily|IndexColumnFamily),name=(Metric
  name)
 (Same as existing ColumnFamily metrics, but with no keyspace or scope.)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7408) System hints corruption - dataSize ... would be larger than file

2014-06-17 Thread Jeff Griffith (JIRA)

Jeff Griffith created CASSANDRA-7408:


 Summary: System hints corruption - dataSize ... would be larger 
than file
 Key: CASSANDRA-7408
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7408
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 6.5
Cassandra 1.2.16
RF=3
Thrift
Reporter: Jeff Griffith


I've found several unresolved JIRA tickets related to SSTable corruption but 
not sure if they apply to the case we are seeing in system/hints. We see 
periodic exceptions such as:

{noformat}
dataSize of 144115248479299639 starting at 17209 would be larger than file 
/home/y/var/cassandra/data/system/hints/system-hints-ic-219-Data.db length 35542
{noformat}

Is there something we could possibly be doing from the application to cause 
this sort of corruption? We also see it on some of our own column families also 
some *negative* lengths which are presumably a similar corruption.

{noformat}
ERROR [HintedHandoff:57] 2014-06-17 17:08:04,690 CassandraDaemon.java (line 
191) Exception in thread Thread[HintedHandoff:57,1,main]
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.IOException: 
dataSize of 144115248479299639 starting at 17209 would be larger than file 
/home/y/var/cassandra/data/system/hints/system-hints-ic-219-Data.db length 35542
at 
org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:441)
at 
org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:282)
at 
org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:90)
at 
org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:508)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.ExecutionException: 
org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.IOException: 
dataSize of 144115248479299639 starting at 17209 would be larger than file 
/home/y/var/cassandra/data/system/hints/system-hints-ic-219-Data.db length 35542
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at 
org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:437)
... 6 more
Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
java.io.IOException: dataSize of 144115248479299639 starting at 17209 would be 
larger than file 
/home/y/var/cassandra/data/system/hints/system-hints-ic-219-Data.db length 35542
at 
org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:167)
at 
org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:83)
at 
org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:69)
at 
org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:180)
at 
org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:155)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:142)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:38)
at 
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:145)
at 
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:122)
at 
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:96)
at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at 
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:145)
at 
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:58)
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
at 
org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:442)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
... 3

[jira] [Commented] (CASSANDRA-7273) expose global ColumnFamily metrics

[
https://issues.apache.org/jira/browse/CASSANDRA-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034080#comment-14034080
]

Brandon Williams commented on CASSANDRA-7273:
-

bq. I was trying to say that some metrics can be meaningless if combined
together. For example, 95%tile of global sstables per read can shadow certain
column family's high sstable read. Or bloom filter false positive ratio. If one
is high and the other is low, then the global average cannot tell certain CF
has low fp ratio. (Correct me if I'm wrong.)

This was my exact reasoning as well, but [~rfwag...@gmail.com] convinced that
in practice, it actually was helpful. Keep in mind though this isn't an
average, just another histogram with totals.

bq. Also, there already node level latency metrics in StorageProxy, so I don't
feel the need for one in global CF.

SP latency is different from local latency though.

expose global ColumnFamily metrics
--

Attachments: 7273-2_1_branch-v1.txt

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7139) Default concurrent_compactors is probably too high

2014-06-17 Thread Jeremiah Jordan (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034093#comment-14034093
 ] 

Jeremiah Jordan commented on CASSANDRA-7139:


Can we get this change in 2.0?  Have had the default concurrent compactors 
causes issues on a few clusters.

 Default concurrent_compactors is probably too high
 --

 Key: CASSANDRA-7139
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7139
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 2.1 rc1

 Attachments: 7139.txt


 The default number of concurrent compactors is probably too high for modern 
 hardware with spinning disks for storage: A modern blade can easily have 24+ 
 Cores, which would result in a default of 24 concurrent compactions. This not 
 only increases random IO, it also keeps around a lot of obsoleted files for 
 an unnecessarily long time, as each compaction keeps references to any 
 possibly overlapping files that it isn't itself compacting - but these can 
 have been obsoleted part way through by compactions that finished earlier. If 
 you factor in the default compaction throughput rate of 16Mb/s, anything but 
 a single default concurrent_compactor makes very little sense, as a single 
 thread should always be able to handle 16Mb/s, will cause less interference 
 with other processes, and permits obsoleted files to be immediately removed.
 See [http://imgur.com/HDqhxFp] for a graph demonstrating the result of making 
 this change on a box with 24-cores and 8Tb of storage (first spike is default 
 settings)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7409) Allow multiple overlapping sstables in L1

2014-06-17 Thread Carl Yeksigian (JIRA)

Carl Yeksigian created CASSANDRA-7409:
-

 Summary: Allow multiple overlapping sstables in L1
 Key: CASSANDRA-7409
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7409
 Project: Cassandra
  Issue Type: Improvement
Reporter: Carl Yeksigian
Assignee: Carl Yeksigian


Currently, when a normal L0 compaction takes place (not STCS), we take up to 
MAX_COMPACTING_L0 L0 sstables and all of the overlapping L1 sstables and 
compact them together. If we didn't have to deal with the overlapping L1 
tables, we could compact a higher number of L0 sstables together into a set of 
non-overlapping L1 sstables.

This could be done by delaying the invariant that L1 has no overlapping 
sstables. Going from L1 to L2, we would be compacting fewer sstables together 
which overlap.

When reading, we will not have the same one sstable per level (except L0) 
guarantee, but this can be bounded (once we have too many sets of sstables, 
either compact them back into the same level, or compact them up to the next 
level).

This could be generalized to allow any level to be the maximum for this 
overlapping strategy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7411) Node enables vnodes when bounced

Philip Thompson created CASSANDRA-7411:
--

 Summary: Node enables vnodes when bounced
 Key: CASSANDRA-7411
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7411
 Project: Cassandra
  Issue Type: Bug
 Environment: OSX 9
Reporter: Philip Thompson
 Attachments: system.log

According to cassandra.yaml, in the information for the num_tokens setting, 
Specifying initial_token will override this setting. So if exactly one 
initial token is set, then vnodes are disabled, regardless of if or what 
num_tokens are set to. This behavior is inconsistent when a node is started, 
versus if it has been bounced.

From a fresh checkout of C*, if I build, then edit cassandra.yaml so that:

num_tokens: 256
initial_token: -9223372036854775808

then run bin/cassandra, C* will start correctly. I can run bin/nodetool ring 
and see that the node has exactly one token and it is what I set in 
initial_token. If I gracefully shutdown C*, then restart the node, running 
bin/nodetool ring shows that the node now has vnodes enabled and has 256 tokens.

I have been able to reproduce this locally on OSX using 2.0.8, 2.1 rc1, and 
trunk. I have not yet tested in Linux or Windows to see if it occurs there.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization

2014-06-17 Thread Robert Stupp (JIRA)


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

Robert Stupp updated CASSANDRA-7386:


Attachment: 7386v2.diff
Mappe1.ods

Here's a working version of the patch.

It adds new metrics to each data directory:
* {{readTasks}} counts the read requests
* {{writeTasks}} counts the write requests
* {{writeValue*}} exposes the write value for each data directory for mean, 
one/five/fifteen minutes

The data directory with the highest write value is chosen for new sstables.

Write value is calculated using the formula:
{{freeRatio / weightedRate}} where {{freeRatio = availableBytes / totalBytes}} 
and {{weightedRate = writeRate + readRate / 2}}. divide by 2 has been 
randomly chosen since not every read operation hits the disks.

{{readRate}} is taken from {{SSTableReader.incrementReadCount()}} but I had to 
add a call to {{incrementReadCount()}} to some classes in code. I did not add 
it to {{RandomAccessReader}} or {{SegmentedFile}} because this patch should not 
influence performance too much.

I did not experience much with the formula but created a sheet ({{Mappe1.ods}}) 
that shows the write value in a matrix if freeRatio vs. weightedRate.

I've run {{cassandra-stress}} against (a single node, single data-directory) C* 
instance and saw that the writeValue behaves as expected.

But that's only half the battle. The patch has to be verified in a real 
production like cluster. weight value needs to be compared with {{iostat}}, 
{{df}} etc. Is there any possibility to do that?

 JBOD threshold to prevent unbalanced disk utilization
 -

 Key: CASSANDRA-7386
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7386
 Project: Cassandra
  Issue Type: Improvement
Reporter: Chris Lohfink
Priority: Minor
 Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, 
 patch_2_1_branch_proto.diff


 Currently the pick the disks are picked first by number of current tasks, 
 then by free space.  This helps with performance but can lead to large 
 differences in utilization in some (unlikely but possible) scenarios.  Ive 
 seen 55% to 10% and heard reports of 90% to 10% on IRC.  With both LCS and 
 STCS (although my suspicion is that STCS makes it worse since harder to be 
 balanced).
 I purpose the algorithm change a little to have some maximum range of 
 utilization where it will pick by free space over load (acknowledging it can 
 be slower).  So if a disk A is 30% full and disk B is 5% full it will never 
 pick A over B until it balances out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7351) Make BEGIN COUNTER BATCH syntax optional

2014-06-17 Thread T Jake Luciani (JIRA)


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

T Jake Luciani updated CASSANDRA-7351:
--

Attachment: 7351v2.txt

v2 rejects mixed batches and fixes the BatchMessage checks

 Make BEGIN COUNTER BATCH syntax optional
 

 Key: CASSANDRA-7351
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7351
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Trivial
  Labels: cql3
 Fix For: 2.1.0

 Attachments: 7351-rebase.txt, 7351.txt, 7351v2.txt


 AFAIK there is no need to supply COUNTER in Batch statements.
 The server should just throw an syntax error if you try to mix counter and 
 non counter statements in the same batch.
 What value does this keyword add?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[1/2] git commit: Upgrade netty to 4.0.20

2014-06-17 Thread jake

Repository: cassandra
Updated Branches:
  refs/heads/trunk 5bd5e25fb - 805a4aeeb


Upgrade netty to 4.0.20


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

Branch: refs/heads/trunk
Commit: a3dc7b8b41b4b0a3f18523fa6685f7179054a9ca
Parents: a14a01c
Author: Jake Luciani j...@apache.org
Authored: Tue Jun 17 15:09:03 2014 -0400
Committer: Jake Luciani j...@apache.org
Committed: Tue Jun 17 15:09:03 2014 -0400

--
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.19.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.20.Final.txt | 202 +++
 lib/netty-all-4.0.19.Final.jar  | Bin 1678810 - 0 bytes
 lib/netty-all-4.0.20.Final.jar  | Bin 0 - 1721619 bytes
 5 files changed, 203 insertions(+), 203 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a3dc7b8b/build.xml
--
diff --git a/build.xml b/build.xml
index 15986d1..26c360c 100644
--- a/build.xml
+++ b/build.xml
@@ -396,7 +396,7 @@
   dependency groupId=com.addthis.metrics 
artifactId=reporter-config version=2.1.0 /
   dependency groupId=org.mindrot artifactId=jbcrypt 
version=0.3m /
   dependency groupId=io.airlift artifactId=airline version=0.6 
/
-  dependency groupId=io.netty artifactId=netty-all 
version=4.0.19.Final /
+  dependency groupId=io.netty artifactId=netty-all 
version=4.0.20.Final /
   dependency groupId=com.google.code.findbugs artifactId=jsr305 
version=2.0.2 /
   dependency groupId=com.clearspring.analytics artifactId=stream 
version=2.5.2 /
   dependency groupId=com.datastax.cassandra 
artifactId=cassandra-driver-core version=2.0.1 /

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a3dc7b8b/lib/licenses/netty-all-4.0.19.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.19.Final.txt 
b/lib/licenses/netty-all-4.0.19.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.19.Final.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 shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works that remain
-  separable from, or merely link (or bind by name) to the interfaces of,
-  the Work and Derivative Works thereof.
-
-  Contribution shall mean any work of authorship, including
-  the original version of the Work and

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

2014-06-17 Thread jake

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/805a4aee
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/805a4aee
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/805a4aee

Branch: refs/heads/trunk
Commit: 805a4aeebe0ef62159951781a294c40e5be3efe7
Parents: 5bd5e25 a3dc7b8
Author: Jake Luciani j...@apache.org
Authored: Tue Jun 17 15:09:31 2014 -0400
Committer: Jake Luciani j...@apache.org
Committed: Tue Jun 17 15:09:31 2014 -0400

--
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.19.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.20.Final.txt | 202 +++
 lib/netty-all-4.0.19.Final.jar  | Bin 1678810 - 0 bytes
 lib/netty-all-4.0.20.Final.jar  | Bin 0 - 1721619 bytes
 5 files changed, 203 insertions(+), 203 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/805a4aee/build.xml
--

git commit: Upgrade netty to 4.0.20

2014-06-17 Thread jake

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 a14a01c92 - a3dc7b8b4


Upgrade netty to 4.0.20


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

Branch: refs/heads/cassandra-2.1
Commit: a3dc7b8b41b4b0a3f18523fa6685f7179054a9ca
Parents: a14a01c
Author: Jake Luciani j...@apache.org
Authored: Tue Jun 17 15:09:03 2014 -0400
Committer: Jake Luciani j...@apache.org
Committed: Tue Jun 17 15:09:03 2014 -0400

--
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.19.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.20.Final.txt | 202 +++
 lib/netty-all-4.0.19.Final.jar  | Bin 1678810 - 0 bytes
 lib/netty-all-4.0.20.Final.jar  | Bin 0 - 1721619 bytes
 5 files changed, 203 insertions(+), 203 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a3dc7b8b/build.xml
--
diff --git a/build.xml b/build.xml
index 15986d1..26c360c 100644
--- a/build.xml
+++ b/build.xml
@@ -396,7 +396,7 @@
   dependency groupId=com.addthis.metrics 
artifactId=reporter-config version=2.1.0 /
   dependency groupId=org.mindrot artifactId=jbcrypt 
version=0.3m /
   dependency groupId=io.airlift artifactId=airline version=0.6 
/
-  dependency groupId=io.netty artifactId=netty-all 
version=4.0.19.Final /
+  dependency groupId=io.netty artifactId=netty-all 
version=4.0.20.Final /
   dependency groupId=com.google.code.findbugs artifactId=jsr305 
version=2.0.2 /
   dependency groupId=com.clearspring.analytics artifactId=stream 
version=2.5.2 /
   dependency groupId=com.datastax.cassandra 
artifactId=cassandra-driver-core version=2.0.1 /

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a3dc7b8b/lib/licenses/netty-all-4.0.19.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.19.Final.txt 
b/lib/licenses/netty-all-4.0.19.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.19.Final.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 shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works that remain
-  separable from, or merely link (or bind by name) to the interfaces of,
-  the Work and Derivative Works thereof.
-
-  Contribution shall mean any work of authorship, including
-  the original version

[jira] [Created] (CASSANDRA-7412) Create new BulkOutputFormat to use CQLSSTableWriter

Alex Liu created CASSANDRA-7412:
---

 Summary: Create new BulkOutputFormat to use CQLSSTableWriter
 Key: CASSANDRA-7412
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7412
 Project: Cassandra
  Issue Type: Improvement
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
Priority: Minor


Create new BulkOutputFormat to use CQLSSTableWriter. The interface may need 
change.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7412) Create new BulkOutputFormat to use CQLSSTableWriter

2014-06-17 Thread Jeremy Hanna (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034251#comment-14034251
 ] 

Jeremy Hanna commented on CASSANDRA-7412:
-

See also CASSANDRA-6927

 Create new BulkOutputFormat to use CQLSSTableWriter
 ---

 Key: CASSANDRA-7412
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7412
 Project: Cassandra
  Issue Type: Improvement
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
Priority: Minor

 Create new BulkOutputFormat to use CQLSSTableWriter. The interface may need 
 change.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

buildbot success in ASF Buildbot on cassandra-trunk

2014-06-17 Thread buildbot

The Buildbot has detected a restored build on builder cassandra-trunk while 
building cassandra.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/335

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch trunk] 805a4aeebe0ef62159951781a294c40e5be3efe7
Blamelist: Jake Luciani j...@apache.org

Build succeeded!

sincerely,
 -The Buildbot

[jira] [Commented] (CASSANDRA-7351) Make BEGIN COUNTER BATCH syntax optional


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034289#comment-14034289
 ] 

Aleksey Yeschenko commented on CASSANDRA-7351:
--

Looks correct to me. That said, looking at the bigger picture, we should 
refactor BatchStatement a bit (this does contradict my initial remarks, sorry).

1. Should move all the validation from Parsed#prepare() to 
BatchStatement#validate() - including Batch with conditions cannot span 
multiple tables
2. Should remove, really, not update, the counter validation logic from 
BatchMessage, and rely on BS#validate() instead - it will get called by 
processBatch() down the line. No need to duplicate this logic in two places.

 Make BEGIN COUNTER BATCH syntax optional
 

 Key: CASSANDRA-7351
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7351
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Trivial
  Labels: cql3
 Fix For: 2.1.0

 Attachments: 7351-rebase.txt, 7351.txt, 7351v2.txt


 AFAIK there is no need to supply COUNTER in Batch statements.
 The server should just throw an syntax error if you try to mix counter and 
 non counter statements in the same batch.
 What value does this keyword add?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7139) Default concurrent_compactors is probably too high


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034309#comment-14034309
 ] 

Jonathan Ellis commented on CASSANDRA-7139:
---

I don't like changing defaults out from under people mid-release.  Makes for an 
unpleasant surprise if those defaults were working for you.

 Default concurrent_compactors is probably too high
 --

 Key: CASSANDRA-7139
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7139
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 2.1 rc1

 Attachments: 7139.txt


 The default number of concurrent compactors is probably too high for modern 
 hardware with spinning disks for storage: A modern blade can easily have 24+ 
 Cores, which would result in a default of 24 concurrent compactions. This not 
 only increases random IO, it also keeps around a lot of obsoleted files for 
 an unnecessarily long time, as each compaction keeps references to any 
 possibly overlapping files that it isn't itself compacting - but these can 
 have been obsoleted part way through by compactions that finished earlier. If 
 you factor in the default compaction throughput rate of 16Mb/s, anything but 
 a single default concurrent_compactor makes very little sense, as a single 
 thread should always be able to handle 16Mb/s, will cause less interference 
 with other processes, and permits obsoleted files to be immediately removed.
 See [http://imgur.com/HDqhxFp] for a graph demonstrating the result of making 
 this change on a box with 24-cores and 8Tb of storage (first spike is default 
 settings)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7412) Create new BulkOutputFormat to use CQLSSTableWriter


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

Alex Liu resolved CASSANDRA-7412.
-

Resolution: Duplicate

 Create new BulkOutputFormat to use CQLSSTableWriter
 ---

 Key: CASSANDRA-7412
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7412
 Project: Cassandra
  Issue Type: Improvement
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
Priority: Minor

 Create new BulkOutputFormat to use CQLSSTableWriter. The interface may need 
 change.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization


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

Jonathan Ellis updated CASSANDRA-7386:
--

Reviewer: Yuki Morishita
Assignee: Robert Stupp

 JBOD threshold to prevent unbalanced disk utilization
 -

 Key: CASSANDRA-7386
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7386
 Project: Cassandra
  Issue Type: Improvement
Reporter: Chris Lohfink
Assignee: Robert Stupp
Priority: Minor
 Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, 
 patch_2_1_branch_proto.diff


 Currently the pick the disks are picked first by number of current tasks, 
 then by free space.  This helps with performance but can lead to large 
 differences in utilization in some (unlikely but possible) scenarios.  Ive 
 seen 55% to 10% and heard reports of 90% to 10% on IRC.  With both LCS and 
 STCS (although my suspicion is that STCS makes it worse since harder to be 
 balanced).
 I purpose the algorithm change a little to have some maximum range of 
 utilization where it will pick by free space over load (acknowledging it can 
 be slower).  So if a disk A is 30% full and disk B is 5% full it will never 
 pick A over B until it balances out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034313#comment-14034313
 ] 

Jonathan Ellis commented on CASSANDRA-7386:
---

[~yukim] to review

 JBOD threshold to prevent unbalanced disk utilization
 -

 Key: CASSANDRA-7386
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7386
 Project: Cassandra
  Issue Type: Improvement
Reporter: Chris Lohfink
Assignee: Robert Stupp
Priority: Minor
 Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, 
 patch_2_1_branch_proto.diff


 Currently the pick the disks are picked first by number of current tasks, 
 then by free space.  This helps with performance but can lead to large 
 differences in utilization in some (unlikely but possible) scenarios.  Ive 
 seen 55% to 10% and heard reports of 90% to 10% on IRC.  With both LCS and 
 STCS (although my suspicion is that STCS makes it worse since harder to be 
 balanced).
 I purpose the algorithm change a little to have some maximum range of 
 utilization where it will pick by free space over load (acknowledging it can 
 be slower).  So if a disk A is 30% full and disk B is 5% full it will never 
 pick A over B until it balances out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6927) Create a CQL3 based bulk OutputFormat


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034314#comment-14034314
 ] 

Alex Liu commented on CASSANDRA-6927:
-

[~sixpak32577] I will take your code and make some interface changes.

 Create a CQL3 based bulk OutputFormat
 -

 Key: CASSANDRA-6927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6927
 Project: Cassandra
  Issue Type: New Feature
  Components: Hadoop
Reporter: Paul Pak
Priority: Minor
  Labels: cql3, hadoop
 Attachments: trunk-6927.txt


 This is the CQL compatible version of BulkOutputFormat.  CqlOutputFormat 
 exists, but doesn't write SSTables directly, similar to 
 ColumnFamilyOutputFormat for thrift.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7351) Make BEGIN COUNTER BATCH syntax optional

2014-06-17 Thread T Jake Luciani (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034319#comment-14034319
 ] 

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

BatchStatement.validate() is called on every execute() shouldn't we only need 
these checks in prepare()?





 Make BEGIN COUNTER BATCH syntax optional
 

 Key: CASSANDRA-7351
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7351
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Trivial
  Labels: cql3
 Fix For: 2.1.0

 Attachments: 7351-rebase.txt, 7351.txt, 7351v2.txt


 AFAIK there is no need to supply COUNTER in Batch statements.
 The server should just throw an syntax error if you try to mix counter and 
 non counter statements in the same batch.
 What value does this keyword add?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7060) Clean up unit tests on Windows

2014-06-17 Thread Joshua McKenzie (JIRA)


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

Joshua McKenzie resolved CASSANDRA-7060.


Resolution: Fixed

Unit tests on trunk as of 6/17 are in parity.  Can handle future divergence on 
a case by case basis.

 Clean up unit tests on Windows
 --

 Key: CASSANDRA-7060
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7060
 Project: Cassandra
  Issue Type: Bug
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Priority: Minor
  Labels: Windows
 Fix For: 3.0


 Currently we have unit tests failing on Windows that aren't failing on Unix.  
 We need to have parity on unit tests between platforms for future 
 multi-platform development.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6927) Create a CQL3 based bulk OutputFormat

2014-06-17 Thread Paul Pak (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034378#comment-14034378
 ] 

Paul Pak commented on CASSANDRA-6927:
-

@alexliu68 What type of interface changes did you have in mind?

 Create a CQL3 based bulk OutputFormat
 -

 Key: CASSANDRA-6927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6927
 Project: Cassandra
  Issue Type: New Feature
  Components: Hadoop
Reporter: Paul Pak
Priority: Minor
  Labels: cql3, hadoop
 Attachments: trunk-6927.txt


 This is the CQL compatible version of BulkOutputFormat.  CqlOutputFormat 
 exists, but doesn't write SSTables directly, similar to 
 ColumnFamilyOutputFormat for thrift.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-6927) Create a CQL3 based bulk OutputFormat

2014-06-17 Thread Paul Pak (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034378#comment-14034378
 ] 

Paul Pak edited comment on CASSANDRA-6927 at 6/17/14 9:13 PM:
--

[~alexliu68] What type of interface changes did you have in mind?


was (Author: sixpak32577):
@alexliu68 What type of interface changes did you have in mind?

 Create a CQL3 based bulk OutputFormat
 -

 Key: CASSANDRA-6927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6927
 Project: Cassandra
  Issue Type: New Feature
  Components: Hadoop
Reporter: Paul Pak
Priority: Minor
  Labels: cql3, hadoop
 Attachments: trunk-6927.txt


 This is the CQL compatible version of BulkOutputFormat.  CqlOutputFormat 
 exists, but doesn't write SSTables directly, similar to 
 ColumnFamilyOutputFormat for thrift.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7411) Node enables vnodes when bounced

[
https://issues.apache.org/jira/browse/CASSANDRA-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034427#comment-14034427
]

Brandon Williams commented on CASSANDRA-7411:
-

This is because once the initial_token is set in the system table, it's unused
from the yaml afterward. Upon rebooted the num_tokens takes precedence, as
that would be the procedure to begin upgrading to vnodes. You really shouldn't
ever set both of these, especially with a single initial_token.

Node enables vnodes when bounced

Key: CASSANDRA-7411
URL: https://issues.apache.org/jira/browse/CASSANDRA-7411
Project: Cassandra
Issue Type: Bug
Environment: OSX 9
Reporter: Philip Thompson
Attachments: system.log

According to cassandra.yaml, in the information for the num_tokens setting,
Specifying initial_token will override this setting. So if exactly one
initial token is set, then vnodes are disabled, regardless of if or what
num_tokens are set to. This behavior is inconsistent when a node is started,
versus if it has been bounced.
From a fresh checkout of C*, if I build, then edit cassandra.yaml so that:
num_tokens: 256
initial_token: -9223372036854775808
then run bin/cassandra, C* will start correctly. I can run bin/nodetool ring
and see that the node has exactly one token and it is what I set in
initial_token. If I gracefully shutdown C*, then restart the node, running
bin/nodetool ring shows that the node now has vnodes enabled and has 256
tokens.
I have been able to reproduce this locally on OSX using 2.0.8, 2.1 rc1, and
trunk. I have not yet tested in Linux or Windows to see if it occurs there.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7407) COPY command does not work properly with collections causing failure to import data


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

Brandon Williams updated CASSANDRA-7407:


Fix Version/s: 2.0.9

 COPY command does not work properly with collections causing failure to 
 import data
 ---

 Key: CASSANDRA-7407
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7407
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cqlsh 4.1.1, 
 Cassandra 2.0.7.31,
 CQL spec 3.1.1,
 Thrift protocol 19.39.0
Reporter: Jose Martinez Poblete
Assignee: Mikhail Stepura
  Labels: patch
 Fix For: 2.0.9


 The COPY command does not properly format collections in the output CSV - to 
 be able to re-import the data.
 Here is how you can replicate the problem:
 {noformat}
 CREATE TABLE user_colors ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 UPDATE user_colors SET colors = ['red','blue'] WHERE user_id=5; 
 UPDATE user_colors SET colors = ['purple','yellow'] WHERE user_id=6; 
 UPDATE user_colors SET colors = ['black''] WHERE user_id=7;
 COPY user_colors (user_id, colors) TO 'output.csv';
 CREATE TABLE user_colors2 ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 Bad Request: line 1:68 no viable alternative at input ']'
 Aborting import at record #0 (line 1). Previously-inserted values still 
 present.
 0 rows imported in 0.007 seconds.
 {noformat}
 The CSV file seems to be malformed
 - The single quotes within the collection are missing
 - The double quotes for collection on user_id=7 are missing and causing COPY 
 to fail.
 {noformat}
 5,[red, blue]
 7,[black]
 6,[purple, yellow]
 {noformat}
 Should be like this
 {noformat}
 5,['red', 'blue']
 7,['black']
 6,['purple', 'yellow']
 {noformat}
 Once the file is changed, the import works
 {noformat}
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 3 rows imported in 0.012 seconds.
 SELECT * FROM user_colors2;
  user_id | colors
 -+--
5 |  [red, blue]
7 |  [black]
6 | [purple, yellow]
 (3 rows)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CASSANDRA-7407) COPY command does not work properly with collections causing failure to import data


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

Brandon Williams reassigned CASSANDRA-7407:
---

Assignee: Mikhail Stepura

 COPY command does not work properly with collections causing failure to 
 import data
 ---

 Key: CASSANDRA-7407
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7407
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cqlsh 4.1.1, 
 Cassandra 2.0.7.31,
 CQL spec 3.1.1,
 Thrift protocol 19.39.0
Reporter: Jose Martinez Poblete
Assignee: Mikhail Stepura
  Labels: patch
 Fix For: 2.0.9


 The COPY command does not properly format collections in the output CSV - to 
 be able to re-import the data.
 Here is how you can replicate the problem:
 {noformat}
 CREATE TABLE user_colors ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 UPDATE user_colors SET colors = ['red','blue'] WHERE user_id=5; 
 UPDATE user_colors SET colors = ['purple','yellow'] WHERE user_id=6; 
 UPDATE user_colors SET colors = ['black''] WHERE user_id=7;
 COPY user_colors (user_id, colors) TO 'output.csv';
 CREATE TABLE user_colors2 ( 
 user_id int PRIMARY KEY, 
 colors listascii 
 );
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 Bad Request: line 1:68 no viable alternative at input ']'
 Aborting import at record #0 (line 1). Previously-inserted values still 
 present.
 0 rows imported in 0.007 seconds.
 {noformat}
 The CSV file seems to be malformed
 - The single quotes within the collection are missing
 - The double quotes for collection on user_id=7 are missing and causing COPY 
 to fail.
 {noformat}
 5,[red, blue]
 7,[black]
 6,[purple, yellow]
 {noformat}
 Should be like this
 {noformat}
 5,['red', 'blue']
 7,['black']
 6,['purple', 'yellow']
 {noformat}
 Once the file is changed, the import works
 {noformat}
 COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
 3 rows imported in 0.012 seconds.
 SELECT * FROM user_colors2;
  user_id | colors
 -+--
5 |  [red, blue]
7 |  [black]
6 | [purple, yellow]
 (3 rows)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-6927) Create a CQL3 based bulk OutputFormat


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

Alex Liu updated CASSANDRA-6927:


Attachment: 6927-2.0-branch-v2.txt

 Create a CQL3 based bulk OutputFormat
 -

 Key: CASSANDRA-6927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6927
 Project: Cassandra
  Issue Type: New Feature
  Components: Hadoop
Reporter: Paul Pak
Priority: Minor
  Labels: cql3, hadoop
 Attachments: 6927-2.0-branch-v2.txt, trunk-6927.txt


 This is the CQL compatible version of BulkOutputFormat.  CqlOutputFormat 
 exists, but doesn't write SSTables directly, similar to 
 ColumnFamilyOutputFormat for thrift.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6927) Create a CQL3 based bulk OutputFormat


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034441#comment-14034441
 ] 

Alex Liu commented on CASSANDRA-6927:
-

v2 on cassandra-2.0 branch is attached. It change the interface from 
OutputFormatByteBuffer,ListMutation to OutputFormatObject, ListMutation 
where Object is a placeholder for an object, but internally it's not used, so 
it can just be null object. ListMutation is the binder variable values to the 
insert statement.

I also remove the . + columnFamily  in
{code}
private String getColumnFamilySchema()
{
return conf.get(COLUMNFAMILY_SCHEMA + . + columnFamily);
}

private String getColumnFamilyInsertStatement()
{
return conf.get(COLUMNFAMILY_INSERT_STATEMENT + . + columnFamily);
}
{code}

and some code format clean up

 Create a CQL3 based bulk OutputFormat
 -

 Key: CASSANDRA-6927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6927
 Project: Cassandra
  Issue Type: New Feature
  Components: Hadoop
Reporter: Paul Pak
Priority: Minor
  Labels: cql3, hadoop
 Attachments: 6927-2.0-branch-v2.txt, trunk-6927.txt


 This is the CQL compatible version of BulkOutputFormat.  CqlOutputFormat 
 exists, but doesn't write SSTables directly, similar to 
 ColumnFamilyOutputFormat for thrift.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-6927) Create a CQL3 based bulk OutputFormat


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034441#comment-14034441
 ] 

Alex Liu edited comment on CASSANDRA-6927 at 6/17/14 9:54 PM:
--

v2 on cassandra-2.0 branch is attached. It changes the interface from 
OutputFormatByteBuffer,ListMutation to OutputFormatObject, ListMutation 
where Object is a placeholder for an object, but internally it's not used, so 
it can just be null object. ListMutation is the binder variable values to the 
insert statement.

I also remove the . + columnFamily  in
{code}
private String getColumnFamilySchema()
{
return conf.get(COLUMNFAMILY_SCHEMA + . + columnFamily);
}

private String getColumnFamilyInsertStatement()
{
return conf.get(COLUMNFAMILY_INSERT_STATEMENT + . + columnFamily);
}
{code}

and some code format clean up


was (Author: alexliu68):
v2 on cassandra-2.0 branch is attached. It change the interface from 
OutputFormatByteBuffer,ListMutation to OutputFormatObject, ListMutation 
where Object is a placeholder for an object, but internally it's not used, so 
it can just be null object. ListMutation is the binder variable values to the 
insert statement.

I also remove the . + columnFamily  in
{code}
private String getColumnFamilySchema()
{
return conf.get(COLUMNFAMILY_SCHEMA + . + columnFamily);
}

private String getColumnFamilyInsertStatement()
{
return conf.get(COLUMNFAMILY_INSERT_STATEMENT + . + columnFamily);
}
{code}

and some code format clean up

 Create a CQL3 based bulk OutputFormat
 -

 Key: CASSANDRA-6927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6927
 Project: Cassandra
  Issue Type: New Feature
  Components: Hadoop
Reporter: Paul Pak
Priority: Minor
  Labels: cql3, hadoop
 Attachments: 6927-2.0-branch-v2.txt, trunk-6927.txt


 This is the CQL compatible version of BulkOutputFormat.  CqlOutputFormat 
 exists, but doesn't write SSTables directly, similar to 
 ColumnFamilyOutputFormat for thrift.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-6927) Create a CQL3 based bulk OutputFormat


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034441#comment-14034441
 ] 

Alex Liu edited comment on CASSANDRA-6927 at 6/17/14 9:56 PM:
--

v2 on cassandra-2.0 branch is attached. It changes the interface from 
OutputFormatListByteBuffer, ListByteBuffer to OutputFormatObject, 
ListMutation where Object is a placeholder for an object, but internally 
it's not used, so it can just be null object. ListMutation is the binder 
variable values to the insert statement.

I also remove the . + columnFamily  in
{code}
private String getColumnFamilySchema()
{
return conf.get(COLUMNFAMILY_SCHEMA + . + columnFamily);
}

private String getColumnFamilyInsertStatement()
{
return conf.get(COLUMNFAMILY_INSERT_STATEMENT + . + columnFamily);
}
{code}

and some code format clean up


was (Author: alexliu68):
v2 on cassandra-2.0 branch is attached. It changes the interface from 
OutputFormatByteBuffer,ListMutation to OutputFormatObject, ListMutation 
where Object is a placeholder for an object, but internally it's not used, so 
it can just be null object. ListMutation is the binder variable values to the 
insert statement.

I also remove the . + columnFamily  in
{code}
private String getColumnFamilySchema()
{
return conf.get(COLUMNFAMILY_SCHEMA + . + columnFamily);
}

private String getColumnFamilyInsertStatement()
{
return conf.get(COLUMNFAMILY_INSERT_STATEMENT + . + columnFamily);
}
{code}

and some code format clean up

 Create a CQL3 based bulk OutputFormat
 -

 Key: CASSANDRA-6927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6927
 Project: Cassandra
  Issue Type: New Feature
  Components: Hadoop
Reporter: Paul Pak
Priority: Minor
  Labels: cql3, hadoop
 Attachments: 6927-2.0-branch-v2.txt, trunk-6927.txt


 This is the CQL compatible version of BulkOutputFormat.  CqlOutputFormat 
 exists, but doesn't write SSTables directly, similar to 
 ColumnFamilyOutputFormat for thrift.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CASSANDRA-7318) Unable to truncate column family on node which has been decommissioned and re-bootstrapped


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

Brandon Williams reassigned CASSANDRA-7318:
---

Assignee: Brandon Williams  (was: Yuki Morishita)

 Unable to truncate column family on node which has been decommissioned and 
 re-bootstrapped
 --

 Key: CASSANDRA-7318
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7318
 Project: Cassandra
  Issue Type: Bug
 Environment: Seen running cassandra 2.0.7 running on Red Hat Linux
Reporter: Thomas Whiteway
Assignee: Brandon Williams
Priority: Minor

 After decommissioning a node, then re-bootstrapping it, it's not possible to 
 truncate column families until cassandra is restarted.
 Steps to reproduce:
 - Start with a two node deployment (nodes A and B)
 - Run nodetool decommission on node B
 - Stop cassandra on node B
 - Delete the contents of the cassandra data and commitlog directories
 - Start cassandra on node B with node A as the seed
 - Run cqlsh on node B and try to truncate a column family
 - cqlsh displays: Unable to complete request: one or more nodes were 
 unavailable.
 According to the logs node B seems to think that itself is down.  The follow 
 logs appear when the server is started and there are no further logs to 
 indicate the B is now UP (A=10.225.45.150, B=10.225.45.151):
  INFO [main] 2014-05-29 10:40:11,090 MessagingService.java (line 461) 
 Starting Messaging Service on port 7000
  INFO [HANDSHAKE-/10.225.45.150] 2014-05-29 10:40:11,106 
 OutboundTcpConnection.java (line 386) Handshaking version with /10.225.45.150
  INFO [GossipStage:1] 2014-05-29 10:40:11,182 Gossiper.java (line 903) Node 
 /10.225.45.150 is now part of the cluster
  INFO [GossipStage:1] 2014-05-29 10:40:11,185 Gossiper.java (line 883) 
 InetAddress /10.225.45.151 is now DOWN
  INFO [RequestResponseStage:1] 2014-05-29 10:40:11,215 Gossiper.java (line 
 869) InetAddress /10.225.45.150 is now UP
 This problem isn't hit if cassandra is restarted on node A while node B is 
 stopped.  The problem goes away if node B is restarted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7318) Unable to truncate column family on node which has been decommissioned and re-bootstrapped


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

Brandon Williams updated CASSANDRA-7318:


 Reviewer: Tyler Hobbs
  Component/s: Core
Fix Version/s: 2.0.9

 Unable to truncate column family on node which has been decommissioned and 
 re-bootstrapped
 --

 Key: CASSANDRA-7318
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7318
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Seen running cassandra 2.0.7 running on Red Hat Linux
Reporter: Thomas Whiteway
Assignee: Brandon Williams
Priority: Minor
 Fix For: 2.0.9

 Attachments: 7318.txt


 After decommissioning a node, then re-bootstrapping it, it's not possible to 
 truncate column families until cassandra is restarted.
 Steps to reproduce:
 - Start with a two node deployment (nodes A and B)
 - Run nodetool decommission on node B
 - Stop cassandra on node B
 - Delete the contents of the cassandra data and commitlog directories
 - Start cassandra on node B with node A as the seed
 - Run cqlsh on node B and try to truncate a column family
 - cqlsh displays: Unable to complete request: one or more nodes were 
 unavailable.
 According to the logs node B seems to think that itself is down.  The follow 
 logs appear when the server is started and there are no further logs to 
 indicate the B is now UP (A=10.225.45.150, B=10.225.45.151):
  INFO [main] 2014-05-29 10:40:11,090 MessagingService.java (line 461) 
 Starting Messaging Service on port 7000
  INFO [HANDSHAKE-/10.225.45.150] 2014-05-29 10:40:11,106 
 OutboundTcpConnection.java (line 386) Handshaking version with /10.225.45.150
  INFO [GossipStage:1] 2014-05-29 10:40:11,182 Gossiper.java (line 903) Node 
 /10.225.45.150 is now part of the cluster
  INFO [GossipStage:1] 2014-05-29 10:40:11,185 Gossiper.java (line 883) 
 InetAddress /10.225.45.151 is now DOWN
  INFO [RequestResponseStage:1] 2014-05-29 10:40:11,215 Gossiper.java (line 
 869) InetAddress /10.225.45.150 is now UP
 This problem isn't hit if cassandra is restarted on node A while node B is 
 stopped.  The problem goes away if node B is restarted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7318) Unable to truncate column family on node which has been decommissioned and re-bootstrapped


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

Brandon Williams updated CASSANDRA-7318:


Attachment: 7318.txt

The problem here is that there is a dead state for our ip in gossip from the 
decommission.  Normally, this isn't a problem since our generation would be 
newer and knock that state out, except during bootstrap we do a shadow round to 
check for an existing endpoint, then fail to clean unreachable endpoints which 
is what truncate is checking.  I suspect there would be a similar problem with 
replace_address on the same ip.

Patch to also clear unreachableEndpoints and liveEndpoints so that the gossiper 
is more pristine when it really start.s

 Unable to truncate column family on node which has been decommissioned and 
 re-bootstrapped
 --

 Key: CASSANDRA-7318
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7318
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Seen running cassandra 2.0.7 running on Red Hat Linux
Reporter: Thomas Whiteway
Assignee: Brandon Williams
Priority: Minor
 Fix For: 2.0.9

 Attachments: 7318.txt


 After decommissioning a node, then re-bootstrapping it, it's not possible to 
 truncate column families until cassandra is restarted.
 Steps to reproduce:
 - Start with a two node deployment (nodes A and B)
 - Run nodetool decommission on node B
 - Stop cassandra on node B
 - Delete the contents of the cassandra data and commitlog directories
 - Start cassandra on node B with node A as the seed
 - Run cqlsh on node B and try to truncate a column family
 - cqlsh displays: Unable to complete request: one or more nodes were 
 unavailable.
 According to the logs node B seems to think that itself is down.  The follow 
 logs appear when the server is started and there are no further logs to 
 indicate the B is now UP (A=10.225.45.150, B=10.225.45.151):
  INFO [main] 2014-05-29 10:40:11,090 MessagingService.java (line 461) 
 Starting Messaging Service on port 7000
  INFO [HANDSHAKE-/10.225.45.150] 2014-05-29 10:40:11,106 
 OutboundTcpConnection.java (line 386) Handshaking version with /10.225.45.150
  INFO [GossipStage:1] 2014-05-29 10:40:11,182 Gossiper.java (line 903) Node 
 /10.225.45.150 is now part of the cluster
  INFO [GossipStage:1] 2014-05-29 10:40:11,185 Gossiper.java (line 883) 
 InetAddress /10.225.45.151 is now DOWN
  INFO [RequestResponseStage:1] 2014-05-29 10:40:11,215 Gossiper.java (line 
 869) InetAddress /10.225.45.150 is now UP
 This problem isn't hit if cassandra is restarted on node A while node B is 
 stopped.  The problem goes away if node B is restarted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

git commit: Don't insert tombstones that hide indexed values into 2i

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-1.2 593bba94f - febf3854b


Don't insert tombstones that hide indexed values into 2i

patch by Sam Tunnicliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-7268


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

Branch: refs/heads/cassandra-1.2
Commit: febf3854bfa507c092ad5d35e3fe2d536ca78ce1
Parents: 593bba9
Author: Sam Tunnicliffe s...@beobal.com
Authored: Tue Jun 17 16:25:29 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 16:26:43 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 26 -
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 82 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 28b5f29..18929d5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,8 @@
 1.2.17
+ * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
  * Track metrics at a keyspace level (CASSANDRA-6539)
- * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+ * Add replace_address_first_boot flag to only replace if not bootstrapped
+   (CASSANDRA-7356)
  * Enable keepalive for native protocol (CASSANDRA-7380)
  * Check internal addresses for seeds (CASSANDRA-6523)
  * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --git a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java 
b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index c4e4129..7fefa13 100644
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@ -29,7 +29,6 @@ import org.apache.cassandra.config.ColumnDefinition;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.db.compaction.CompactionManager;
 import org.apache.cassandra.db.filter.IDiskAtomFilter;
-import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.dht.AbstractBounds;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.io.sstable.ReducingKeyIterator;
@@ -650,7 +649,14 @@ public class SecondaryIndexManager
 // where the row is invisible to both queries (the opposite 
seems preferable); see CASSANDRA-5540
 if (!column.isMarkedForDelete())
 ((PerColumnSecondaryIndex) index).insert(key.key, column);
-((PerColumnSecondaryIndex) index).delete(key.key, oldColumn);
+
+// Usually we want to delete the old value from the index, 
except when
+// name/value/timestamp are all equal, but the columns 
themselves
+// are not (as is the case when overwriting expiring columns 
with
+// identical values and ttl) Then, we don't want to delete as 
the
+// tombstone will hide the new value we just inserted; see 
CASSANDRA-7268
+if (shouldCleanupOldValue(oldColumn, column))
+((PerColumnSecondaryIndex) index).delete(key.key, 
oldColumn);
 }
 }
 
@@ -672,5 +678,21 @@ public class SecondaryIndexManager
 for (SecondaryIndex index : rowLevelIndexMap.values())
 ((PerRowSecondaryIndex) index).index(key.key, cf);
 }
+
+private boolean shouldCleanupOldValue(IColumn oldColumn, IColumn 
newColumn)
+{
+// If any one of name/value/timestamp are different, then we
+// should delete from the index. If not, then we can infer that
+// at least one of the columns is an ExpiringColumn and that the
+// difference is in the expiry time. In this case, we don't want to
+// delete the old value from the index as the tombstone we insert
+// will just hide the inserted value.
+// Completely identical columns (including expiring columns with
+// identical ttl  localExpirationTime) will not get this far due
+// to the oldColumn.equals(newColumn) in StandardUpdater.update
+return !oldColumn.name().equals(newColumn.name())
+||

[jira] [Created] (CASSANDRA-7413) Native Protocol V3 CREATE Response

2014-06-17 Thread Robert Stupp (JIRA)

Robert Stupp created CASSANDRA-7413:
---

 Summary: Native Protocol V3 CREATE Response
 Key: CASSANDRA-7413
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7413
 Project: Cassandra
  Issue Type: Task
Reporter: Robert Stupp


Native protocol v3 changes the EVENT (opcode 12) SCHEMA_CHANGE to include the 
target type that changed : changetargetkeyspacename.

The RESULT (opcode 8) SCHEMA_CHANGE has the old layout 
(changekeyspacetable.

Is this difference intentional or does the protocol spec needs change for 
RESULT/SCHEMA_CHANGE?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java


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

Branch: refs/heads/cassandra-2.0
Commit: 7801aab8c0945005735d81f64e248c85d057a4ec
Parents: cee1f67 febf385
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:15:31 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:15:31 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 25 -
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 82 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7801aab8/CHANGES.txt
--
diff --cc CHANGES.txt
index e3bd64b,18929d5..6a50186
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,23 -1,8 +1,25 @@@
 -1.2.17
 +2.0.9
 + * Fix native protocol CAS batches (CASSANDRA-7337)
 + * Add per-CF range read request latency metrics (CASSANDRA-7338)
 + * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)
 + * Add conditional CREATE/DROP USER support (CASSANDRA-7264)
 + * Swap local and global default read repair chances (CASSANDRA-7320)
 + * Add missing iso8601 patterns for date strings (CASSANDRA-6973)
 + * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 + * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 + * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
 + * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 + * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 + * Add authentication support to shuffle (CASSANDRA-6484)
 + * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
 + * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
 + * Fix infinite loop on exception while streaming (CASSANDRA-7330)
 + * Reference sstables before populating key cache (CASSANDRA-7234)
 +Merged from 1.2:
+  * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
   * Track metrics at a keyspace level (CASSANDRA-6539)
-  * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+  * Add replace_address_first_boot flag to only replace if not bootstrapped
+(CASSANDRA-7356)
   * Enable keepalive for native protocol (CASSANDRA-7380)
   * Check internal addresses for seeds (CASSANDRA-6523)
   * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7801aab8/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --cc src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index 9600099,7fefa13..2c0d611
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@@ -623,17 -638,25 +623,24 @@@ public class SecondaryIndexManage
  {
  if (oldColumn.equals(column))
  return;
 -
 -SecondaryIndex index = indexFor(column.name());
 -if (index == null)
 -return;
 -
 -if (index instanceof PerColumnSecondaryIndex)
 +
 +for (SecondaryIndex index : indexFor(column.name()))
  {
 -// insert the new value before removing the old one, so we 
never have a period
 -// where the row is invisible to both queries (the opposite 
seems preferable); see CASSANDRA-5540
 -if (!column.isMarkedForDelete())
 -((PerColumnSecondaryIndex) index).insert(key.key, column);
 -
 -// Usually we want to delete the old value from the index, 
except when
 -// name/value/timestamp are all equal, but the columns 
themselves
 -// are not (as is the case when overwriting expiring columns 
with
 -// identical values and ttl) Then, we don't want to delete as 
the
 -// tombstone will hide the new value we just inserted; see 
CASSANDRA-7268
 -if (shouldCleanupOldValue(oldColumn, column))
 -((PerColumnSecondaryIndex) index).delete(key.key, 
oldColumn);
 +if (index instanceof PerColumnSecondaryIndex)
 +{
 +// insert the new

[1/2] git commit: Don't insert tombstones that hide indexed values into 2i

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.0 cee1f674a - 7801aab8c


Don't insert tombstones that hide indexed values into 2i

patch by Sam Tunnicliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-7268


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

Branch: refs/heads/cassandra-2.0
Commit: febf3854bfa507c092ad5d35e3fe2d536ca78ce1
Parents: 593bba9
Author: Sam Tunnicliffe s...@beobal.com
Authored: Tue Jun 17 16:25:29 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 16:26:43 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 26 -
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 82 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 28b5f29..18929d5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,8 @@
 1.2.17
+ * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
  * Track metrics at a keyspace level (CASSANDRA-6539)
- * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+ * Add replace_address_first_boot flag to only replace if not bootstrapped
+   (CASSANDRA-7356)
  * Enable keepalive for native protocol (CASSANDRA-7380)
  * Check internal addresses for seeds (CASSANDRA-6523)
  * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --git a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java 
b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index c4e4129..7fefa13 100644
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@ -29,7 +29,6 @@ import org.apache.cassandra.config.ColumnDefinition;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.db.compaction.CompactionManager;
 import org.apache.cassandra.db.filter.IDiskAtomFilter;
-import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.dht.AbstractBounds;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.io.sstable.ReducingKeyIterator;
@@ -650,7 +649,14 @@ public class SecondaryIndexManager
 // where the row is invisible to both queries (the opposite 
seems preferable); see CASSANDRA-5540
 if (!column.isMarkedForDelete())
 ((PerColumnSecondaryIndex) index).insert(key.key, column);
-((PerColumnSecondaryIndex) index).delete(key.key, oldColumn);
+
+// Usually we want to delete the old value from the index, 
except when
+// name/value/timestamp are all equal, but the columns 
themselves
+// are not (as is the case when overwriting expiring columns 
with
+// identical values and ttl) Then, we don't want to delete as 
the
+// tombstone will hide the new value we just inserted; see 
CASSANDRA-7268
+if (shouldCleanupOldValue(oldColumn, column))
+((PerColumnSecondaryIndex) index).delete(key.key, 
oldColumn);
 }
 }
 
@@ -672,5 +678,21 @@ public class SecondaryIndexManager
 for (SecondaryIndex index : rowLevelIndexMap.values())
 ((PerRowSecondaryIndex) index).index(key.key, cf);
 }
+
+private boolean shouldCleanupOldValue(IColumn oldColumn, IColumn 
newColumn)
+{
+// If any one of name/value/timestamp are different, then we
+// should delete from the index. If not, then we can infer that
+// at least one of the columns is an ExpiringColumn and that the
+// difference is in the expiry time. In this case, we don't want to
+// delete the old value from the index as the tombstone we insert
+// will just hide the inserted value.
+// Completely identical columns (including expiring columns with
+// identical ttl  localExpirationTime) will not get this far due
+// to the oldColumn.equals(newColumn) in StandardUpdater.update
+return !oldColumn.name().equals(newColumn.name())
+||

[1/3] git commit: Don't insert tombstones that hide indexed values into 2i

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 a3dc7b8b4 - 5e90091d1


Don't insert tombstones that hide indexed values into 2i

patch by Sam Tunnicliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-7268


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

Branch: refs/heads/cassandra-2.1
Commit: febf3854bfa507c092ad5d35e3fe2d536ca78ce1
Parents: 593bba9
Author: Sam Tunnicliffe s...@beobal.com
Authored: Tue Jun 17 16:25:29 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 16:26:43 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 26 -
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 82 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 28b5f29..18929d5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,8 @@
 1.2.17
+ * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
  * Track metrics at a keyspace level (CASSANDRA-6539)
- * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+ * Add replace_address_first_boot flag to only replace if not bootstrapped
+   (CASSANDRA-7356)
  * Enable keepalive for native protocol (CASSANDRA-7380)
  * Check internal addresses for seeds (CASSANDRA-6523)
  * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --git a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java 
b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index c4e4129..7fefa13 100644
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@ -29,7 +29,6 @@ import org.apache.cassandra.config.ColumnDefinition;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.db.compaction.CompactionManager;
 import org.apache.cassandra.db.filter.IDiskAtomFilter;
-import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.dht.AbstractBounds;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.io.sstable.ReducingKeyIterator;
@@ -650,7 +649,14 @@ public class SecondaryIndexManager
 // where the row is invisible to both queries (the opposite 
seems preferable); see CASSANDRA-5540
 if (!column.isMarkedForDelete())
 ((PerColumnSecondaryIndex) index).insert(key.key, column);
-((PerColumnSecondaryIndex) index).delete(key.key, oldColumn);
+
+// Usually we want to delete the old value from the index, 
except when
+// name/value/timestamp are all equal, but the columns 
themselves
+// are not (as is the case when overwriting expiring columns 
with
+// identical values and ttl) Then, we don't want to delete as 
the
+// tombstone will hide the new value we just inserted; see 
CASSANDRA-7268
+if (shouldCleanupOldValue(oldColumn, column))
+((PerColumnSecondaryIndex) index).delete(key.key, 
oldColumn);
 }
 }
 
@@ -672,5 +678,21 @@ public class SecondaryIndexManager
 for (SecondaryIndex index : rowLevelIndexMap.values())
 ((PerRowSecondaryIndex) index).index(key.key, cf);
 }
+
+private boolean shouldCleanupOldValue(IColumn oldColumn, IColumn 
newColumn)
+{
+// If any one of name/value/timestamp are different, then we
+// should delete from the index. If not, then we can infer that
+// at least one of the columns is an ExpiringColumn and that the
+// difference is in the expiry time. In this case, we don't want to
+// delete the old value from the index as the tombstone we insert
+// will just hide the inserted value.
+// Completely identical columns (including expiring columns with
+// identical ttl  localExpirationTime) will not get this far due
+// to the oldColumn.equals(newColumn) in StandardUpdater.update
+return !oldColumn.name().equals(newColumn.name())
+||

[3/3] 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/db/index/SecondaryIndexManager.java


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

Branch: refs/heads/cassandra-2.1
Commit: 5e90091d1ef940bcba65a87bf14fc1e809503627
Parents: a3dc7b8 7801aab
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:42:32 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:42:32 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 28 +-
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 85 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e90091d/CHANGES.txt
--
diff --cc CHANGES.txt
index fd7c62b,6a50186..4c9e69d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,26 -1,25 +1,28 @@@
 -2.0.9
 +2.1.0
 + * Avoid incremental compaction on Windows (CASSANDRA-7365)
 + * Fix exception when querying a composite-keyed table with a collection index
 +   (CASSANDRA-7372)
 + * Use node's host id in place of counter ids (CASSANDRA-7366)
   * Fix native protocol CAS batches (CASSANDRA-7337)
 + * Reduce likelihood of contention on local paxos locking (CASSANDRA-7359)
 + * Upgrade to Pig 0.12.1 (CASSANDRA-6556)
 + * Make sure we clear out repair sessions from netstats (CASSANDRA-7329)
 + * Don't fail streams on failure detector downs (CASSANDRA-3569)
 + * Add optional keyspace to DROP INDEX statement (CASSANDRA-7314)
 + * Reduce run time for CQL tests (CASSANDRA-7327)
 + * Fix heap size calculation on Windows (CASSANDRA-7352)
 + * RefCount native frames from netty (CASSANDRA-7245)
 + * Use tarball dir instead of /var for default paths (CASSANDRA-7136)
 +Merged from 2.0:
   * Add per-CF range read request latency metrics (CASSANDRA-7338)
   * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)
 - * Add conditional CREATE/DROP USER support (CASSANDRA-7264)
 - * Swap local and global default read repair chances (CASSANDRA-7320)
 - * Add missing iso8601 patterns for date strings (CASSANDRA-6973)
 - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
 - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 - * Add authentication support to shuffle (CASSANDRA-6484)
 - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
   * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
   * Fix infinite loop on exception while streaming (CASSANDRA-7330)
 - * Reference sstables before populating key cache (CASSANDRA-7234)
  Merged from 1.2:
+  * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
   * Track metrics at a keyspace level (CASSANDRA-6539)
-  * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+  * Add replace_address_first_boot flag to only replace if not bootstrapped
+(CASSANDRA-7356)
   * Enable keepalive for native protocol (CASSANDRA-7380)
   * Check internal addresses for seeds (CASSANDRA-6523)
   * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e90091d/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --cc src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index 36c7e1e,2c0d611..f78dc86
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@@ -710,10 -628,18 +710,20 @@@ public class SecondaryIndexManage
  {
  if (index instanceof PerColumnSecondaryIndex)
  {
 -// insert the new value before removing the old one, so 
we never have a period
 -// where the row is invisible to both queries (the 
opposite seems preferable); see CASSANDRA-5540
 -if (!column.isMarkedForDelete(System.currentTimeMillis()))
 -((PerColumnSecondaryIndex) index).insert(key.key, 
column);
 -
 -// Usually we want to delete the old value from the 
index, except when
 -// name/value/timestamp

[4/4] 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/704469d9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/704469d9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/704469d9

Branch: refs/heads/trunk
Commit: 704469d95f3e2842eb174d887330eea682774e4e
Parents: 805a4ae 5e90091
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:42:59 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:42:59 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 28 +-
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 85 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/704469d9/CHANGES.txt
--

[2/4] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java


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

Branch: refs/heads/trunk
Commit: 7801aab8c0945005735d81f64e248c85d057a4ec
Parents: cee1f67 febf385
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:15:31 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:15:31 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 25 -
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 82 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7801aab8/CHANGES.txt
--
diff --cc CHANGES.txt
index e3bd64b,18929d5..6a50186
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,23 -1,8 +1,25 @@@
 -1.2.17
 +2.0.9
 + * Fix native protocol CAS batches (CASSANDRA-7337)
 + * Add per-CF range read request latency metrics (CASSANDRA-7338)
 + * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)
 + * Add conditional CREATE/DROP USER support (CASSANDRA-7264)
 + * Swap local and global default read repair chances (CASSANDRA-7320)
 + * Add missing iso8601 patterns for date strings (CASSANDRA-6973)
 + * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 + * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 + * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
 + * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 + * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 + * Add authentication support to shuffle (CASSANDRA-6484)
 + * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
 + * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
 + * Fix infinite loop on exception while streaming (CASSANDRA-7330)
 + * Reference sstables before populating key cache (CASSANDRA-7234)
 +Merged from 1.2:
+  * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
   * Track metrics at a keyspace level (CASSANDRA-6539)
-  * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+  * Add replace_address_first_boot flag to only replace if not bootstrapped
+(CASSANDRA-7356)
   * Enable keepalive for native protocol (CASSANDRA-7380)
   * Check internal addresses for seeds (CASSANDRA-6523)
   * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7801aab8/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --cc src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index 9600099,7fefa13..2c0d611
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@@ -623,17 -638,25 +623,24 @@@ public class SecondaryIndexManage
  {
  if (oldColumn.equals(column))
  return;
 -
 -SecondaryIndex index = indexFor(column.name());
 -if (index == null)
 -return;
 -
 -if (index instanceof PerColumnSecondaryIndex)
 +
 +for (SecondaryIndex index : indexFor(column.name()))
  {
 -// insert the new value before removing the old one, so we 
never have a period
 -// where the row is invisible to both queries (the opposite 
seems preferable); see CASSANDRA-5540
 -if (!column.isMarkedForDelete())
 -((PerColumnSecondaryIndex) index).insert(key.key, column);
 -
 -// Usually we want to delete the old value from the index, 
except when
 -// name/value/timestamp are all equal, but the columns 
themselves
 -// are not (as is the case when overwriting expiring columns 
with
 -// identical values and ttl) Then, we don't want to delete as 
the
 -// tombstone will hide the new value we just inserted; see 
CASSANDRA-7268
 -if (shouldCleanupOldValue(oldColumn, column))
 -((PerColumnSecondaryIndex) index).delete(key.key, 
oldColumn);
 +if (index instanceof PerColumnSecondaryIndex)
 +{
 +// insert the new value before

[1/4] git commit: Don't insert tombstones that hide indexed values into 2i

Repository: cassandra
Updated Branches:
  refs/heads/trunk 805a4aeeb - 704469d95


Don't insert tombstones that hide indexed values into 2i

patch by Sam Tunnicliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-7268


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

Branch: refs/heads/trunk
Commit: febf3854bfa507c092ad5d35e3fe2d536ca78ce1
Parents: 593bba9
Author: Sam Tunnicliffe s...@beobal.com
Authored: Tue Jun 17 16:25:29 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 16:26:43 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 26 -
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 82 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 28b5f29..18929d5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,8 @@
 1.2.17
+ * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
  * Track metrics at a keyspace level (CASSANDRA-6539)
- * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+ * Add replace_address_first_boot flag to only replace if not bootstrapped
+   (CASSANDRA-7356)
  * Enable keepalive for native protocol (CASSANDRA-7380)
  * Check internal addresses for seeds (CASSANDRA-6523)
  * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/febf3854/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --git a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java 
b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index c4e4129..7fefa13 100644
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@ -29,7 +29,6 @@ import org.apache.cassandra.config.ColumnDefinition;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.db.compaction.CompactionManager;
 import org.apache.cassandra.db.filter.IDiskAtomFilter;
-import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.dht.AbstractBounds;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.io.sstable.ReducingKeyIterator;
@@ -650,7 +649,14 @@ public class SecondaryIndexManager
 // where the row is invisible to both queries (the opposite 
seems preferable); see CASSANDRA-5540
 if (!column.isMarkedForDelete())
 ((PerColumnSecondaryIndex) index).insert(key.key, column);
-((PerColumnSecondaryIndex) index).delete(key.key, oldColumn);
+
+// Usually we want to delete the old value from the index, 
except when
+// name/value/timestamp are all equal, but the columns 
themselves
+// are not (as is the case when overwriting expiring columns 
with
+// identical values and ttl) Then, we don't want to delete as 
the
+// tombstone will hide the new value we just inserted; see 
CASSANDRA-7268
+if (shouldCleanupOldValue(oldColumn, column))
+((PerColumnSecondaryIndex) index).delete(key.key, 
oldColumn);
 }
 }
 
@@ -672,5 +678,21 @@ public class SecondaryIndexManager
 for (SecondaryIndex index : rowLevelIndexMap.values())
 ((PerRowSecondaryIndex) index).index(key.key, cf);
 }
+
+private boolean shouldCleanupOldValue(IColumn oldColumn, IColumn 
newColumn)
+{
+// If any one of name/value/timestamp are different, then we
+// should delete from the index. If not, then we can infer that
+// at least one of the columns is an ExpiringColumn and that the
+// difference is in the expiry time. In this case, we don't want to
+// delete the old value from the index as the tombstone we insert
+// will just hide the inserted value.
+// Completely identical columns (including expiring columns with
+// identical ttl  localExpirationTime) will not get this far due
+// to the oldColumn.equals(newColumn) in StandardUpdater.update
+return !oldColumn.name().equals(newColumn.name())
+||

[3/4] 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/db/index/SecondaryIndexManager.java


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

Branch: refs/heads/trunk
Commit: 5e90091d1ef940bcba65a87bf14fc1e809503627
Parents: a3dc7b8 7801aab
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:42:32 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:42:32 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 28 +-
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 85 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e90091d/CHANGES.txt
--
diff --cc CHANGES.txt
index fd7c62b,6a50186..4c9e69d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,26 -1,25 +1,28 @@@
 -2.0.9
 +2.1.0
 + * Avoid incremental compaction on Windows (CASSANDRA-7365)
 + * Fix exception when querying a composite-keyed table with a collection index
 +   (CASSANDRA-7372)
 + * Use node's host id in place of counter ids (CASSANDRA-7366)
   * Fix native protocol CAS batches (CASSANDRA-7337)
 + * Reduce likelihood of contention on local paxos locking (CASSANDRA-7359)
 + * Upgrade to Pig 0.12.1 (CASSANDRA-6556)
 + * Make sure we clear out repair sessions from netstats (CASSANDRA-7329)
 + * Don't fail streams on failure detector downs (CASSANDRA-3569)
 + * Add optional keyspace to DROP INDEX statement (CASSANDRA-7314)
 + * Reduce run time for CQL tests (CASSANDRA-7327)
 + * Fix heap size calculation on Windows (CASSANDRA-7352)
 + * RefCount native frames from netty (CASSANDRA-7245)
 + * Use tarball dir instead of /var for default paths (CASSANDRA-7136)
 +Merged from 2.0:
   * Add per-CF range read request latency metrics (CASSANDRA-7338)
   * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)
 - * Add conditional CREATE/DROP USER support (CASSANDRA-7264)
 - * Swap local and global default read repair chances (CASSANDRA-7320)
 - * Add missing iso8601 patterns for date strings (CASSANDRA-6973)
 - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
 - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 - * Add authentication support to shuffle (CASSANDRA-6484)
 - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
   * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
   * Fix infinite loop on exception while streaming (CASSANDRA-7330)
 - * Reference sstables before populating key cache (CASSANDRA-7234)
  Merged from 1.2:
+  * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
   * Track metrics at a keyspace level (CASSANDRA-6539)
-  * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+  * Add replace_address_first_boot flag to only replace if not bootstrapped
+(CASSANDRA-7356)
   * Enable keepalive for native protocol (CASSANDRA-7380)
   * Check internal addresses for seeds (CASSANDRA-6523)
   * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e90091d/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --cc src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index 36c7e1e,2c0d611..f78dc86
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@@ -710,10 -628,18 +710,20 @@@ public class SecondaryIndexManage
  {
  if (index instanceof PerColumnSecondaryIndex)
  {
 -// insert the new value before removing the old one, so 
we never have a period
 -// where the row is invisible to both queries (the 
opposite seems preferable); see CASSANDRA-5540
 -if (!column.isMarkedForDelete(System.currentTimeMillis()))
 -((PerColumnSecondaryIndex) index).insert(key.key, 
column);
 -
 -// Usually we want to delete the old value from the 
index, except when
 -// name/value/timestamp are all

[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java


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

Branch: refs/heads/cassandra-2.1
Commit: 7801aab8c0945005735d81f64e248c85d057a4ec
Parents: cee1f67 febf385
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:15:31 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:15:31 2014 -0700

--
 CHANGES.txt |  4 +-
 .../db/index/SecondaryIndexManager.java | 25 -
 .../cassandra/db/ColumnFamilyStoreTest.java | 55 
 3 files changed, 82 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7801aab8/CHANGES.txt
--
diff --cc CHANGES.txt
index e3bd64b,18929d5..6a50186
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,23 -1,8 +1,25 @@@
 -1.2.17
 +2.0.9
 + * Fix native protocol CAS batches (CASSANDRA-7337)
 + * Add per-CF range read request latency metrics (CASSANDRA-7338)
 + * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)
 + * Add conditional CREATE/DROP USER support (CASSANDRA-7264)
 + * Swap local and global default read repair chances (CASSANDRA-7320)
 + * Add missing iso8601 patterns for date strings (CASSANDRA-6973)
 + * Support selecting multiple rows in a partition using IN (CASSANDRA-6875)
 + * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274)
 + * Copy compaction options to make sure they are reloaded (CASSANDRA-7290)
 + * Add option to do more aggressive tombstone compactions (CASSANDRA-6563)
 + * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
 + * Add authentication support to shuffle (CASSANDRA-6484)
 + * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
 + * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
 + * Fix infinite loop on exception while streaming (CASSANDRA-7330)
 + * Reference sstables before populating key cache (CASSANDRA-7234)
 +Merged from 1.2:
+  * Don't insert tombstones that hide indexed values into 2i (CASSANDRA-7268)
   * Track metrics at a keyspace level (CASSANDRA-6539)
-  * Add replace_address_first_boot flag to only replace if not bootstrapped 
(CASSANDRA-7356)
+  * Add replace_address_first_boot flag to only replace if not bootstrapped
+(CASSANDRA-7356)
   * Enable keepalive for native protocol (CASSANDRA-7380)
   * Check internal addresses for seeds (CASSANDRA-6523)
   * Fix potential / by 0 in HHOM page size calculation (CASSANDRA-7354)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7801aab8/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
--
diff --cc src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
index 9600099,7fefa13..2c0d611
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java
@@@ -623,17 -638,25 +623,24 @@@ public class SecondaryIndexManage
  {
  if (oldColumn.equals(column))
  return;
 -
 -SecondaryIndex index = indexFor(column.name());
 -if (index == null)
 -return;
 -
 -if (index instanceof PerColumnSecondaryIndex)
 +
 +for (SecondaryIndex index : indexFor(column.name()))
  {
 -// insert the new value before removing the old one, so we 
never have a period
 -// where the row is invisible to both queries (the opposite 
seems preferable); see CASSANDRA-5540
 -if (!column.isMarkedForDelete())
 -((PerColumnSecondaryIndex) index).insert(key.key, column);
 -
 -// Usually we want to delete the old value from the index, 
except when
 -// name/value/timestamp are all equal, but the columns 
themselves
 -// are not (as is the case when overwriting expiring columns 
with
 -// identical values and ttl) Then, we don't want to delete as 
the
 -// tombstone will hide the new value we just inserted; see 
CASSANDRA-7268
 -if (shouldCleanupOldValue(oldColumn, column))
 -((PerColumnSecondaryIndex) index).delete(key.key, 
oldColumn);
 +if (index instanceof PerColumnSecondaryIndex)
 +{
 +// insert the new

git commit: Handle empty CFs in Memtable#maybeUpdateLiveRatio()

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.0 7801aab8c - 9afc2097e


Handle empty CFs in Memtable#maybeUpdateLiveRatio()

patch by Christian Spriegel; reviewed by Aleksey Yeschenko for
CASSANDRA-7401


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

Branch: refs/heads/cassandra-2.0
Commit: 9afc2097ef8e806b9916e623815202b0f43d1cfc
Parents: 7801aab
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:59:26 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:59:26 2014 -0700

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/Memtable.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afc2097/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6a50186..8af4b3e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.9
+ * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401)
  * Fix native protocol CAS batches (CASSANDRA-7337)
  * Add per-CF range read request latency metrics (CASSANDRA-7338)
  * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afc2097/src/java/org/apache/cassandra/db/Memtable.java
--
diff --git a/src/java/org/apache/cassandra/db/Memtable.java 
b/src/java/org/apache/cassandra/db/Memtable.java
index ea79e9c..bcef0ec 100644
--- a/src/java/org/apache/cassandra/db/Memtable.java
+++ b/src/java/org/apache/cassandra/db/Memtable.java
@@ -180,7 +180,7 @@ public class Memtable
 {
 long last = liveRatioComputedAt.get();
 long operations = currentOperations.get();
-if (operations  2 * last)
+if (operations = 2L * last)
 break;
 if (liveRatioComputedAt.compareAndSet(last, operations))
 {

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

Merge branch 'cassandra-2.0' into cassandra-2.1

Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/db/Memtable.java


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

Branch: refs/heads/cassandra-2.1
Commit: d38f677c007a46f6fa914e7a3535bb12feb6ec94
Parents: 5e90091 9afc209
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 18:01:23 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 18:01:23 2014 -0700

--

--

[1/3] git commit: Handle empty CFs in Memtable#maybeUpdateLiveRatio()

Repository: cassandra
Updated Branches:
  refs/heads/trunk 704469d95 - 75b9ea41e


Handle empty CFs in Memtable#maybeUpdateLiveRatio()

patch by Christian Spriegel; reviewed by Aleksey Yeschenko for
CASSANDRA-7401


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

Branch: refs/heads/trunk
Commit: 9afc2097ef8e806b9916e623815202b0f43d1cfc
Parents: 7801aab
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:59:26 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:59:26 2014 -0700

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/Memtable.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afc2097/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6a50186..8af4b3e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.9
+ * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401)
  * Fix native protocol CAS batches (CASSANDRA-7337)
  * Add per-CF range read request latency metrics (CASSANDRA-7338)
  * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afc2097/src/java/org/apache/cassandra/db/Memtable.java
--
diff --git a/src/java/org/apache/cassandra/db/Memtable.java 
b/src/java/org/apache/cassandra/db/Memtable.java
index ea79e9c..bcef0ec 100644
--- a/src/java/org/apache/cassandra/db/Memtable.java
+++ b/src/java/org/apache/cassandra/db/Memtable.java
@@ -180,7 +180,7 @@ public class Memtable
 {
 long last = liveRatioComputedAt.get();
 long operations = currentOperations.get();
-if (operations  2 * last)
+if (operations = 2L * last)
 break;
 if (liveRatioComputedAt.compareAndSet(last, operations))
 {

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

Merge branch 'cassandra-2.0' into cassandra-2.1

Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/db/Memtable.java


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

Branch: refs/heads/trunk
Commit: d38f677c007a46f6fa914e7a3535bb12feb6ec94
Parents: 5e90091 9afc209
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 18:01:23 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 18:01:23 2014 -0700

--

--

[3/3] 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/75b9ea41
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/75b9ea41
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/75b9ea41

Branch: refs/heads/trunk
Commit: 75b9ea41eddffe874e10a9a3160c4c4694857089
Parents: 704469d d38f677
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 18:01:49 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 18:01:49 2014 -0700

--

--

[1/2] git commit: Handle empty CFs in Memtable#maybeUpdateLiveRatio()

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 5e90091d1 - d38f677c0


Handle empty CFs in Memtable#maybeUpdateLiveRatio()

patch by Christian Spriegel; reviewed by Aleksey Yeschenko for
CASSANDRA-7401


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

Branch: refs/heads/cassandra-2.1
Commit: 9afc2097ef8e806b9916e623815202b0f43d1cfc
Parents: 7801aab
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Jun 17 17:59:26 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Jun 17 17:59:26 2014 -0700

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/Memtable.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afc2097/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6a50186..8af4b3e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.9
+ * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401)
  * Fix native protocol CAS batches (CASSANDRA-7337)
  * Add per-CF range read request latency metrics (CASSANDRA-7338)
  * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9afc2097/src/java/org/apache/cassandra/db/Memtable.java
--
diff --git a/src/java/org/apache/cassandra/db/Memtable.java 
b/src/java/org/apache/cassandra/db/Memtable.java
index ea79e9c..bcef0ec 100644
--- a/src/java/org/apache/cassandra/db/Memtable.java
+++ b/src/java/org/apache/cassandra/db/Memtable.java
@@ -180,7 +180,7 @@ public class Memtable
 {
 long last = liveRatioComputedAt.get();
 long operations = currentOperations.get();
-if (operations  2 * last)
+if (operations = 2L * last)
 break;
 if (liveRatioComputedAt.compareAndSet(last, operations))
 {

[jira] [Updated] (CASSANDRA-7401) Memtable.maybeUpdateLiveRatio goes into an endless loop when currentOperations is zero


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

Aleksey Yeschenko updated CASSANDRA-7401:
-

Reviewer: Aleksey Yeschenko  (was: Jonathan Ellis)

 Memtable.maybeUpdateLiveRatio goes into an endless loop when 
 currentOperations is zero
 --

 Key: CASSANDRA-7401
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7401
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Christian Spriegel
Assignee: Christian Spriegel
 Fix For: 2.0.9

 Attachments: MemtableFixV1.patch


 Hi,
 I was describing an error the other day on the mailing list, where the 
 MemoryMeter would go into an endless loop. This happened multiple times last 
 week, unfortunetaly I cannot reproduce it at the moment.
 The whole cassandra server got unresponsive and logged about 7000k messages 
 per second into the log:
 {quote}
 ...
  INFO [MemoryMeter:1] 2014-06-14 19:24:09,488 Memtable.java (line 481) 
 CFS(Keyspace='MDS', ColumnFamily='ResponsePortal') liveRatio is 64.0 
 (just-counted was 64.0).  calculation took 0ms for 0 cells
 ...
 {quote}
 The cause for this seems to be Memtable.maybeUpdateLiveRatio(), which cannot 
 handle currentOperations (and liveRatioComputedAt) to be zero. The loop will 
 iterate endlessly:
 {code}
 ...
 if (operations  2 * last) // does never break when zero: 0  0 
 is not true
 break;
 ...
 {code}
 One thing I cannot explain: How can the operationcount be zero when 
 maybeUpdateLiveRatio() gets called?
 is it possible that addAndGet in resolve() increases by 0  in some cases?
 {code}
 currentOperations.addAndGet(cf.getColumnCount() + (cf.isMarkedForDelete() ? 1 
 : 0) + cf.deletionInfo().rangeCount()); // can this be zero? 
 {code}
 Nevertheless, the attached patch fixes the endless loop. Feel free to 
 reassign this ticket or create a followup ticket if currentOperations should 
 not be zero.
 kind regards,
 Christian



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7401) Memtable.maybeUpdateLiveRatio goes into an endless loop when currentOperations is zero


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034693#comment-14034693
 ] 

Aleksey Yeschenko commented on CASSANDRA-7401:
--

Committed in 9afc2097ef8e806b9916e623815202b0f43d1cfc 
(https://github.com/apache/cassandra/commit/9afc2097ef8e806b9916e623815202b0f43d1cfc)
 (replaced  with =).

bq. Looks related to the start new memtable w/ the old memtable's liveRatio 
thing we were talking about.

It's not, at least directly it isn't.

bq. is it possible that addAndGet in resolve() increases by 0 in some cases?

Apparently yes, it is - when the CF has no cells in it, no range tombstones, 
and isn't top-level marked for deletion.
I have NO idea where that CF originated from, and don't even know where to 
start looking. If you find out - let us know.

 Memtable.maybeUpdateLiveRatio goes into an endless loop when 
 currentOperations is zero
 --

 Key: CASSANDRA-7401
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7401
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Christian Spriegel
Assignee: Aleksey Yeschenko
 Fix For: 2.0.9

 Attachments: MemtableFixV1.patch


 Hi,
 I was describing an error the other day on the mailing list, where the 
 MemoryMeter would go into an endless loop. This happened multiple times last 
 week, unfortunetaly I cannot reproduce it at the moment.
 The whole cassandra server got unresponsive and logged about 7000k messages 
 per second into the log:
 {quote}
 ...
  INFO [MemoryMeter:1] 2014-06-14 19:24:09,488 Memtable.java (line 481) 
 CFS(Keyspace='MDS', ColumnFamily='ResponsePortal') liveRatio is 64.0 
 (just-counted was 64.0).  calculation took 0ms for 0 cells
 ...
 {quote}
 The cause for this seems to be Memtable.maybeUpdateLiveRatio(), which cannot 
 handle currentOperations (and liveRatioComputedAt) to be zero. The loop will 
 iterate endlessly:
 {code}
 ...
 if (operations  2 * last) // does never break when zero: 0  0 
 is not true
 break;
 ...
 {code}
 One thing I cannot explain: How can the operationcount be zero when 
 maybeUpdateLiveRatio() gets called?
 is it possible that addAndGet in resolve() increases by 0  in some cases?
 {code}
 currentOperations.addAndGet(cf.getColumnCount() + (cf.isMarkedForDelete() ? 1 
 : 0) + cf.deletionInfo().rangeCount()); // can this be zero? 
 {code}
 Nevertheless, the attached patch fixes the endless loop. Feel free to 
 reassign this ticket or create a followup ticket if currentOperations should 
 not be zero.
 kind regards,
 Christian



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7401) Memtable.maybeUpdateLiveRatio goes into an endless loop when currentOperations is zero


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

Aleksey Yeschenko updated CASSANDRA-7401:
-

Assignee: Christian Spriegel  (was: Aleksey Yeschenko)

 Memtable.maybeUpdateLiveRatio goes into an endless loop when 
 currentOperations is zero
 --

 Key: CASSANDRA-7401
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7401
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Christian Spriegel
Assignee: Christian Spriegel
 Fix For: 2.0.9

 Attachments: MemtableFixV1.patch


 Hi,
 I was describing an error the other day on the mailing list, where the 
 MemoryMeter would go into an endless loop. This happened multiple times last 
 week, unfortunetaly I cannot reproduce it at the moment.
 The whole cassandra server got unresponsive and logged about 7000k messages 
 per second into the log:
 {quote}
 ...
  INFO [MemoryMeter:1] 2014-06-14 19:24:09,488 Memtable.java (line 481) 
 CFS(Keyspace='MDS', ColumnFamily='ResponsePortal') liveRatio is 64.0 
 (just-counted was 64.0).  calculation took 0ms for 0 cells
 ...
 {quote}
 The cause for this seems to be Memtable.maybeUpdateLiveRatio(), which cannot 
 handle currentOperations (and liveRatioComputedAt) to be zero. The loop will 
 iterate endlessly:
 {code}
 ...
 if (operations  2 * last) // does never break when zero: 0  0 
 is not true
 break;
 ...
 {code}
 One thing I cannot explain: How can the operationcount be zero when 
 maybeUpdateLiveRatio() gets called?
 is it possible that addAndGet in resolve() increases by 0  in some cases?
 {code}
 currentOperations.addAndGet(cf.getColumnCount() + (cf.isMarkedForDelete() ? 1 
 : 0) + cf.deletionInfo().rangeCount()); // can this be zero? 
 {code}
 Nevertheless, the attached patch fixes the endless loop. Feel free to 
 reassign this ticket or create a followup ticket if currentOperations should 
 not be zero.
 kind regards,
 Christian



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7273) expose global ColumnFamily metrics

2014-06-17 Thread Richard Wagner (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034707#comment-14034707
 ] 

Richard Wagner commented on CASSANDRA-7273:
---

Just to reiterate what Chris Lohfink said, we find it super useful in a managed 
cluster scenario to have aggregate CF metrics. In practice we find them quite 
useful and almost never have to dig into the CF specific metrics - which by the 
way is always an option as long as those are available too. I think that every 
CF metric is useful and should be presented in a global, aggregated view.

And to reiterate Brandon's comment, SP latency is a whole different beast from 
local latency, so having an aggregate view of latency at the local level is 
super important too.


 expose global ColumnFamily metrics
 --

 Key: CASSANDRA-7273
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7273
 Project: Cassandra
  Issue Type: New Feature
Reporter: Richard Wagner
Assignee: Brandon Williams
Priority: Minor
  Labels: lhf
 Fix For: 1.2.17

 Attachments: 7273-2_1_branch-v1.txt


 It would be very useful to have cassandra expose ColumnFamily metrics that 
 span all column families. A general purpose cassandra monitoring system built 
 up around the current ColumnFamily metrics really only has a couple of 
 choices right now: publish metrics for all column families or fetch metrics 
 for all column families, aggregate them and then publish the aggregated 
 metrics. The first can be quite expensive for the downstream monitoring 
 system and the second is a piece of work that it seems is better pushed into 
 cassandra itself.
 Perhaps these global ColumnFamily metrics could be published under a name of:
 org.apache.cassandra.metrics:type=(ColumnFamily|IndexColumnFamily),name=(Metric
  name)
 (Same as existing ColumnFamily metrics, but with no keyspace or scope.)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

buildbot failure in ASF Buildbot on cassandra-trunk

2014-06-17 Thread buildbot

The Buildbot has detected a new failure on builder cassandra-trunk while 
building cassandra.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/336

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch trunk] 704469d95f3e2842eb174d887330eea682774e4e
Blamelist: Aleksey Yeschenko alek...@apache.org,Sam Tunnicliffe 
s...@beobal.com

BUILD FAILED: failed shell

sincerely,
 -The Buildbot

[jira] [Updated] (CASSANDRA-7364) assert error in StorageProxy.submitHint


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

Aleksey Yeschenko updated CASSANDRA-7364:
-

Attachment: 7364.txt

 assert error in StorageProxy.submitHint
 ---

 Key: CASSANDRA-7364
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7364
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cassandra 2.1-rc1, os windows, 32 bit
Reporter: Radim Kolar
Assignee: Aleksey Yeschenko
Priority: Blocker
 Fix For: 2.0.9, 2.1 rc2

 Attachments: 7364.txt


 in 2.1-rc1. assert error and hector based client ends with all nodes down 
 message (its single node cluster). I assume that client connection got closed.
 INFO  18:28:33 Compacting 
 [SSTableReader(path='c:\cassandra-2.1\data\test\sipdb-
 58f51090ee6511e3815625991ef2b954\test-sipdb-ka-3-Data.db'), 
 SSTableReader(path='
 c:\cassandra-2.1\data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-
 1-Data.db'), 
 SSTableReader(path='c:\cassandra-2.1\data\test\sipdb-58f51090ee6511
 e3815625991ef2b954\test-sipdb-ka-4-Data.db'), 
 SSTableReader(path='c:\cassandra-2
 .1\data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-2-Data.db'),
  S
 STableReader(path='c:\cassandra-2.1\data\test\sipdb-58f51090ee6511e3815625991ef2
 b954\test-sipdb-ka-6-Data.db')]
 ERROR 18:29:50 Exception in thread Thread[Thrift:16,5,main]
 java.lang.AssertionError: localhost/127.0.0.1
 at 
 org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.jav
 a:870) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:49
 3) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageP
 roxy.java:537) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.
 java:1095) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.
 java:1077) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraSer
 ver.java:970) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResul
 t(Cassandra.java:3996) ~[apache-cassandra-thrift-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResul
 t(Cassandra.java:3980) ~[apache-cassandra-thrift-2.1.0-rc1.jar:2.1.0-rc1]
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) 
 ~[
 libthrift-0.9.1.jar:0.9.1]
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) 
 ~[li
 bthrift-0.9.1.jar:0.9.1]
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run
 (CustomTThreadPoolServer.java:201) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
 java:1145) ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
 .java:615) ~[na:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
 INFO  18:29:55 1 MUTATION messages dropped in last 5000ms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7364) assert error in StorageProxy.submitHint


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

Aleksey Yeschenko updated CASSANDRA-7364:
-

Priority: Minor  (was: Blocker)

The bug only affects WTE handling w/ CL.ANY.

 assert error in StorageProxy.submitHint
 ---

 Key: CASSANDRA-7364
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7364
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cassandra 2.1-rc1, os windows, 32 bit
Reporter: Radim Kolar
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 2.0.9, 2.1 rc2

 Attachments: 7364.txt


 in 2.1-rc1. assert error and hector based client ends with all nodes down 
 message (its single node cluster). I assume that client connection got closed.
 INFO  18:28:33 Compacting 
 [SSTableReader(path='c:\cassandra-2.1\data\test\sipdb-
 58f51090ee6511e3815625991ef2b954\test-sipdb-ka-3-Data.db'), 
 SSTableReader(path='
 c:\cassandra-2.1\data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-
 1-Data.db'), 
 SSTableReader(path='c:\cassandra-2.1\data\test\sipdb-58f51090ee6511
 e3815625991ef2b954\test-sipdb-ka-4-Data.db'), 
 SSTableReader(path='c:\cassandra-2
 .1\data\test\sipdb-58f51090ee6511e3815625991ef2b954\test-sipdb-ka-2-Data.db'),
  S
 STableReader(path='c:\cassandra-2.1\data\test\sipdb-58f51090ee6511e3815625991ef2
 b954\test-sipdb-ka-6-Data.db')]
 ERROR 18:29:50 Exception in thread Thread[Thrift:16,5,main]
 java.lang.AssertionError: localhost/127.0.0.1
 at 
 org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.jav
 a:870) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:49
 3) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageP
 roxy.java:537) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.
 java:1095) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.
 java:1077) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraSer
 ver.java:970) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResul
 t(Cassandra.java:3996) ~[apache-cassandra-thrift-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResul
 t(Cassandra.java:3980) ~[apache-cassandra-thrift-2.1.0-rc1.jar:2.1.0-rc1]
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) 
 ~[
 libthrift-0.9.1.jar:0.9.1]
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) 
 ~[li
 bthrift-0.9.1.jar:0.9.1]
 at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run
 (CustomTThreadPoolServer.java:201) ~[apache-cassandra-2.1.0-rc1.jar:2.1.0-rc1]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
 java:1145) ~[na:1.7.0_60]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
 .java:615) ~[na:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
 INFO  18:29:55 1 MUTATION messages dropped in last 5000ms



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7411) Node enables vnodes when bounced

[
https://issues.apache.org/jira/browse/CASSANDRA-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034721#comment-14034721
]

Philip Thompson commented on CASSANDRA-7411:

That seems inconsistent, but okay. In which case, I would like to suggest the
attached alteration to the cassandra yaml.

Node enables vnodes when bounced

Key: CASSANDRA-7411
URL: https://issues.apache.org/jira/browse/CASSANDRA-7411
Project: Cassandra
Issue Type: Bug
Environment: OSX 9
Reporter: Philip Thompson
Attachments: system.log

--
This message was sent by Atlassian JIRA
(v6.2#6252)

buildbot success in ASF Buildbot on cassandra-trunk

2014-06-17 Thread buildbot

The Buildbot has detected a restored build on builder cassandra-trunk while 
building cassandra.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/337

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch trunk] 75b9ea41eddffe874e10a9a3160c4c4694857089
Blamelist: Aleksey Yeschenko alek...@apache.org

Build succeeded!

sincerely,
 -The Buildbot

[jira] [Updated] (CASSANDRA-7411) Node enables vnodes when bounced