date:20140711

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

Robert Stupp commented on CASSANDRA-7534:
-

I guess what you want (in CQL terms) is TTL on partition key - am I right?

IMO the problem with your particular use case is that the TTL changes whenever
a session is used (no implicit change of session data). Means: you need to
change the TTL of the whole partition although the data has not changed (user
is just browsing on the site). This implies a lot of writes without changing
data - and each write invalidates older writes for the same session. If i'm
right, then you get into a similar problem that [~iamaleksey] described here:
http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

It's perfectly valid to store servlet API session data in C* - but you have to
do it right. This does not only mean to create a proper data and access
models but also to route the same HTTP session to the same web server (in this
case Tomcat) to keep session data local within the same JVM and not just
multiplying access load from Tomcat to C* (which may have to replicate your
session data). Means (for this use case) just use C* as a storage to failover a
HTTP session to another Tomcat. And only update the partition TTL (by
re-inserting all current data) at very low frequency.

But despite your use case, I think there is already another JIRA ticket that
covers the same (update TTL on row) or similar scenario - not sure.

TTL on rows to ensure data consistency
--

Key: CASSANDRA-7534
URL: https://issues.apache.org/jira/browse/CASSANDRA-7534
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Morten Jorgensen
Fix For: 3.0

Requesting TTL on key/row-level to ensure consistency between data stored in
columns under the same key. Please refer to original request for this
enhancement in CASSANDRA-2469.
There are valid reasons why you would want the TTL on the key/row rather than
the individual columns. The reason why you store your data as columns under a
common key is that the data is related, and hence you want to ensure that all
data exists as long as the key exists. Example:
I have developed a plugin for Tomcat that stores user session data in
Cassandra, effectively making Tomcat stateless (and scalable) even if it
maintains user sessions. Session data is stored in Cassandra under the
session ID (key/row), as session attribute name/value-pairs (columns).
Sessions time out after N minutes of inactivity, and I would prefer to use
Cassandra's TTL for this. Otherwise I have to traverse all sessions
periodically and purge sessions that are past their expiry time. But, the
problem using the column-level TTL is that I risk timing out only parts of a
user session, rather than all of it. So, a user that accesses JSPs that
require read/write access to only certain session objects will retain those
objects in Cassandra, while other session objects will expire with their
respective column TTL's. This creates an inconsistent session, with some data
expiring and some data remaining in the session - while what I need is the
entire session to remain or expire as a whole.
This is one valid use case for key-level TTL, and this is only one specific
example of the more general use case of column consistency. I suggest that
this issue is re-opened an re-evaluated from this perspective.

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

[jira] [Commented] (CASSANDRA-7534) TTL on rows to ensure data consistency

2014-07-11 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-7534:
--

[~mor...@apache.org] You can probably remodel and use range-tombstones instead.

TTL on rows to ensure data consistency
--

Key: CASSANDRA-7534
URL: https://issues.apache.org/jira/browse/CASSANDRA-7534
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Morten Jorgensen
Fix For: 3.0

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

[jira] [Commented] (CASSANDRA-7534) TTL on rows to ensure data consistency

2014-07-11 Thread Morten Jorgensen (JIRA)

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

Morten Jorgensen commented on CASSANDRA-7534:
-

Robert, thanks a lot for your comment. This explains the negative impact of
doing what I am trying to do. Each access to a web session would require the
TTL to be updated, regardless of if the actual session data changes or not.
This again means that I do indeed hit the anti-pattern in Aleksey's article.

I do _not_ want to store session data in memory in Tomcat, as this forces me to
use a sticky load balancer. I want any request to be able to hit any Tomcat
node, and let tomcat be completely stateless and horizontally scalable. If this
means that I need to run periodical purge-scripts across my sessions in
Cassandra then so be it.

TTL on rows to ensure data consistency
--

Key: CASSANDRA-7534
URL: https://issues.apache.org/jira/browse/CASSANDRA-7534
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Morten Jorgensen
Fix For: 3.0

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

[jira] [Created] (CASSANDRA-7535) Coverage analysis for range queries

David Semeria created CASSANDRA-7535:


 Summary: Coverage analysis for range queries
 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
 Fix For: 2.0.9


This is a regression related to 
https://issues.apache.org/jira/browse/CASSANDRA-4858

Range queries are taking orders of magnitude more time to complete than before 
because the query planner is frequently unable to calculate the correct 
intersection of contiguous ranges for a given node.

For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE when 
RF = #nodes when in fact it can result in several hundred scans (sometimes 
thousands). The problem is exasperated with vnodes.

The regression occurred at some point between 2.0.4 (which works fine) and 
2.0.9.   



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

[jira] [Commented] (CASSANDRA-5571) Reject bootstrapping endpoints that are already in the ring with different gossip data

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

Brandon Williams commented on CASSANDRA-5571:
-

bq. This causes a problem the first time I bootstrap a cluster since all nodes
call checkForEndpointCollision() but no one have yet started Gossiper

Only bootstrapping nodes call it, and seeds never bootstrap, which is what the
other nodes are trying to communicate with. You can probably either a) make
sure your seeds have started first, or b) just not bootstrap at all, since it's
a fresh cluster where it doesn't make any sense to do so. In any case, I
recommend taking this to the Cassandra and/or Priam MLs, since this ticket
isn't the real source of your problem.

Reject bootstrapping endpoints that are already in the ring with different
gossip data
--

Key: CASSANDRA-5571
URL: https://issues.apache.org/jira/browse/CASSANDRA-5571
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Rick Branson
Assignee: Tyler Hobbs
Fix For: 2.0.2

Attachments: 5571-2.0-v1.patch, 5571-2.0-v2.patch, 5571-2.0-v3.patch

The ring can be silently broken by improperly bootstrapping an endpoint that
has an existing entry in the gossip table. In the case where a node attempts
to bootstrap with the same IP address as an existing ring member, the old
token metadata is dropped without warning, resulting in range shifts for the
cluster.
This isn't so bad for non-vnode cases where, in general, tokens are
explicitly assigned, and a bootstrap on the same token would result in no
range shifts. For vnode cases, the convention is to just let nodes come up by
selecting their own tokens, and a bootstrap will override the existing tokens
for that endpoint.
While there are some other issues open for adding an explicit rebootstrap
feature for vnode cases, given the changes in operator habits for vnode
rings, it seems a bit too easy to make this happen. Even more undesirable is
the fact that it's basically silent.
This is a proposal for checking for this exact case: bootstraps on endpoints
with existing ring entries that have different hostIDs and/or tokens should
be rejected with an error message describing what happened and how to
override the safety check. It looks like the override can be supported using
the existing nodetool removenode -force.
I can work up a patch for this.

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

[jira] [Updated] (CASSANDRA-7263) Improve the layout of the output of compactionstats

2014-07-11 Thread JIRA


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

Nicolas Lalevée updated CASSANDRA-7263:
---

Attachment: compactionstats-layout-2.patch

this time the patch with the proper white spaces

 Improve the layout of the output of compactionstats
 ---

 Key: CASSANDRA-7263
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7263
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Nicolas Lalevée
Priority: Trivial
 Attachments: compactionstats-layout-2.patch, 
 compactionstats-layout.patch


 If the name of the column family or the keyspace is too long, the layout of 
 the output is messed up. Hence the suggested patch which computes the size 
 the columns so they can be printed properly.



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

[jira] [Updated] (CASSANDRA-7486) Compare CMS and G1 pause times


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

Jonathan Ellis updated CASSANDRA-7486:
--

Fix Version/s: (was: 2.1.0)
   2.1.1

 Compare CMS and G1 pause times
 --

 Key: CASSANDRA-7486
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7486
 Project: Cassandra
  Issue Type: Test
  Components: Config
Reporter: Jonathan Ellis
Assignee: Ryan McGuire
 Fix For: 2.1.1


 See 
 http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning
  and https://twitter.com/rbranson/status/482113561431265281
 May want to default 2.1 to G1.
 2.1 is a different animal from 2.0 after moving most of memtables off heap.  
 Suspect this will help G1 even more than CMS.  (NB this is off by default but 
 needs to be part of the test.)



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

[jira] [Updated] (CASSANDRA-6312) Create dtest suite for user types


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

Jonathan Ellis updated CASSANDRA-6312:
--

Fix Version/s: (was: 2.1.0)
   2.1.1

 Create dtest suite for user types
 -

 Key: CASSANDRA-6312
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6312
 Project: Cassandra
  Issue Type: Test
Reporter: Ryan McGuire
Assignee: Russ Hatch
 Fix For: 2.1.1


 See examples in CASSANDRA-5590



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

[jira] [Updated] (CASSANDRA-7524) cqlsh fails when version number parts are not int


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

Jonathan Ellis updated CASSANDRA-7524:
--

Reproduced In: 2.1 rc2, 2.1 rc1  (was: 2.1 rc1, 2.1 rc2)
Fix Version/s: (was: 2.1.0)
   2.1.1

 cqlsh fails when version number parts are not int
 -

 Key: CASSANDRA-7524
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7524
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Alexander Bulaev
Assignee: Mikhail Stepura
Priority: Trivial
  Labels: cqlsh
 Fix For: 2.1.1


 {code}
 alexbool@gibson ~ cqlsh
 Traceback (most recent call last):
   File /usr/bin/cqlsh, line 1894, in module
 main(*read_options(sys.argv[1:], os.environ))
   File /usr/bin/cqlsh, line 1877, in main
 single_statement=options.execute)
   File /usr/bin/cqlsh, line 496, in __init__
 self.get_connection_versions()
   File /usr/bin/cqlsh, line 595, in get_connection_versions
 self.cass_ver_tuple = tuple(map(int, vers['build'].split('-', 
 1)[0].split('.')[:3]))
 ValueError: invalid literal for int() with base 10: '0~rc2'
 {code}
 I used cassandra 2.1-rc2 debs from Apache repository



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

[jira] [Commented] (CASSANDRA-7523) add date and time types

2014-07-11 Thread Joshua McKenzie (JIRA)


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

Joshua McKenzie commented on CASSANDRA-7523:


Are we shooting for microsecond or millisecond resolution on the time type?

 add date and time types
 ---

 Key: CASSANDRA-7523
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Jonathan Ellis
Assignee: Joshua McKenzie
Priority: Minor
 Fix For: 2.0.10


 http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
 (we already have timestamp; interval is out of scope for now, and see 
 CASSANDRA-6350 for discussion on timestamp-with-time-zone.  but date/time 
 should be pretty easy to add.)



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

[jira] [Commented] (CASSANDRA-6230) Write hints to a file instead of a table

2014-07-11 Thread Nick Bailey (JIRA)


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

Nick Bailey commented on CASSANDRA-6230:


It would be great if we could expose a metric indicating when hints are 
'expired'. Potentially even which nodes hints were expired for.

 Write hints to a file instead of a table
 

 Key: CASSANDRA-6230
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6230
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 3.0


 Writing to a file would have less overhead on both hint creation and replay.



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

[jira] [Assigned] (CASSANDRA-7535) Coverage analysis for range queries


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

Jonathan Ellis reassigned CASSANDRA-7535:
-

Assignee: Tyler Hobbs

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.9


 This is a regression related to 
 https://issues.apache.org/jira/browse/CASSANDRA-4858
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Updated] (CASSANDRA-7535) Coverage analysis for range queries


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

Jonathan Ellis updated CASSANDRA-7535:
--

Reproduced In: 2.0.9
Fix Version/s: (was: 2.0.9)
   2.0.10

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 https://issues.apache.org/jira/browse/CASSANDRA-4858
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

Jonathan Ellis commented on CASSANDRA-7535:
---

Is this the same as CASSANDRA-6976?

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 https://issues.apache.org/jira/browse/CASSANDRA-4858
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Updated] (CASSANDRA-7525) Querying by multiple secondary indexes gives java.lang.IllegalArgumentException on some cases


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

Tyler Hobbs updated CASSANDRA-7525:
---

Fix Version/s: 2.1.0

 Querying by multiple secondary indexes gives 
 java.lang.IllegalArgumentException on some cases
 -

 Key: CASSANDRA-7525
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7525
 Project: Cassandra
  Issue Type: Bug
Reporter: Tuukka Mustonen
Assignee: Tyler Hobbs
 Fix For: 2.1.0


 Querying by:
 * non-primary key column with secondary index + collection with secondary 
 index
 * primary key column with secondary index + non-primary key column with 
 secondary index
 gives {{ErrorMessage code= [Server error] 
 message=java.lang.IllegalArgumentException: expected one element but was: 
 org.apache.cassandra.db.index.composites.CompositesSearcher@156b5576, 
 org.apache.cassandra.db.index.composites.CompositesSearcher@39b7c0f6}}
 Steps to reproduce:
 {code}
 cqlsh:cs CREATE TABLE test (
   ...   id1 text,
   ...   id2 text,
   ...   column1 text,
   ...   column2 text,
   ...   collection settext,
   ...   PRIMARY KEY (id1, id2)
   ... );
 cqlsh:cs 
 {code}
 Simple query by primary key works as should:
 {code}
 cqlsh:cs SELECT * FROM test WHERE id1 = 'foo';
 (0 rows)
 cqlsh:cs SELECT * FROM test WHERE id1 = 'foo' AND id2 = 'bar';
 (0 rows)
 {code}
 Query by secondary index + non-indexed column:
 {code}
 cqlsh:cs CREATE INDEX test_column1s ON test(column1);
 cqlsh:cs SELECT * FROM test WHERE column1 = 'foo';
 (0 rows)
 cqlsh:cs SELECT * FROM test WHERE column1 = 'foo' AND column2 = 'bar' ALLOW 
 FILTERING;
 (0 rows)
 {code}
 Add secondary index also for the second column:
 {code}
 cqlsh:cs CREATE INDEX test_column2s ON test(column2);
 cqlsh:cs SELECT * FROM test WHERE column1 = 'foo' AND column2 = 'bar' ALLOW 
 FILTERING;
 (0 rows)
 {code}
 Doesn't matter if we bring primary key or the collection there as well:
 {code}
 cqlsh:cs SELECT * FROM test WHERE id1 = 'blah' AND column1 = 'foo' AND 
 column2 = 'bar' ALLOW FILTERING;
 (0 rows)
 cqlsh:cs SELECT * FROM test WHERE column1 = 'foo' AND collection CONTAINS 
 'bar' ALLOW FILTERING;
 (0 rows)
 {code}
 Let's add index for the collection:
 {code}
 cqlsh:cs CREATE INDEX test_collections ON test(collection);
 cqlsh:cs SELECT * FROM test WHERE collection CONTAINS 'bar';
 (0 rows)
 {code}
 But then combine secondary index column and collection with secondary index:
 {code}
 cqlsh:cs SELECT * FROM test WHERE column1 = 'foo' AND collection CONTAINS 
 'bar' ALLOW FILTERING;
 ErrorMessage code= [Server error] 
 message=java.lang.IllegalArgumentException: expected one element but was: 
 org.apache.cassandra.db.index.composites.CompositesSearcher@68e37722, 
 org.apache.cassandra.db.index.composites.CompositesSearcher@2da28efa
 {code}
 Furthermore, query by primary key field with secondary index + non-primary 
 key column with secondary index:
 {code}
 cqlsh:cs CREATE INDEX test_id2s ON test(id2);
 cqlsh:cs SELECT * FROM test WHERE id2 = 'foo' AND column1 = 'bar' ALLOW 
 FILTERING;
 ErrorMessage code= [Server error] 
 message=java.lang.IllegalArgumentException: expected one element but was: 
 org.apache.cassandra.db.index.composites.CompositesSearcher@3ca899f1, 
 org.apache.cassandra.db.index.composites.CompositesSearcher@6112bc53
 {code}
 I'm a cassandra noob so maybe I'm trying to do things the db is not meant to 
 do?



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

[jira] [Commented] (CASSANDRA-7059) Range query with strict bound on clustering column can return less results than required for compact tables


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

Alex Liu commented on CASSANDRA-7059:
-

I got the following error for pig-test on 2.1 branch for a counter CF

{code}
create column family CC with  +
   key_validation_class = UTF8Type and  +
   default_validation_class=CounterColumnType  +
   and comparator=UTF8Type;
{code}

The cal query is 
{code}
SELECT * FROM CC WHERE token(key) = token(?)  AND column1   ?  LIMIT 
1000 ALLOW FILTERING
{code}

{code}
[junit] java.lang.RuntimeException
[junit] at 
org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.executeQuery(CqlPagingRecordReader.java:665)
[junit] at 
org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.computeNext(CqlPagingRecordReader.java:366)
[junit] at 
org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.computeNext(CqlPagingRecordReader.java:289)
[junit] at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
[junit] at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
[junit] at 
org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader.getProgress(CqlPagingRecordReader.java:195)
[junit] at 
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigRecordReader.getProgress(PigRecordReader.java:169)
[junit] at 
org.apache.hadoop.mapred.MapTask$NewTrackingRecordReader.getProgress(MapTask.java:514)
[junit] at 
org.apache.hadoop.mapred.MapTask$NewTrackingRecordReader.nextKeyValue(MapTask.java:539)
[junit] at 
org.apache.hadoop.mapreduce.MapContext.nextKeyValue(MapContext.java:67)
[junit] at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:143)
[junit] at 
org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:764)
[junit] at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370)
[junit] at 
org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:212)
[junit] Caused by: InvalidRequestException(why:The query requests a 
restriction of rows with a strict bound (column1  ?) over a range of 
partitions. This is not supported by the underlying storage engine for COMPACT 
tables if a LIMIT is provided. Please either make the condition non strict 
(column1 = ?) or remove the user LIMIT)
[junit] at 
org.apache.cassandra.thrift.Cassandra$prepare_cql3_query_result$prepare_cql3_query_resultStandardScheme.read(Cassandra.java:52282)
[junit] at 
org.apache.cassandra.thrift.Cassandra$prepare_cql3_query_result$prepare_cql3_query_resultStandardScheme.read(Cassandra.java:52259)
[junit] at 
org.apache.cassandra.thrift.Cassandra$prepare_cql3_query_result.read(Cassandra.java:52198)
[junit] at 
org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
[junit] at 
org.apache.cassandra.thrift.Cassandra$Client.recv_prepare_cql3_query(Cassandra.java:1797)
[junit] at 
org.apache.cassandra.thrift.Cassandra$Client.prepare_cql3_query(Cassandra.java:1783)
[junit] at 
org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.prepareQuery(CqlPagingRecordReader.java:605)
[junit] at 
org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.executeQuery(CqlPagingRecordReader.java:635)
[junit] ... 13 more
{code}

 Range query with strict bound on clustering column can return less results 
 than required for compact tables
 ---

 Key: CASSANDRA-7059
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7059
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 2.0.9

 Attachments: 7059.txt


 What's wrong:
 {noformat}
 CREATE TABLE test (
 k int,
 v int,
 PRIMARY KEY (k, v)
 ) WITH COMPACT STORAGE;
 INSERT INTO test(k, v) VALUES (0, 0);
 INSERT INTO test(k, v) VALUES (0, 1);
 INSERT INTO test(k, v) VALUES (1, 0);
 INSERT INTO test(k, v) VALUES (1, 1);
 INSERT INTO test(k, v) VALUES (2, 0);
 INSERT INTO test(k, v) VALUES (2, 1);
 SELECT * FROM test WHERE v  0 LIMIT 3 ALLOW FILTERING;
  k | v
 ---+---
  1 | 1
  0 | 1
 {noformat}
 That last query should return 3 results.
 The problem lies into how we deal with 'strict greater than' ({{}}) for 
 wide compact storage table. Namely, for those tables, we internally only 
 support inclusive bounds (for CQL3 tables this is not a problem as we deal 
 with this using the 'end-of-component' of the CompositeType encoding). So we 
 compensate by asking one more result than asked by the user, and we trim 
 afterwards if that was

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

David Semeria commented on CASSANDRA-7535:
--

I think not. 

[CASSANDRA-6906|https://issues.apache.org/jira/browse/CASSANDRA-6906] refers to 
skipping the Determining replicas to query step in range slice queries, 
whereas [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858] 
refers specifically to the problem of correctly calculating contiguous ranges.

In a nutshell, we're doing hundreds of separate single range scans when a 
single scan over a broader range would suffice.

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 https://issues.apache.org/jira/browse/CASSANDRA-4858
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat


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

Alex Liu commented on CASSANDRA-6454:
-

I got some test errors for compact tables using CqlStorage in CASSANDRA-7059, I 
hope change them to CqlNativeStorage fixes the issue.

 Pig support for hadoop CqlInputFormat
 -

 Key: CASSANDRA-6454
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6454
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 2.0.10

 Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt


 CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it



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

[jira] [Commented] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat


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

Brandon Williams commented on CASSANDRA-6454:
-

Yes, that's a bug in CPRR, I'm fine with moving away from it.

 Pig support for hadoop CqlInputFormat
 -

 Key: CASSANDRA-6454
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6454
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 2.0.10

 Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt


 CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it



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

[jira] [Updated] (CASSANDRA-7535) Coverage analysis for range queries


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

David Semeria updated CASSANDRA-7535:
-

Description: 
This is a regression related to 
[CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]

Range queries are taking orders of magnitude more time to complete than before 
because the query planner is frequently unable to calculate the correct 
intersection of contiguous ranges for a given node.

For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE when 
RF = #nodes when in fact it can result in several hundred scans (sometimes 
thousands). The problem is exasperated with vnodes.

The regression occurred at some point between 2.0.4 (which works fine) and 
2.0.9.   

  was:
This is a regression related to 
https://issues.apache.org/jira/browse/CASSANDRA-4858

Range queries are taking orders of magnitude more time to complete than before 
because the query planner is frequently unable to calculate the correct 
intersection of contiguous ranges for a given node.

For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE when 
RF = #nodes when in fact it can result in several hundred scans (sometimes 
thousands). The problem is exasperated with vnodes.

The regression occurred at some point between 2.0.4 (which works fine) and 
2.0.9.   


 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

Brandon Williams commented on CASSANDRA-7535:
-

Can you provide a simple way to reproduce?  Does it absolutely require vnodes?  
I tried rf=3/n=3 with single token nodes on 2.0.4 and 2.0 head and saw no 
differences with tracing on.

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7523) add date and time types


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

Robert Stupp commented on CASSANDRA-7523:
-

Why not add extra resolution in terms of microsecond or even nanosecond 
precision. I don't want to bring extra complexity but providing the existing 
(low resolution) timestamp plus a high resolution (nano precision) 
timestamp plus high resolution time plus date doesn't sound that bad. The new 
Java 8 {{java.time}} API brings nanosecond precision - so people might want to 
persist that using some natively supported type.

 add date and time types
 ---

 Key: CASSANDRA-7523
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Jonathan Ellis
Assignee: Joshua McKenzie
Priority: Minor
 Fix For: 2.0.10


 http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
 (we already have timestamp; interval is out of scope for now, and see 
 CASSANDRA-6350 for discussion on timestamp-with-time-zone.  but date/time 
 should be pretty easy to add.)



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

David Semeria commented on CASSANDRA-7535:
--

Brandon, 2.0.4 works as expected, try it with 2.0.9.

We have two DCs, one running 2.0.4 and the other running 2.0.9. Range scans are 
coming back in around 10ms in DC1 (RF=3/n=3) and were taking anywhere between 
200 and 1000ms in DC2 (RF= 5,n=5). When I put the 2.0.4 cassandra jar in DC2 
the latencies disappeared. 

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Updated] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60


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

Brandon Williams updated CASSANDRA-7432:


Attachment: 7432.txt

Patch to enable these. [~enigmacurry] want to give them a whirl?

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Assigned] (CASSANDRA-7200) word count broken


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

Brandon Williams reassigned CASSANDRA-7200:
---

Assignee: Brandon Williams  (was: Ala' Alkhaldi)

 word count broken
 -

 Key: CASSANDRA-7200
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7200
 Project: Cassandra
  Issue Type: Bug
  Components: Examples
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 2.0.10

 Attachments: 7200_v1.txt, 7200_v2.txt, 7200_v3.txt


 word_count_setup hangs forever, and word_count loops forever with this 
 exception:
 {noformat}
 DEBUG 17:52:42,875 java.io.IOException: config(config)
 at org.apache.hadoop.conf.Configuration.init(Configuration.java:260)
 at org.apache.hadoop.mapred.JobConf.init(JobConf.java:341)
 at org.apache.hadoop.mapreduce.JobContext.init(JobContext.java:76)
 at 
 org.apache.hadoop.mapreduce.TaskAttemptContext.init(TaskAttemptContext.java:35)
 at 
 org.apache.hadoop.mapreduce.TaskInputOutputContext.init(TaskInputOutputContext.java:44)
 at org.apache.hadoop.mapreduce.MapContext.init(MapContext.java:43)
 at org.apache.hadoop.mapreduce.Mapper$Context.init(Mapper.java:105)
 at sun.reflect.GeneratedConstructorAccessor14.newInstance(Unknown 
 Source)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:759)
 at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370)
 at 
 org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:212)
 {noformat}



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

[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60

2014-07-11 Thread graham sanderson (JIRA)


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

graham sanderson commented on CASSANDRA-7432:
-

presumably those should be = rather than 

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Commented] (CASSANDRA-7509) conditional updates don't work from cqlsh


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

Jonathan Ellis commented on CASSANDRA-7509:
---

Besides switching the driver, how much work is this?  Should I ask Brandon or 
Tyler to help?  Would like to fix for 2.1.0-final.

 conditional updates don't work from cqlsh
 -

 Key: CASSANDRA-7509
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7509
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Mikhail Stepura
Priority: Blocker
 Fix For: 2.1.0


 {noformat}
 apache-cassandra-2.1.0-rc2/bin $ ./cqlsh
 Connected to Test Cluster at 127.0.0.1:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.0-rc2 | CQL spec 3.1.7 | Native protocol v3]
 Use HELP for help.
 cqlsh use ks1;
 cqlsh:ks1 create table users(
... userID uuid,
... fname text,
... lname text,
... email text,
... address text,
... zip int,
... state text,
... PRIMARY KEY ((userID, fname), state)
... );
 cqlsh:ks1 insert into users (userID, fname, state, email) VALUES 
 (cfd66ccc-d857-4e90-b1e5-df98a3d40cd6, 'laura', 'ca', 'lau...@gmail.com') if 
 not exists;
 code=2200 [Invalid query] message=Conditional updates are not supported by 
 the protocol version in use. You need to upgrade to a driver using the native 
 protocol v2.
 cqlsh:ks1
 {noformat}



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

[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60


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

Brandon Williams commented on CASSANDRA-7432:
-

Nope.  Read the comment right above it, it evals as =

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Comment Edited] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60

2014-07-11 Thread graham sanderson (JIRA)


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

graham sanderson edited comment on CASSANDRA-7432 at 7/11/14 5:34 PM:
--

presumably that should be an equals for 1.7 and a greater than or equal to for 
patch 60 (note I'm not sure what version of 1.8 has these flags, so setting on 
1.7 only for now seems reasonable


was (Author: graham sanderson):
presumably those should be = rather than 

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Commented] (CASSANDRA-7200) word count broken


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

Brandon Williams commented on CASSANDRA-7200:
-

It looks like your IDE did some strange things with the imports, and I'm not 
sure why the toByteBuffer() line was added to WordCount since it won't compile 
with it, but maybe that's just artifacts from patch against 2.0.0 and a rebase 
will solve it.

cql3 word count looks good, can we add similar logic about the sleep to word 
count (and rebase aganst 2.0 head)?

 word count broken
 -

 Key: CASSANDRA-7200
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7200
 Project: Cassandra
  Issue Type: Bug
  Components: Examples
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 2.0.10

 Attachments: 7200_v1.txt, 7200_v2.txt, 7200_v3.txt


 word_count_setup hangs forever, and word_count loops forever with this 
 exception:
 {noformat}
 DEBUG 17:52:42,875 java.io.IOException: config(config)
 at org.apache.hadoop.conf.Configuration.init(Configuration.java:260)
 at org.apache.hadoop.mapred.JobConf.init(JobConf.java:341)
 at org.apache.hadoop.mapreduce.JobContext.init(JobContext.java:76)
 at 
 org.apache.hadoop.mapreduce.TaskAttemptContext.init(TaskAttemptContext.java:35)
 at 
 org.apache.hadoop.mapreduce.TaskInputOutputContext.init(TaskInputOutputContext.java:44)
 at org.apache.hadoop.mapreduce.MapContext.init(MapContext.java:43)
 at org.apache.hadoop.mapreduce.Mapper$Context.init(Mapper.java:105)
 at sun.reflect.GeneratedConstructorAccessor14.newInstance(Unknown 
 Source)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:759)
 at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370)
 at 
 org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:212)
 {noformat}



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries

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

David Semeria commented on CASSANDRA-7535:
--

Sorry Brandon, I misinterpreted your reply. What I meant to say was to check
2.0.9 which I believe is the current stable version. I don't know if vnodes are
the culprit because I don't have a simple way of checking. I'm guessing that a
vnode range is the same as a normal range, except there are more of them.

Just to emphasize the point, running a range query from DC1 with CL.ALL was 10x
quicker than running the same query with CL.LOCAL_ONE in DC2. It's clearly an
issue with the query planner in 2.0.9

Coverage analysis for range queries
---

Key: CASSANDRA-7535
URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
Fix For: 2.0.10

This is a regression related to
[CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
Range queries are taking orders of magnitude more time to complete than
before because the query planner is frequently unable to calculate the
correct intersection of contiguous ranges for a given node.
For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE
when RF = #nodes when in fact it can result in several hundred scans
(sometimes thousands). The problem is exasperated with vnodes.
The regression occurred at some point between 2.0.4 (which works fine) and
2.0.9.

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

[jira] [Updated] (CASSANDRA-7200) word count broken


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

Brandon Williams updated CASSANDRA-7200:


Assignee: Ala' Alkhaldi  (was: Brandon Williams)

 word count broken
 -

 Key: CASSANDRA-7200
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7200
 Project: Cassandra
  Issue Type: Bug
  Components: Examples
Reporter: Brandon Williams
Assignee: Ala' Alkhaldi
 Fix For: 2.0.10

 Attachments: 7200_v1.txt, 7200_v2.txt, 7200_v3.txt


 word_count_setup hangs forever, and word_count loops forever with this 
 exception:
 {noformat}
 DEBUG 17:52:42,875 java.io.IOException: config(config)
 at org.apache.hadoop.conf.Configuration.init(Configuration.java:260)
 at org.apache.hadoop.mapred.JobConf.init(JobConf.java:341)
 at org.apache.hadoop.mapreduce.JobContext.init(JobContext.java:76)
 at 
 org.apache.hadoop.mapreduce.TaskAttemptContext.init(TaskAttemptContext.java:35)
 at 
 org.apache.hadoop.mapreduce.TaskInputOutputContext.init(TaskInputOutputContext.java:44)
 at org.apache.hadoop.mapreduce.MapContext.init(MapContext.java:43)
 at org.apache.hadoop.mapreduce.Mapper$Context.init(Mapper.java:105)
 at sun.reflect.GeneratedConstructorAccessor14.newInstance(Unknown 
 Source)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:759)
 at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370)
 at 
 org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:212)
 {noformat}



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

[jira] [Commented] (CASSANDRA-7523) add date and time types

2014-07-11 Thread Joshua McKenzie (JIRA)


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

Joshua McKenzie commented on CASSANDRA-7523:


Pre-Java 8 there really isn't much support for microsecond resolution in the 
Java ecosystem.  I'd prefer we add equivalent (to the current) resolution Date 
and Time types immediately and look at introducing high-resolution types w/a 
dependency on Java 8 as a separate effort, giving the new version some time to 
stabilize.

 add date and time types
 ---

 Key: CASSANDRA-7523
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Jonathan Ellis
Assignee: Joshua McKenzie
Priority: Minor
 Fix For: 2.0.10


 http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
 (we already have timestamp; interval is out of scope for now, and see 
 CASSANDRA-6350 for discussion on timestamp-with-time-zone.  but date/time 
 should be pretty easy to add.)



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

[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60


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

Brandon Williams commented on CASSANDRA-7432:
-

If you have a java version like 1.7.0_60-b19 then 1.7.0 is  1.7 and 
60-b19 is  60

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60


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

Brandon Williams commented on CASSANDRA-7432:
-

There is a problem though, our patch logic chops off the -b19 portion.

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60

2014-07-11 Thread graham sanderson (JIRA)


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

graham sanderson commented on CASSANDRA-7432:
-

Sorry, yes... that comment was old, and I wasn't sure it applied (I thought the 
version was actualy 1.7 rather than 1.7.0, so the opposite of what the actual 
problem is!)... sorry about that

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Created] (CASSANDRA-7536) High resolution types for timestamp and time

Robert Stupp created CASSANDRA-7536:
---

 Summary: High resolution types for timestamp and time
 Key: CASSANDRA-7536
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7536
 Project: Cassandra
  Issue Type: New Feature
Reporter: Robert Stupp


CASSANDRA-7523 adds support for _date_ and _time_ data types using the same 
precision as current _timestamp_ type.

This ticket is about to add high resolution (nanosecond precision) types for 
timestamp and time. It should be easy to use with Joda API and Java 8 
{{java.time}} API.

Additionally support for time zone / offset (might need be handled differently) 
could be introduced using new time and timestamp types.

Idea for binary serialization format (from java.time API):
{{(int)year (short)month (short)day (byte)hour (byte)minute (byte)second 
(int)nano (int)offsetInSeconds}}

Additional thinking is required to make even the time zone / offset types 
comparable (even for different TZ offsets) - so these might not be covered by 
this ticket.



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

[jira] [Commented] (CASSANDRA-7523) add date and time types


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

Robert Stupp commented on CASSANDRA-7523:
-

OK - I've created a new ticket CASSANDRA-7536 to cover high precision types.

 add date and time types
 ---

 Key: CASSANDRA-7523
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Jonathan Ellis
Assignee: Joshua McKenzie
Priority: Minor
 Fix For: 2.0.10


 http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
 (we already have timestamp; interval is out of scope for now, and see 
 CASSANDRA-6350 for discussion on timestamp-with-time-zone.  but date/time 
 should be pretty easy to add.)



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

[jira] [Created] (CASSANDRA-7537) Updates and partition tombstones are not given the same timestamp in a CAS batch

2014-07-11 Thread Nicolas Favre-Felix (JIRA)

Nicolas Favre-Felix created CASSANDRA-7537:
--

 Summary: Updates and partition tombstones are not given the same 
timestamp in a CAS batch
 Key: CASSANDRA-7537
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7537
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Nicolas Favre-Felix


Create a table with one partition and 2 CQL rows:
{code}
CREATE TABLE t1 (
k text,
c text,
v text,
PRIMARY KEY(k,c)
);

BEGIN BATCH
INSERT INTO t1 (k,c,v) VALUES ('x','1','1');
INSERT INTO t1 (k,c,v) VALUES ('x','2','2');
APPLY BATCH;
{code}

CAS-delete the full partition based on the expected value of a single column:
{code}
cqlsh:ks1 SELECT * FROM t1 WHERE k='x';

 k | c | v
---+---+---
 x | 1 | 1
 x | 2 | 2

(2 rows)

cqlsh:ks1 BEGIN BATCH
   ... UPDATE t1 SET v = '0' WHERE k = 'x' AND c = '1' IF v = '1';
   ... DELETE FROM t1 WHERE k = 'x';
   ... APPLY BATCH;

 [applied]
---
  True

cqlsh:ks1 SELECT * FROM t1 WHERE k='x';

 k | c | v
---+---+---
 x | 1 | 0

(1 rows)
{code}

sstable2json reports that the updated column has a timestamp 1 greater than the 
partition delete:

{code}
{key: 78,metadata: {deletionInfo: 
{markedForDeleteAt:1405097039224999,localDeletionTime:1405097039}},columns:
 [[1:v,0,1405097039225000]]}
{code}

All mutations in a CAS batch should be applied with the same timestamp.



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

[jira] [Commented] (CASSANDRA-7531) Node replacement leads to null entries in system.peers

2014-07-11 Thread Nicolas Favre-Felix (JIRA)


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

Nicolas Favre-Felix commented on CASSANDRA-7531:


Brandon, it was a hand-rolled 2.0.9 with a few small changes, all unrelated to 
Gossip or cluster metadata.

 Node replacement leads to null entries in system.peers
 --

 Key: CASSANDRA-7531
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7531
 Project: Cassandra
  Issue Type: Bug
Reporter: Nicolas Favre-Felix
Assignee: Brandon Williams

 On 2.0.9, I'm still reproducing a similar behavior as in CASSANDRA-7122.
 One node was replaced and it's no longer in nodetool status but still has 
 null entries in system.peers:
 {code}
  peer  | data_center | host_id  | 
 preferred_ip | rack| release_version | rpc_address   | schema_version 
   | tokens
 ---+-+--+--+-+-+---+--+--
   10.123.99.36 | DC1 | null | 
 null |null |null |  null |
  null | null
  10.123.45.121 | DC1 | e34b134c-c03e-464e-99a9-e3c022eed369 | 
 null | rack123 |  2.0.9-SNAPSHOT | 10.123.45.121 | 
 e6b32c6b-f3f3-3350-9bd1-a9b8620d42ea |  {'4099276460824344804'}
   10.123.77.88 | DC2 | fdd76fa0-0971-43d5-961b-452bd2821b31 | 
 null | rack456 |  2.0.9-SNAPSHOT |  10.123.77.88 | 
 e6b32c6b-f3f3-3350-9bd1-a9b8620d42ea | {'-3074457345618258603'}
 [...]
 {code}
 This causes errors to be logged from the datastax Java driver (2.0.2):
 {code}
 [main] ERROR com.datastax.driver.core.ControlConnection - No rpc_address 
 found for host /10.123.99.36 in 
 my.anonymized.host.name.com/10.123.45.66:9042's peers system table. That 
 should not happen but using address /10.123.99.36 instead
 {code}



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

[jira] [Created] (CASSANDRA-7538) Truncate of a CF should also delete Paxos CF

2014-07-11 Thread sankalp kohli (JIRA)

sankalp kohli created CASSANDRA-7538:


 Summary: Truncate of a CF should also delete Paxos CF
 Key: CASSANDRA-7538
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7538
 Project: Cassandra
  Issue Type: Bug
Reporter: sankalp kohli
Priority: Minor


We don't delete data from Paxos CF during truncate. This will cause data to 
come back in the next CAS round for incomplete commits. 
Also I am not sure whether we already do this but should we also not truncate 
hints for that CF. 



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

[jira] [Updated] (CASSANDRA-7503) Windows - better communication on start-up failure


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

Ala' Alkhaldi updated CASSANDRA-7503:
-

Attachment: 7503_v2.txt

 Windows - better communication on start-up failure
 --

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

 Attachments: 7503_v1.txt, 7503_v2.txt


 The Windows launch scripts report successful launch on certain failure 
 conditions.  For instance, if you try to start a 2nd instance of Cassandra 
 and it fails to bind to the JMX port:
 {code:title=silent failure}
 D:\src\cassandra\bincassandra.bat
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Started cassandra successfully with pid: 6520
 {code}
 {code:title=-f failure}
 D:\src\cassandra\bincassandra.bat -f
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Error: Exception thrown by the agent : java.rmi.server.ExportException: Port 
 already in use: 7199; nested exception is:
 java.net.BindException: Address already in use: JVM_Bind
 {code}
 Reference CASSANDRA-7254 for linux-based solution to a similar NPE on startup 
 due to duplicate JMX port-bind.



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

[jira] [Commented] (CASSANDRA-7503) Windows - better communication on start-up failure


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

Ala' Alkhaldi commented on CASSANDRA-7503:
--

I cleaned up the wait time as well as the sucess/error messages. Now the script 
returns the immediate exit code of the start-process command. Please check 
7503_v2.txt

 Windows - better communication on start-up failure
 --

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

 Attachments: 7503_v1.txt, 7503_v2.txt


 The Windows launch scripts report successful launch on certain failure 
 conditions.  For instance, if you try to start a 2nd instance of Cassandra 
 and it fails to bind to the JMX port:
 {code:title=silent failure}
 D:\src\cassandra\bincassandra.bat
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Started cassandra successfully with pid: 6520
 {code}
 {code:title=-f failure}
 D:\src\cassandra\bincassandra.bat -f
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Error: Exception thrown by the agent : java.rmi.server.ExportException: Port 
 already in use: 7199; nested exception is:
 java.net.BindException: Address already in use: JVM_Bind
 {code}
 Reference CASSANDRA-7254 for linux-based solution to a similar NPE on startup 
 due to duplicate JMX port-bind.



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

[jira] [Commented] (CASSANDRA-5571) Reject bootstrapping endpoints that are already in the ring with different gossip data

2014-07-11 Thread Giampiero Recco (JIRA)


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

Giampiero Recco commented on CASSANDRA-5571:


Thank you Brandon, you are right, Priam has been probably abusing this 
non-feature for a while essentially starting the cluster in a non-conventional 
(less-coordinated) way.

My understanding is that this issue's patch breaks that, although not so much 
for the new check that has been introduced but rather for the timing and the 
collaterals of this check (i.e. other nodes ignoring the gossip message), and 
that's why I raised the problem here, wondering if there is any way we can 
mitigate the collateral effects of this patch while Priam improves the way it 
bootstrap a cluster.

Anyhow, I'm already trying to put this in the Priam dev agenda, and, as you 
suggested, I'll try to discuss this also on the Cassandra ml.


 Reject bootstrapping endpoints that are already in the ring with different 
 gossip data
 --

 Key: CASSANDRA-5571
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5571
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Rick Branson
Assignee: Tyler Hobbs
 Fix For: 2.0.2

 Attachments: 5571-2.0-v1.patch, 5571-2.0-v2.patch, 5571-2.0-v3.patch


 The ring can be silently broken by improperly bootstrapping an endpoint that 
 has an existing entry in the gossip table. In the case where a node attempts 
 to bootstrap with the same IP address as an existing ring member, the old 
 token metadata is dropped without warning, resulting in range shifts for the 
 cluster.
 This isn't so bad for non-vnode cases where, in general, tokens are 
 explicitly assigned, and a bootstrap on the same token would result in no 
 range shifts. For vnode cases, the convention is to just let nodes come up by 
 selecting their own tokens, and a bootstrap will override the existing tokens 
 for that endpoint.
 While there are some other issues open for adding an explicit rebootstrap 
 feature for vnode cases, given the changes in operator habits for vnode 
 rings, it seems a bit too easy to make this happen. Even more undesirable is 
 the fact that it's basically silent.
 This is a proposal for checking for this exact case: bootstraps on endpoints 
 with existing ring entries that have different hostIDs and/or tokens should 
 be rejected with an error message describing what happened and how to 
 override the safety check. It looks like the override can be supported using 
 the existing nodetool removenode -force.
 I can work up a patch for this.



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

[jira] [Comment Edited] (CASSANDRA-5571) Reject bootstrapping endpoints that are already in the ring with different gossip data

2014-07-11 Thread Giampiero Recco (JIRA)


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

Giampiero Recco edited comment on CASSANDRA-5571 at 7/11/14 7:18 PM:
-

Thank you Brandon, you are right, Priam has been probably abusing this 
non-feature for a while essentially starting the cluster in a non-conventional 
(less-coordinated) way.

My understanding is that this issue's patch breaks that, although not so much 
for the new check that has been introduced but rather for the timing and the 
collaterals of this check (i.e. other nodes ignoring the gossip message), and 
that's why I raised the problem here, wondering if there is any way we can 
mitigate the collateral effects of this patch while Priam improves the way it 
bootstrap a cluster.

Anyhow, I'm already trying to put this in the Priam dev agenda, and, as you 
suggested, I'll try to discuss this also on the Cassandra ml.

Update: For reference here you can find one of the issues reporting the problem 
on the Priam side: https://github.com/Netflix/Priam/issues/313



was (Author: grecco-gn):
Thank you Brandon, you are right, Priam has been probably abusing this 
non-feature for a while essentially starting the cluster in a non-conventional 
(less-coordinated) way.

My understanding is that this issue's patch breaks that, although not so much 
for the new check that has been introduced but rather for the timing and the 
collaterals of this check (i.e. other nodes ignoring the gossip message), and 
that's why I raised the problem here, wondering if there is any way we can 
mitigate the collateral effects of this patch while Priam improves the way it 
bootstrap a cluster.

Anyhow, I'm already trying to put this in the Priam dev agenda, and, as you 
suggested, I'll try to discuss this also on the Cassandra ml.


 Reject bootstrapping endpoints that are already in the ring with different 
 gossip data
 --

 Key: CASSANDRA-5571
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5571
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Rick Branson
Assignee: Tyler Hobbs
 Fix For: 2.0.2

 Attachments: 5571-2.0-v1.patch, 5571-2.0-v2.patch, 5571-2.0-v3.patch


 The ring can be silently broken by improperly bootstrapping an endpoint that 
 has an existing entry in the gossip table. In the case where a node attempts 
 to bootstrap with the same IP address as an existing ring member, the old 
 token metadata is dropped without warning, resulting in range shifts for the 
 cluster.
 This isn't so bad for non-vnode cases where, in general, tokens are 
 explicitly assigned, and a bootstrap on the same token would result in no 
 range shifts. For vnode cases, the convention is to just let nodes come up by 
 selecting their own tokens, and a bootstrap will override the existing tokens 
 for that endpoint.
 While there are some other issues open for adding an explicit rebootstrap 
 feature for vnode cases, given the changes in operator habits for vnode 
 rings, it seems a bit too easy to make this happen. Even more undesirable is 
 the fact that it's basically silent.
 This is a proposal for checking for this exact case: bootstraps on endpoints 
 with existing ring entries that have different hostIDs and/or tokens should 
 be rejected with an error message describing what happened and how to 
 override the safety check. It looks like the override can be supported using 
 the existing nodetool removenode -force.
 I can work up a patch for this.



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

[3/6] git commit: Make cql3 word count executable

Make cql3 word count executable


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

Branch: refs/heads/trunk
Commit: 58931dd6fef5f5f200c196fcd78512d46e6cc138
Parents: 233308f
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:20:57 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:20:57 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count 
b/examples/hadoop_cql3_word_count/bin/word_count
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count_counters
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_counters 
b/examples/hadoop_cql3_word_count/bin/word_count_counters
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count_setup
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_setup 
b/examples/hadoop_cql3_word_count/bin/word_count_setup
old mode 100644
new mode 100755

[1/6] git commit: Make cql3 word count executable

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.0 233308f02 - 58931dd6f
  refs/heads/cassandra-2.1 5207cfa59 - 1b1e2b9c0
  refs/heads/trunk 93a662537 - 2d69ad216


Make cql3 word count executable


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

Branch: refs/heads/cassandra-2.0
Commit: 58931dd6fef5f5f200c196fcd78512d46e6cc138
Parents: 233308f
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:20:57 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:20:57 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count 
b/examples/hadoop_cql3_word_count/bin/word_count
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count_counters
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_counters 
b/examples/hadoop_cql3_word_count/bin/word_count_counters
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count_setup
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_setup 
b/examples/hadoop_cql3_word_count/bin/word_count_setup
old mode 100644
new mode 100755

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

Merge branch 'cassandra-2.0' into cassandra-2.1


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

Branch: refs/heads/trunk
Commit: 1b1e2b9c06d0644799c2ac9e0b318cadffb6463b
Parents: 5207cfa 58931dd
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:21:08 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:21:08 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--

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

Branch: refs/heads/trunk
Commit: 2d69ad21651168a904740fc765999e6695b56b2d
Parents: 93a6625 1b1e2b9
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:21:18 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:21:18 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--

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

Merge branch 'cassandra-2.0' into cassandra-2.1


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

Branch: refs/heads/cassandra-2.1
Commit: 1b1e2b9c06d0644799c2ac9e0b318cadffb6463b
Parents: 5207cfa 58931dd
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:21:08 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:21:08 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--

[2/6] git commit: Make cql3 word count executable

Make cql3 word count executable


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

Branch: refs/heads/cassandra-2.1
Commit: 58931dd6fef5f5f200c196fcd78512d46e6cc138
Parents: 233308f
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:20:57 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:20:57 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count 
b/examples/hadoop_cql3_word_count/bin/word_count
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count_counters
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_counters 
b/examples/hadoop_cql3_word_count/bin/word_count_counters
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/58931dd6/examples/hadoop_cql3_word_count/bin/word_count_setup
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_setup 
b/examples/hadoop_cql3_word_count/bin/word_count_setup
old mode 100644
new mode 100755

[4/5] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1

Merge branch 'cassandra-2.1.0' into cassandra-2.1


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

Branch: refs/heads/cassandra-2.1
Commit: d979ba272e5a2a25fdc7ae3176b75163c3adbf04
Parents: 1b1e2b9 9b63413
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:22:26 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:22:26 2014 -0500

--

--

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

Branch: refs/heads/trunk
Commit: 33060c66d753c33620fe3e9ea8ea020fc745df11
Parents: 2d69ad2 d979ba2
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:22:33 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:22:33 2014 -0500

--

--

[1/5] git commit: Make cql3 word count executable

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 1b1e2b9c0 - d979ba272
  refs/heads/trunk 2d69ad216 - 33060c66d


Make cql3 word count executable


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

Branch: refs/heads/cassandra-2.1
Commit: 9b634131c92addd6c75f4d3fd3277a7adbb85662
Parents: 1a9d4b8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:20:57 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:22:09 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9b634131/examples/hadoop_cql3_word_count/bin/word_count
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count 
b/examples/hadoop_cql3_word_count/bin/word_count
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9b634131/examples/hadoop_cql3_word_count/bin/word_count_counters
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_counters 
b/examples/hadoop_cql3_word_count/bin/word_count_counters
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9b634131/examples/hadoop_cql3_word_count/bin/word_count_setup
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_setup 
b/examples/hadoop_cql3_word_count/bin/word_count_setup
old mode 100644
new mode 100755

[2/5] git commit: Make cql3 word count executable

Make cql3 word count executable


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

Branch: refs/heads/trunk
Commit: 9b634131c92addd6c75f4d3fd3277a7adbb85662
Parents: 1a9d4b8
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:20:57 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:22:09 2014 -0500

--
 examples/hadoop_cql3_word_count/bin/word_count  | 0
 examples/hadoop_cql3_word_count/bin/word_count_counters | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup| 0
 3 files changed, 0 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9b634131/examples/hadoop_cql3_word_count/bin/word_count
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count 
b/examples/hadoop_cql3_word_count/bin/word_count
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9b634131/examples/hadoop_cql3_word_count/bin/word_count_counters
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_counters 
b/examples/hadoop_cql3_word_count/bin/word_count_counters
old mode 100644
new mode 100755

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9b634131/examples/hadoop_cql3_word_count/bin/word_count_setup
--
diff --git a/examples/hadoop_cql3_word_count/bin/word_count_setup 
b/examples/hadoop_cql3_word_count/bin/word_count_setup
old mode 100644
new mode 100755

[3/5] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1

Merge branch 'cassandra-2.1.0' into cassandra-2.1


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

Branch: refs/heads/trunk
Commit: d979ba272e5a2a25fdc7ae3176b75163c3adbf04
Parents: 1b1e2b9 9b63413
Author: Brandon Williams brandonwilli...@apache.org
Authored: Fri Jul 11 14:22:26 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Fri Jul 11 14:22:26 2014 -0500

--

--

[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60


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

Brandon Williams commented on CASSANDRA-7432:
-

bq. that comment was old, and I wasn't sure it applied

Not your fault, it was cruft I accidentally left behind, then got the chance to 
reuse :)

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Commented] (CASSANDRA-7531) Node replacement leads to null entries in system.peers


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

Brandon Williams commented on CASSANDRA-7531:
-

Was that node replaced by the same ip address, or a different one?

 Node replacement leads to null entries in system.peers
 --

 Key: CASSANDRA-7531
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7531
 Project: Cassandra
  Issue Type: Bug
Reporter: Nicolas Favre-Felix
Assignee: Brandon Williams

 On 2.0.9, I'm still reproducing a similar behavior as in CASSANDRA-7122.
 One node was replaced and it's no longer in nodetool status but still has 
 null entries in system.peers:
 {code}
  peer  | data_center | host_id  | 
 preferred_ip | rack| release_version | rpc_address   | schema_version 
   | tokens
 ---+-+--+--+-+-+---+--+--
   10.123.99.36 | DC1 | null | 
 null |null |null |  null |
  null | null
  10.123.45.121 | DC1 | e34b134c-c03e-464e-99a9-e3c022eed369 | 
 null | rack123 |  2.0.9-SNAPSHOT | 10.123.45.121 | 
 e6b32c6b-f3f3-3350-9bd1-a9b8620d42ea |  {'4099276460824344804'}
   10.123.77.88 | DC2 | fdd76fa0-0971-43d5-961b-452bd2821b31 | 
 null | rack456 |  2.0.9-SNAPSHOT |  10.123.77.88 | 
 e6b32c6b-f3f3-3350-9bd1-a9b8620d42ea | {'-3074457345618258603'}
 [...]
 {code}
 This causes errors to be logged from the datastax Java driver (2.0.2):
 {code}
 [main] ERROR com.datastax.driver.core.ControlConnection - No rpc_address 
 found for host /10.123.99.36 in 
 my.anonymized.host.name.com/10.123.45.66:9042's peers system table. That 
 should not happen but using address /10.123.99.36 instead
 {code}



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

[jira] [Updated] (CASSANDRA-7527) Bump CQL version and update doc for 2.1


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

Tyler Hobbs updated CASSANDRA-7527:
---

Attachment: 7527.txt

7527.txt (and [branch|https://github.com/thobbs/cassandra/tree/CASSANDRA-7527]) 
bumps the CQL version to 3.2.0 and updates the CQL docs.  There are also a few 
minor fixes to the CQL docs in the patch.

If you want to view the generated html output, run {{ant generate-cql-html}} 
and open {{docs/cql3/CQL.html}} in a browser.

 Bump CQL version and update doc for 2.1
 ---

 Key: CASSANDRA-7527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7527
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Tyler Hobbs
 Fix For: 2.1.0

 Attachments: 7527.txt


 It appears we forgot to bump the CQL version for new 2.1 features (UDT, tuple 
 type, collection indexing), nor did we update the textile doc



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

Brandon Williams commented on CASSANDRA-7535:
-

By 2.0 head I meant the latest 2.0 in the git repo, which is newer than 
2.0.9, so I'm still not sure how to reproduce since that worked the same as 
2.0.4

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Updated] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat


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

Alex Liu updated CASSANDRA-6454:


Attachment: 6454-v3-2.1-branch.txt

 Pig support for hadoop CqlInputFormat
 -

 Key: CASSANDRA-6454
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6454
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 2.0.10

 Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt, 
 6454-v3-2.1-branch.txt


 CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it



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

[jira] [Updated] (CASSANDRA-7503) Windows - better communication on start-up failure

2014-07-11 Thread Joshua McKenzie (JIRA)


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

Joshua McKenzie updated CASSANDRA-7503:
---

Attachment: 7503_v3.txt

Attaching a v3 that does a few extra things I thought of while reviewing:
* Make writing pidfile required since we can't SIGINT procs on Windows without 
it (overrides path if they provide -p)
* Pass back return code as 0 or 1 from PowerShell to .bat file
* Set errorlevel in .bat file and immediately exit, transferring control to 
caller after powershell launch is complete

This should give us idiomatic scripting behavior on Windows (errorlevel) and 
still mirror our behavior on the linux launch scripts.

 Windows - better communication on start-up failure
 --

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

 Attachments: 7503_v1.txt, 7503_v2.txt, 7503_v3.txt


 The Windows launch scripts report successful launch on certain failure 
 conditions.  For instance, if you try to start a 2nd instance of Cassandra 
 and it fails to bind to the JMX port:
 {code:title=silent failure}
 D:\src\cassandra\bincassandra.bat
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Started cassandra successfully with pid: 6520
 {code}
 {code:title=-f failure}
 D:\src\cassandra\bincassandra.bat -f
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Error: Exception thrown by the agent : java.rmi.server.ExportException: Port 
 already in use: 7199; nested exception is:
 java.net.BindException: Address already in use: JVM_Bind
 {code}
 Reference CASSANDRA-7254 for linux-based solution to a similar NPE on startup 
 due to duplicate JMX port-bind.



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

[jira] [Updated] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat


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

Alex Liu updated CASSANDRA-6454:


Attachment: 6454-v3-2.0-branch.txt

 Pig support for hadoop CqlInputFormat
 -

 Key: CASSANDRA-6454
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6454
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 2.0.10

 Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt, 
 6454-v3-2.0-branch.txt, 6454-v3-2.1-branch.txt


 CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it



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

[jira] [Commented] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat


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

Alex Liu commented on CASSANDRA-6454:
-

I comments out that test case, we can fix it later  in another ticket

 Pig support for hadoop CqlInputFormat
 -

 Key: CASSANDRA-6454
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6454
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 2.0.10

 Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt, 
 6454-v3-2.0-branch.txt, 6454-v3-2.1-branch.txt


 CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it



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

[jira] [Comment Edited] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat


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

Alex Liu edited comment on CASSANDRA-6454 at 7/11/14 8:26 PM:
--

I comment out that test case, we can fix it later  in another ticket


was (Author: alexliu68):
I comments out that test case, we can fix it later  in another ticket

 Pig support for hadoop CqlInputFormat
 -

 Key: CASSANDRA-6454
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6454
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 2.0.10

 Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt, 
 6454-v3-2.0-branch.txt, 6454-v3-2.1-branch.txt


 CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it



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

[jira] [Created] (CASSANDRA-7539) DROP INDEX response is missing table name

Tyler Hobbs created CASSANDRA-7539:
--

 Summary: DROP INDEX response is missing table name
 Key: CASSANDRA-7539
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7539
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
 Fix For: 2.1.0
 Attachments: fix-drop-index-response.txt

CASSANDRA-7413 changed the way we put together schema change notifications and 
accidentally broken the table name portion for DROP INDEX statements.

The attached patch fixes this and adds an assertion to prevent similar errors.



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

[jira] [Commented] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat


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

Alex Liu commented on CASSANDRA-6454:
-

I also got a lib conflict issue as following

{code}
   [junit] -  ---
[junit] Testcase: 
testCassandraStorageCompositeColumnCF(org.apache.cassandra.pig.ThriftColumnFamilyTest):
   Caused an ERROR
[junit] org.antlr.runtime.tree.BaseTree.insertChild(ILjava/lang/Object;)V
[junit] java.lang.NoSuchMethodError: 
org.antlr.runtime.tree.BaseTree.insertChild(ILjava/lang/Object;)V
[junit] at 
org.apache.pig.parser.QueryParser.paren_expr(QueryParser.java:17532)
[junit] at 
org.apache.pig.parser.QueryParser.cast_expr(QueryParser.java:17005)
[junit] at 
org.apache.pig.parser.QueryParser.multi_expr(QueryParser.java:15679)
[junit] at 
org.apache.pig.parser.QueryParser.expr(QueryParser.java:15568)
[junit] at 
org.apache.pig.parser.QueryParser.unary_cond(QueryParser.java:15324)
[junit] at 
org.apache.pig.parser.QueryParser.not_cond(QueryParser.java:14951)
[junit] at 
org.apache.pig.parser.QueryParser.and_cond(QueryParser.java:14828)
[junit] at 
org.apache.pig.parser.QueryParser.cond(QueryParser.java:14728)
[junit] at 
org.apache.pig.parser.QueryParser.filter_clause(QueryParser.java:10509)
[junit] at 
org.apache.pig.parser.QueryParser.op_clause(QueryParser.java:7092)
[junit] at 
org.apache.pig.parser.QueryParser.general_statement(QueryParser.java:2314)
[junit] at 
org.apache.pig.parser.QueryParser.statement(QueryParser.java:1579)
[junit] at org.apache.pig.parser.QueryParser.query(QueryParser.java:395)
[junit] at 
org.apache.pig.parser.QueryParserDriver.parse(QueryParserDriver.java:236)
[junit] at 
org.apache.pig.parser.QueryParserDriver.parse(QueryParserDriver.java:179)
[junit] at 
org.apache.pig.PigServer$Graph.parseQuery(PigServer.java:1678)
[junit] at 
org.apache.pig.PigServer$Graph.registerQuery(PigServer.java:1625)
[junit] at org.apache.pig.PigServer.registerQuery(PigServer.java:577)
[junit] at org.apache.pig.PigServer.registerQuery(PigServer.java:590)
[junit] at 
org.apache.cassandra.pig.ThriftColumnFamilyTest.testCassandraStorageCompositeColumnCF(ThriftColumnFamilyTest.java:624)
{code}

Pig 0.12 is built with antlr 3.4.
Cassandra uses antler 3.2

Other than that, CqlNativeStorage passes all the tests

 Pig support for hadoop CqlInputFormat
 -

 Key: CASSANDRA-6454
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6454
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 2.0.10

 Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt


 CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

David Semeria commented on CASSANDRA-7535:
--

I can only suggest you try vnodes. We have 5 clusters running 2.0.9 and all 
exhibit the same behavior. Tomorrow I will try to reproduce using single tokens.

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries

2014-07-11 Thread Benedict (JIRA)


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

Benedict commented on CASSANDRA-7535:
-

If the problem is vnodes, it is quite likely it is related to CASSANDRA-6976. 
Although there is no doubt a possible expansion of scope to the actual despatch 
of those range queries as well as the calculation of where they should go

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

David Semeria commented on CASSANDRA-7535:
--

See [here|https://gist.github.com/hymanroth/cd9124b458870925afa2] for two 
example tracings, both produced with 2.0.9 running vnodes. In the first tracing 
there are around around 100 scans and in the second there are several thousand. 
Querying the same node from another node running 2.0.4 consistently involved a 
single scan.

I don't know if it's the same issue as 
[CASSANDRA-6976|https://issues.apache.org/jira/browse/CASSANDRA-6976]

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Updated] (CASSANDRA-7535) Coverage analysis for range queries


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

Tyler Hobbs updated CASSANDRA-7535:
---

Since Version: 2.0.5

I'm able to reproduce the issue pretty consistently, and it starts with 2.0.5.

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7417) Allow network configuration on interfaces instead of addresses

2014-07-11 Thread Al Tobey (JIRA)


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

Al Tobey commented on CASSANDRA-7417:
-

Users will want to double-check they have network interface name persistence 
enabled in udev or this could get ugly. I haven't seen it in a while, but on 
some hardware Linux may reorder eth numbers between boots. It happens most 
often after firmware upgrades and other things that might have an impact on PCI 
device ordering.

 Allow network configuration on interfaces instead of addresses
 --

 Key: CASSANDRA-7417
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7417
 Project: Cassandra
  Issue Type: Improvement
  Components: Config, Core
Reporter: Matt Kennedy
Priority: Minor
 Attachments: trunk-7417.txt


 This patch adds two config elements to cassandra.yaml: listen_interface and 
 rpc_interface. 
 These can be used instead of their _address counterparts to bind the 
 addresses Cassandra listens on. This capability can drastically simplify some 
 deployment scenarios, especially in clouds which sometimes have quirky 
 automation capabilities.



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

[jira] [Commented] (CASSANDRA-7417) Allow network configuration on interfaces instead of addresses

2014-07-11 Thread Al Tobey (JIRA)


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

Al Tobey commented on CASSANDRA-7417:
-

That said, the vast majority of systems have one interface and it's always the 
same name within an OS release, so +1.

 Allow network configuration on interfaces instead of addresses
 --

 Key: CASSANDRA-7417
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7417
 Project: Cassandra
  Issue Type: Improvement
  Components: Config, Core
Reporter: Matt Kennedy
Priority: Minor
 Attachments: trunk-7417.txt


 This patch adds two config elements to cassandra.yaml: listen_interface and 
 rpc_interface. 
 These can be used instead of their _address counterparts to bind the 
 addresses Cassandra listens on. This capability can drastically simplify some 
 deployment scenarios, especially in clouds which sometimes have quirky 
 automation capabilities.



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

[jira] [Commented] (CASSANDRA-7417) Allow network configuration on interfaces instead of addresses

2014-07-11 Thread Al Tobey (JIRA)


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

Al Tobey commented on CASSANDRA-7417:
-

http://linux-tips.org/article/73/persistent-device-naming-with-udev

 Allow network configuration on interfaces instead of addresses
 --

 Key: CASSANDRA-7417
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7417
 Project: Cassandra
  Issue Type: Improvement
  Components: Config, Core
Reporter: Matt Kennedy
Priority: Minor
 Attachments: trunk-7417.txt


 This patch adds two config elements to cassandra.yaml: listen_interface and 
 rpc_interface. 
 These can be used instead of their _address counterparts to bind the 
 addresses Cassandra listens on. This capability can drastically simplify some 
 deployment scenarios, especially in clouds which sometimes have quirky 
 automation capabilities.



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

[jira] [Commented] (CASSANDRA-7503) Windows - better communication on start-up failure


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

Ala' Alkhaldi commented on CASSANDRA-7503:
--

sounds good to me. +1

 Windows - better communication on start-up failure
 --

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

 Attachments: 7503_v1.txt, 7503_v2.txt, 7503_v3.txt


 The Windows launch scripts report successful launch on certain failure 
 conditions.  For instance, if you try to start a 2nd instance of Cassandra 
 and it fails to bind to the JMX port:
 {code:title=silent failure}
 D:\src\cassandra\bincassandra.bat
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Started cassandra successfully with pid: 6520
 {code}
 {code:title=-f failure}
 D:\src\cassandra\bincassandra.bat -f
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Error: Exception thrown by the agent : java.rmi.server.ExportException: Port 
 already in use: 7199; nested exception is:
 java.net.BindException: Address already in use: JVM_Bind
 {code}
 Reference CASSANDRA-7254 for linux-based solution to a similar NPE on startup 
 due to duplicate JMX port-bind.



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

[jira] [Comment Edited] (CASSANDRA-7503) Windows - better communication on start-up failure


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

Ala' Alkhaldi edited comment on CASSANDRA-7503 at 7/11/14 9:53 PM:
---

looks good to me. +1


was (Author: ala.alkhaldi):
sounds good to me. +1

 Windows - better communication on start-up failure
 --

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

 Attachments: 7503_v1.txt, 7503_v2.txt, 7503_v3.txt


 The Windows launch scripts report successful launch on certain failure 
 conditions.  For instance, if you try to start a 2nd instance of Cassandra 
 and it fails to bind to the JMX port:
 {code:title=silent failure}
 D:\src\cassandra\bincassandra.bat
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Started cassandra successfully with pid: 6520
 {code}
 {code:title=-f failure}
 D:\src\cassandra\bincassandra.bat -f
 Detected powershell execution permissions.  Running with enhanced startup 
 scripts.
 Setting up Cassandra environment
 Starting cassandra server
 Error: Exception thrown by the agent : java.rmi.server.ExportException: Port 
 already in use: 7199; nested exception is:
 java.net.BindException: Address already in use: JVM_Bind
 {code}
 Reference CASSANDRA-7254 for linux-based solution to a similar NPE on startup 
 due to duplicate JMX port-bind.



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

David Semeria commented on CASSANDRA-7535:
--

I forgot to mention that the issue starts to occur around 5 minutes after 
booting. This is why I think the dynamic snitch might be playing a role, see 
the comments for 
[CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]. When the 
issue occurs, the scans randomly vary between hundreds and thousands for each 
query, but never one.

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

Tyler Hobbs commented on CASSANDRA-7535:


It's not yet clear to me why this is the case, but CASSANDRA-6465 is the cause.

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Updated] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60


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

Brandon Williams updated CASSANDRA-7432:


Attachment: 7432.txt

Updated patch uses -ge on the patch version, since we can actually use 
numerical comparison there.

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Updated] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60


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

Brandon Williams updated CASSANDRA-7432:


Attachment: (was: 7432.txt)

 Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
 

 Key: CASSANDRA-7432
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
 Fix For: 1.2.19

 Attachments: 7432.txt


 The new flags in question are as follows:
 {code}
 -XX:+CMSParallelInitialMarkEnabled
 -XX:+CMSEdenChunksRecordAlways
 {code}
 Given we already have
 {code}
 JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC 
 JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC 
 JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled 
 JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
 if [ $JVM_ARCH = 64-Bit ] ; then
 JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
 fi
 {code}
 The assumption would be that people are at least running on large number CPU 
 cores/threads
 I would therefore recommend defaulting these flags if available - the only 
 two possible downsides for {{+CMSEdenChunksRecordAlways}}:
 1) There is a new very short (probably un-contended) lock in the slow (non 
 TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't 
 detected this timing wise - this is the slow path after all
 2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the 
 default) *and* you call {{System.gc()}} then  {{+CMSEdenChunksRecordAlways}} 
 will expose you to a possible seg fault: (see
 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])



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

[jira] [Updated] (CASSANDRA-7535) Coverage analysis for range queries


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

Tyler Hobbs updated CASSANDRA-7535:
---

Attachment: 7535.txt

Post-6465, it was much more likely for all scores to be 0.  In this case, 
{{maxMerged  maxL1 + maxL2}} is false, so the ranges were not merged.  The 
7535.txt patch makes that a {{=}} check to handle the all-zeroes case.

Besides that, it seems like we should give some additional preference to 
merging ranges, given the overhead of each range request.  This is especially 
true for vnodes.  So, I've also added a {{RANGE_MERGING_PREFERENCE}} of 1.5, 
meaning the merged score must be that much worse than the separate scores for 
the ranges to remain split.  I don't believe there's a lot of value in making 
this configurable, so I've left it hard-coded for now.

There's also a [branch|https://github.com/thobbs/cassandra/tree/CASSANDRA-7535] 
with the changes.

 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10

 Attachments: 7535.txt


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries


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

David Semeria commented on CASSANDRA-7535:
--

The all scores zero might explain each node's log containing a line

{{WARN 23:58:59,178 Couldn't determine workload for *IP REDACTED* from value 
NULL}}

for every node except itself at boot.




 Coverage analysis for range queries
 ---

 Key: CASSANDRA-7535
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: David Semeria
Assignee: Tyler Hobbs
 Fix For: 2.0.10, 2.1.0

 Attachments: 7535.txt


 This is a regression related to 
 [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
 Range queries are taking orders of magnitude more time to complete than 
 before because the query planner is frequently unable to calculate the 
 correct intersection of contiguous ranges for a given node.
 For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE 
 when RF = #nodes when in fact it can result in several hundred scans 
 (sometimes thousands). The problem is exasperated with vnodes.
 The regression occurred at some point between 2.0.4 (which works fine) and 
 2.0.9.   



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

[jira] [Commented] (CASSANDRA-7509) conditional updates don't work from cqlsh

2014-07-11 Thread Mikhail Stepura (JIRA)


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

Mikhail Stepura commented on CASSANDRA-7509:


I still have a few failed cqlsh test cases I need to investigate, which 
shouldn't take too long. The problem is I have not much time for contributions 
for a next 2-3 weeks.
[~jbellis] What is ETA for 2.1.0-final? 

 conditional updates don't work from cqlsh
 -

 Key: CASSANDRA-7509
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7509
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Mikhail Stepura
Priority: Blocker
 Fix For: 2.1.0


 {noformat}
 apache-cassandra-2.1.0-rc2/bin $ ./cqlsh
 Connected to Test Cluster at 127.0.0.1:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.0-rc2 | CQL spec 3.1.7 | Native protocol v3]
 Use HELP for help.
 cqlsh use ks1;
 cqlsh:ks1 create table users(
... userID uuid,
... fname text,
... lname text,
... email text,
... address text,
... zip int,
... state text,
... PRIMARY KEY ((userID, fname), state)
... );
 cqlsh:ks1 insert into users (userID, fname, state, email) VALUES 
 (cfd66ccc-d857-4e90-b1e5-df98a3d40cd6, 'laura', 'ca', 'lau...@gmail.com') if 
 not exists;
 code=2200 [Invalid query] message=Conditional updates are not supported by 
 the protocol version in use. You need to upgrade to a driver using the native 
 protocol v2.
 cqlsh:ks1
 {noformat}



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

[jira] [Commented] (CASSANDRA-7059) Range query with strict bound on clustering column can return less results than required for compact tables

2014-07-11 Thread Edward Capriolo (JIRA)


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

Edward Capriolo commented on CASSANDRA-7059:


{code}
 WHERE token(key) = token(?)  
{code}
I do not understand how any of these work under RP because the relationship 
from keys to tokens is many to one? If there are 1000 keys that map to the same 
token how do we page them. I think only paging keys is logically possible and 
always correct?


 Range query with strict bound on clustering column can return less results 
 than required for compact tables
 ---

 Key: CASSANDRA-7059
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7059
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
 Fix For: 2.0.9

 Attachments: 7059.txt


 What's wrong:
 {noformat}
 CREATE TABLE test (
 k int,
 v int,
 PRIMARY KEY (k, v)
 ) WITH COMPACT STORAGE;
 INSERT INTO test(k, v) VALUES (0, 0);
 INSERT INTO test(k, v) VALUES (0, 1);
 INSERT INTO test(k, v) VALUES (1, 0);
 INSERT INTO test(k, v) VALUES (1, 1);
 INSERT INTO test(k, v) VALUES (2, 0);
 INSERT INTO test(k, v) VALUES (2, 1);
 SELECT * FROM test WHERE v  0 LIMIT 3 ALLOW FILTERING;
  k | v
 ---+---
  1 | 1
  0 | 1
 {noformat}
 That last query should return 3 results.
 The problem lies into how we deal with 'strict greater than' ({{}}) for 
 wide compact storage table. Namely, for those tables, we internally only 
 support inclusive bounds (for CQL3 tables this is not a problem as we deal 
 with this using the 'end-of-component' of the CompositeType encoding). So we 
 compensate by asking one more result than asked by the user, and we trim 
 afterwards if that was unnecessary. This works fine for per-partition 
 queries, but don't for range queries since we potentially would have to ask 
 for {{X}} more results where {{X}} is the number of partition fetched, but we 
 don't know {{X}} beforehand.
 I'll note that:
 * this has always be there
 * this only (potentially) affect compact tables
 * this only affect range queries that have a strict bound on the clustering 
 column (this means only {{ALLOW FILTERING}}) queries in particular.
 * this only matters if a {{LIMIT}} is set on the query.
 As for fixes, it's not entirely trivial. The right fix would probably be to 
 start supporting non-inclusive bound internally, but that's far from a small 
 fix and is at best a 2.1 fix (since we'll have to make a messaging protocol 
 change to ship some additional info for SliceQueryFilter). Also, this might 
 be a lot of work for something that only affect some {{ALLOW FILTERING}} 
 queries on compact tables.
 Another (somewhat simpler) solution might be to detect when we have this kind 
 of queries and use a pager with no limit. We would then query a first page 
 using the user limit (plus some smudge factor to avoid being inefficient too 
 often) and would continue paging unless either we've exhausted all results or 
 we can prove that post-processing we do have enough results to satisfy the 
 user limit.  This does mean in some case we might do 2 or more internal 
 queries, but in practice we can probably make that case very rare, and since 
 the query is an {{ALLOW FILTERING}} one, the user is somewhat warned that the 
 query may not be terribly efficient.
 Lastly, we could always start by disallowing the kind of query that is 
 potentially problematic (until we have a proper fix), knowing that users can 
 work around that by either using non-strict bounds or removing the {{LIMIT}}, 
 whichever makes the most sense in their case. In 1.2 in particular, we don't 
 have the query pagers, so the previous solution I describe would be a bit of 
 a mess to implement.



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

[2/3] git commit: Configurable client timeout for cqlsh.

2014-07-11 Thread mishail

Configurable client timeout for cqlsh.

patch by Ryan McGuire; reviewed by Mikhail Stepura for CASSANDRA-7516


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

Branch: refs/heads/trunk
Commit: 37abae6c32b0e81ce4889b1c8714e9c479b52e85
Parents: d979ba2
Author: Ryan McGuire r...@datastax.com
Authored: Sat Jul 12 14:17:48 2014 +1100
Committer: Mikhail Stepura mish...@apache.org
Committed: Sat Jul 12 14:20:49 2014 +1100

--
 CHANGES.txt |  1 +
 bin/cqlsh   | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/37abae6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ce885eb..27c28ae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
  * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
  * Adjust MT depth based on # of partition validating (CASSANDRA-5263)
  * Optimise NativeCell comparisons (CASSANDRA-6755)
+ * Configurable client timeout for cqlsh (CASSANDRA-7516)
 
 
 2.1.0-final

http://git-wip-us.apache.org/repos/asf/cassandra/blob/37abae6c/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index c3a4ea6..9a6d536 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -467,7 +467,8 @@ class Shell(cmd.Cmd):
  display_time_format=DEFAULT_TIME_FORMAT,
  display_float_precision=DEFAULT_FLOAT_PRECISION,
  ssl=False,
- single_statement=None):
+ single_statement=None,
+ client_timeout=10):
 cmd.Cmd.__init__(self, completekey=completekey)
 self.hostname = hostname
 self.port = port
@@ -493,6 +494,7 @@ class Shell(cmd.Cmd):
 self.session = self.conn.connect(keyspace)
 else:
 self.session = self.conn.connect()
+self.session.default_timeout = client_timeout
 self.get_connection_versions()
 
 self.current_keyspace = keyspace
@@ -1778,6 +1780,11 @@ def read_options(cmdlineargs, environment):
 
 hostname = option_with_default(configs.get, 'connection', 'hostname', 
DEFAULT_HOST)
 port = option_with_default(configs.get, 'connection', 'port', DEFAULT_PORT)
+options.client_timeout = option_with_default(configs.get, 'connection', 
'client_timeout', '10')
+if options.client_timeout.lower() == 'none':
+options.client_timeout = None
+else:
+options.client_timeout = int(options.client_timeout)
 
 hostname = environment.get('CQLSH_HOST', hostname)
 port = environment.get('CQLSH_PORT', port)
@@ -1874,7 +1881,8 @@ def main(options, hostname, port):
   display_time_format=options.time_format,
   display_float_precision=options.float_precision,
   ssl=options.ssl,
-  single_statement=options.execute)
+  single_statement=options.execute,
+  client_timeout=options.client_timeout)
 except KeyboardInterrupt:
 sys.exit('Connection aborted.')
 except CQL_ERRORS, e:

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

2014-07-11 Thread mishail

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

Branch: refs/heads/trunk
Commit: c61a7e470426af5faafcb0fef613651c70f9c2da
Parents: 33060c6 37abae6
Author: Mikhail Stepura mish...@apache.org
Authored: Sat Jul 12 14:21:08 2014 +1100
Committer: Mikhail Stepura mish...@apache.org
Committed: Sat Jul 12 14:21:08 2014 +1100

--
 CHANGES.txt |  1 +
 bin/cqlsh   | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)
--


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

[1/3] git commit: Configurable client timeout for cqlsh.

2014-07-11 Thread mishail

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 d979ba272 - 37abae6c3
  refs/heads/trunk 33060c66d - c61a7e470


Configurable client timeout for cqlsh.

patch by Ryan McGuire; reviewed by Mikhail Stepura for CASSANDRA-7516


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

Branch: refs/heads/cassandra-2.1
Commit: 37abae6c32b0e81ce4889b1c8714e9c479b52e85
Parents: d979ba2
Author: Ryan McGuire r...@datastax.com
Authored: Sat Jul 12 14:17:48 2014 +1100
Committer: Mikhail Stepura mish...@apache.org
Committed: Sat Jul 12 14:20:49 2014 +1100

--
 CHANGES.txt |  1 +
 bin/cqlsh   | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/37abae6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ce885eb..27c28ae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
  * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
  * Adjust MT depth based on # of partition validating (CASSANDRA-5263)
  * Optimise NativeCell comparisons (CASSANDRA-6755)
+ * Configurable client timeout for cqlsh (CASSANDRA-7516)
 
 
 2.1.0-final

http://git-wip-us.apache.org/repos/asf/cassandra/blob/37abae6c/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index c3a4ea6..9a6d536 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -467,7 +467,8 @@ class Shell(cmd.Cmd):
  display_time_format=DEFAULT_TIME_FORMAT,
  display_float_precision=DEFAULT_FLOAT_PRECISION,
  ssl=False,
- single_statement=None):
+ single_statement=None,
+ client_timeout=10):
 cmd.Cmd.__init__(self, completekey=completekey)
 self.hostname = hostname
 self.port = port
@@ -493,6 +494,7 @@ class Shell(cmd.Cmd):
 self.session = self.conn.connect(keyspace)
 else:
 self.session = self.conn.connect()
+self.session.default_timeout = client_timeout
 self.get_connection_versions()
 
 self.current_keyspace = keyspace
@@ -1778,6 +1780,11 @@ def read_options(cmdlineargs, environment):
 
 hostname = option_with_default(configs.get, 'connection', 'hostname', 
DEFAULT_HOST)
 port = option_with_default(configs.get, 'connection', 'port', DEFAULT_PORT)
+options.client_timeout = option_with_default(configs.get, 'connection', 
'client_timeout', '10')
+if options.client_timeout.lower() == 'none':
+options.client_timeout = None
+else:
+options.client_timeout = int(options.client_timeout)
 
 hostname = environment.get('CQLSH_HOST', hostname)
 port = environment.get('CQLSH_PORT', port)
@@ -1874,7 +1881,8 @@ def main(options, hostname, port):
   display_time_format=options.time_format,
   display_float_precision=options.float_precision,
   ssl=options.ssl,
-  single_statement=options.execute)
+  single_statement=options.execute,
+  client_timeout=options.client_timeout)
 except KeyboardInterrupt:
 sys.exit('Connection aborted.')
 except CQL_ERRORS, e:

[jira] [Commented] (CASSANDRA-7509) conditional updates don't work from cqlsh


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

Jonathan Ellis commented on CASSANDRA-7509:
---

Goal is to start the vote next Friday.  Can you post your work in progress and 
I'll get it finished?

 conditional updates don't work from cqlsh
 -

 Key: CASSANDRA-7509
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7509
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Mikhail Stepura
Priority: Blocker
 Fix For: 2.1.0


 {noformat}
 apache-cassandra-2.1.0-rc2/bin $ ./cqlsh
 Connected to Test Cluster at 127.0.0.1:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.0-rc2 | CQL spec 3.1.7 | Native protocol v3]
 Use HELP for help.
 cqlsh use ks1;
 cqlsh:ks1 create table users(
... userID uuid,
... fname text,
... lname text,
... email text,
... address text,
... zip int,
... state text,
... PRIMARY KEY ((userID, fname), state)
... );
 cqlsh:ks1 insert into users (userID, fname, state, email) VALUES 
 (cfd66ccc-d857-4e90-b1e5-df98a3d40cd6, 'laura', 'ca', 'lau...@gmail.com') if 
 not exists;
 code=2200 [Invalid query] message=Conditional updates are not supported by 
 the protocol version in use. You need to upgrade to a driver using the native 
 protocol v2.
 cqlsh:ks1
 {noformat}



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

[2/3] git commit: Add listen_interface and rpc_interface options patch by Matt Kennedy; reviewed by Tupshin Harper and jbellis for CASSANDRA-7417

Add listen_interface and rpc_interface options
patch by Matt Kennedy; reviewed by Tupshin Harper and jbellis for CASSANDRA-7417


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

Branch: refs/heads/trunk
Commit: 5e4b8f535fb2b176335ba29a59302b08c3c23766
Parents: 37abae6
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:36:13 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:36:13 2014 -0500

--
 CHANGES.txt |  1 +
 conf/cassandra.yaml | 22 ++---
 .../org/apache/cassandra/config/Config.java |  2 +
 .../cassandra/config/DatabaseDescriptor.java| 49 ++--
 4 files changed, 62 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e4b8f53/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 27c28ae..080c0bc 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.1
+ * Add listen_interface and rpc_interface options (CASSANDRA-7417)
  * Fail to start if commit log replay detects a problem (CASSANDRA-7125)
  * Improve schema merge performance (CASSANDRA-7444)
  * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e4b8f53/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 4d97e86..061b89d 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -337,17 +337,20 @@ storage_port: 7000
 # encryption_options
 ssl_storage_port: 7001
 
-# Address to bind to and tell other Cassandra nodes to connect to. You
-# _must_ change this if you want multiple nodes to be able to
-# communicate!
-# 
+# Address or interface to bind to and tell other Cassandra nodes to connect to.
+# You _must_ change this if you want multiple nodes to be able to communicate!
+#
+# Set listen_address OR listen_interface, not both. Interfaces must correspond
+# to a single address, IP aliasing is not supported.
+#
 # Leaving it blank leaves it up to InetAddress.getLocalHost(). This
 # will always do the Right Thing _if_ the node is properly configured
 # (hostname, name resolution, etc), and the Right Thing is to use the
 # address associated with the hostname (it might not be).
 #
-# Setting this to 0.0.0.0 is always wrong.
+# Setting listen_address to 0.0.0.0 is always wrong.
 listen_address: localhost
+# listen_interface: eth0
 
 # Address to broadcast to other Cassandra nodes
 # Leaving this blank will set it to the same value as listen_address
@@ -376,15 +379,20 @@ native_transport_port: 9042
 # Whether to start the thrift rpc server.
 start_rpc: true
 
-# The address to bind the Thrift RPC service and native transport
+# The address or interface to bind the Thrift RPC service and native transport
 # server to.
 #
-# Leaving this blank has the same effect as on listen_address
+# Set rpc_address OR rpc_interface, not both. Interfaces must correspond
+# to a single address, IP aliasing is not supported.
+#
+# Leaving rpc_address blank has the same effect as on listen_address
 # (i.e. it will be based on the configured hostname of the node).
 #
 # Note that unlike listen_address, you can specify 0.0.0.0, but you must also
 # set broadcast_rpc_address to a value other than 0.0.0.0.
 rpc_address: localhost
+# rpc_interface: eth1
+
 # port for Thrift to listen for clients on
 rpc_port: 9160
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e4b8f53/src/java/org/apache/cassandra/config/Config.java
--
diff --git a/src/java/org/apache/cassandra/config/Config.java 
b/src/java/org/apache/cassandra/config/Config.java
index 4d4a95b..4b3c0e5 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -100,11 +100,13 @@ public class Config
 public Integer storage_port = 7000;
 public Integer ssl_storage_port = 7001;
 public String listen_address;
+public String listen_interface;
 public String broadcast_address;
 public String internode_authenticator;
 
 public Boolean start_rpc = true;
 public String rpc_address;
+public String rpc_interface;
 public String broadcast_rpc_address;
 public Integer rpc_port = 9160;
 public Integer rpc_listen_backlog = 50;

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

[1/3] git commit: Add listen_interface and rpc_interface options patch by Matt Kennedy; reviewed by Tupshin Harper and jbellis for CASSANDRA-7417

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 37abae6c3 - 5e4b8f535
  refs/heads/trunk c61a7e470 - 66dcdd9da


Add listen_interface and rpc_interface options
patch by Matt Kennedy; reviewed by Tupshin Harper and jbellis for CASSANDRA-7417


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

Branch: refs/heads/cassandra-2.1
Commit: 5e4b8f535fb2b176335ba29a59302b08c3c23766
Parents: 37abae6
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:36:13 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:36:13 2014 -0500

--
 CHANGES.txt |  1 +
 conf/cassandra.yaml | 22 ++---
 .../org/apache/cassandra/config/Config.java |  2 +
 .../cassandra/config/DatabaseDescriptor.java| 49 ++--
 4 files changed, 62 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e4b8f53/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 27c28ae..080c0bc 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.1
+ * Add listen_interface and rpc_interface options (CASSANDRA-7417)
  * Fail to start if commit log replay detects a problem (CASSANDRA-7125)
  * Improve schema merge performance (CASSANDRA-7444)
  * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e4b8f53/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 4d97e86..061b89d 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -337,17 +337,20 @@ storage_port: 7000
 # encryption_options
 ssl_storage_port: 7001
 
-# Address to bind to and tell other Cassandra nodes to connect to. You
-# _must_ change this if you want multiple nodes to be able to
-# communicate!
-# 
+# Address or interface to bind to and tell other Cassandra nodes to connect to.
+# You _must_ change this if you want multiple nodes to be able to communicate!
+#
+# Set listen_address OR listen_interface, not both. Interfaces must correspond
+# to a single address, IP aliasing is not supported.
+#
 # Leaving it blank leaves it up to InetAddress.getLocalHost(). This
 # will always do the Right Thing _if_ the node is properly configured
 # (hostname, name resolution, etc), and the Right Thing is to use the
 # address associated with the hostname (it might not be).
 #
-# Setting this to 0.0.0.0 is always wrong.
+# Setting listen_address to 0.0.0.0 is always wrong.
 listen_address: localhost
+# listen_interface: eth0
 
 # Address to broadcast to other Cassandra nodes
 # Leaving this blank will set it to the same value as listen_address
@@ -376,15 +379,20 @@ native_transport_port: 9042
 # Whether to start the thrift rpc server.
 start_rpc: true
 
-# The address to bind the Thrift RPC service and native transport
+# The address or interface to bind the Thrift RPC service and native transport
 # server to.
 #
-# Leaving this blank has the same effect as on listen_address
+# Set rpc_address OR rpc_interface, not both. Interfaces must correspond
+# to a single address, IP aliasing is not supported.
+#
+# Leaving rpc_address blank has the same effect as on listen_address
 # (i.e. it will be based on the configured hostname of the node).
 #
 # Note that unlike listen_address, you can specify 0.0.0.0, but you must also
 # set broadcast_rpc_address to a value other than 0.0.0.0.
 rpc_address: localhost
+# rpc_interface: eth1
+
 # port for Thrift to listen for clients on
 rpc_port: 9160
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e4b8f53/src/java/org/apache/cassandra/config/Config.java
--
diff --git a/src/java/org/apache/cassandra/config/Config.java 
b/src/java/org/apache/cassandra/config/Config.java
index 4d4a95b..4b3c0e5 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -100,11 +100,13 @@ public class Config
 public Integer storage_port = 7000;
 public Integer ssl_storage_port = 7001;
 public String listen_address;
+public String listen_interface;
 public String broadcast_address;
 public String internode_authenticator;
 
 public Boolean start_rpc = true;
 public String rpc_address;
+public String rpc_interface;
 public String broadcast_rpc_address;
 public Integer rpc_port = 9160;
 public Integer rpc_listen_backlog = 50;

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

Branch: refs/heads/trunk
Commit: 66dcdd9da68d888e0d2dfdff2eb802bf236a
Parents: c61a7e4 5e4b8f5
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:36:26 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:36:26 2014 -0500

--
 CHANGES.txt |  1 +
 conf/cassandra.yaml | 22 ++---
 .../org/apache/cassandra/config/Config.java |  2 +
 .../cassandra/config/DatabaseDescriptor.java| 49 ++--
 4 files changed, 62 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/66dcdd9d/CHANGES.txt
--
diff --cc CHANGES.txt
index 321f594,080c0bc..6195d77
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,20 -1,5 +1,21 @@@
 +3.0
 + * Permit configurable timestamps with cassandra-stress (CASSANDRA-7416)
 + * Move sstable RandomAccessReader to nio2, which allows using the
 +   FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050)
 + * Remove CQL2 (CASSANDRA-5918)
 + * Add Thrift get_multi_slice call (CASSANDRA-6757)
 + * Optimize fetching multiple cells by name (CASSANDRA-6933)
 + * Allow compilation in java 8 (CASSANDRA-7208)
 + * Make incremental repair default (CASSANDRA-7250)
 + * Enable code coverage thru JaCoCo (CASSANDRA-7226)
 + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) 
 + * Shorten SSTable path (CASSANDRA-6962)
 + * Use unsafe mutations for most unit tests (CASSANDRA-6969)
 + * Fix race condition during calculation of pending ranges (CASSANDRA-7390)
 +
 +
  2.1.1
+  * Add listen_interface and rpc_interface options (CASSANDRA-7417)
   * Fail to start if commit log replay detects a problem (CASSANDRA-7125)
   * Improve schema merge performance (CASSANDRA-7444)
   * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)

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

[07/11] git commit: merge from 2.0

merge from 2.0


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

Branch: refs/heads/cassandra-2.1
Commit: 83ac8a631ed46bde023779d4ddb0fa0624f64965
Parents: 380583b a454461
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:50:46 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:50:46 2014 -0500

--
 CHANGES.txt   | 1 +
 examples/hadoop_cql3_word_count/bin/word_count| 0
 examples/hadoop_cql3_word_count/bin/word_count_counters   | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup  | 0
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 7 ++-
 5 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/83ac8a63/CHANGES.txt
--
diff --cc CHANGES.txt
index c0fd4c0,e1c8922..d3390f9
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,31 -1,6 +1,32 @@@
 -2.0.10
 +2.1.0-final
 + * (Windows) fix startup when WMI memory query fails (CASSANDRA-7505)
 + * Anti-compaction proceeds if any part of the repair failed (CASANDRA-7521)
 +Merged from 2.0:
+  * Fix range merging when DES scores are zero (CASSANDRA-7535)
   * Warn when SSL certificates have expired (CASSANDRA-7528)
 + * Fix error when doing reversed queries with static columns (CASSANDRA-7490)
 +Merged from 1.2:
 + * Set correct stream ID on responses when non-Exception Throwables
 +   are thrown while handling native protocol messages (CASSANDRA-7470)
 +
 +
 +2.1.0-rc3
 + * Consider expiry when reconciling otherwise equal cells (CASSANDRA-7403)
 + * Introduce CQL support for stress tool (CASSANDRA-6146)
 + * Fix ClassCastException processing expired messages (CASSANDRA-7496)
 + * Fix prepared marker for collections inside UDT (CASSANDRA-7472)
 + * Remove left-over populate_io_cache_on_flush and replicate_on_write
 +   uses (CASSANDRA-7493)
 + * (Windows) handle spaces in path names (CASSANDRA-7451)
 + * Ensure writes have completed after dropping a table, before recycling
 +   commit log segments (CASSANDRA-7437)
 + * Remove left-over rows_per_partition_to_cache (CASSANDRA-7493)
 + * Fix error when CONTAINS is used with a bind marker (CASSANDRA-7502)
 + * Properly reject unknown UDT field (CASSANDRA-7484)
 +Merged from 2.0:
 + * Fix CC#collectTimeOrderedData() tombstone optimisations (CASSANDRA-7394)
 + * Support DISTINCT for static columns and fix behaviour when DISTINC is
 +   not use (CASSANDRA-7305).
   * Workaround JVM NPE on JMX bind failure (CASSANDRA-7254)
   * Fix race in FileCacheService RemovalListener (CASSANDRA-7278)
   * Fix inconsistent use of consistencyForCommit that allowed LOCAL_QUORUM

[09/11] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1

Merge branch 'cassandra-2.1.0' into cassandra-2.1


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

Branch: refs/heads/trunk
Commit: b374fd5930125dd9fe987f5483967e9f519ed328
Parents: 5e4b8f5 83ac8a6
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:51:06 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:51:06 2014 -0500

--
 CHANGES.txt   | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)
--


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

[04/11] git commit: Fix range merging when DES scores are zero patch by thobbs; reviewed by jbellis for CASSANDRA-7535

Fix range merging when DES scores are zero
patch by thobbs; reviewed by jbellis for CASSANDRA-7535


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

Branch: refs/heads/cassandra-2.1
Commit: a4544615dfcbd80122e75c1ba6288a4f17bb4389
Parents: 58931dd
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:49:36 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:49:36 2014 -0500

--
 CHANGES.txt   | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4544615/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d39cf63..e1c8922 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.10
+ * Fix range merging when DES scores are zero (CASSANDRA-7535)
  * Warn when SSL certificates have expired (CASSANDRA-7528)
  * Workaround JVM NPE on JMX bind failure (CASSANDRA-7254)
  * Fix race in FileCacheService RemovalListener (CASSANDRA-7278)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4544615/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index c76a196..32f52ee 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -45,6 +45,11 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 private int UPDATE_INTERVAL_IN_MS = 
DatabaseDescriptor.getDynamicUpdateInterval();
 private int RESET_INTERVAL_IN_MS = 
DatabaseDescriptor.getDynamicResetInterval();
 private double BADNESS_THRESHOLD = 
DatabaseDescriptor.getDynamicBadnessThreshold();
+
+// the score for a merged set of endpoints must be this much worse than 
the score for separate endpoints to
+// warrant not merging two ranges into a single range
+private double RANGE_MERGING_PREFERENCE = 1.5;
+
 private String mbeanName;
 private boolean registered = false;
 
@@ -320,7 +325,7 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 if (maxMerged  0 || maxL1  0 || maxL2  0)
 return true;
 
-return maxMerged  maxL1 + maxL2;
+return maxMerged = (maxL1 + maxL2) * RANGE_MERGING_PREFERENCE;
 }
 
 // Return the max score for the endpoint in the provided list, or -1.0 if 
no node have a score.

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

Branch: refs/heads/trunk
Commit: 93c9fb82ceb83fc134a7574b6fe7cd22da6e5c6c
Parents: 66dcdd9 b374fd5
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:51:14 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:51:14 2014 -0500

--
 CHANGES.txt   | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)
--


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

[03/11] git commit: Fix range merging when DES scores are zero patch by thobbs; reviewed by jbellis for CASSANDRA-7535

Fix range merging when DES scores are zero
patch by thobbs; reviewed by jbellis for CASSANDRA-7535


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

Branch: refs/heads/cassandra-2.1.0
Commit: a4544615dfcbd80122e75c1ba6288a4f17bb4389
Parents: 58931dd
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:49:36 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:49:36 2014 -0500

--
 CHANGES.txt   | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4544615/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d39cf63..e1c8922 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.10
+ * Fix range merging when DES scores are zero (CASSANDRA-7535)
  * Warn when SSL certificates have expired (CASSANDRA-7528)
  * Workaround JVM NPE on JMX bind failure (CASSANDRA-7254)
  * Fix race in FileCacheService RemovalListener (CASSANDRA-7278)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4544615/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index c76a196..32f52ee 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -45,6 +45,11 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 private int UPDATE_INTERVAL_IN_MS = 
DatabaseDescriptor.getDynamicUpdateInterval();
 private int RESET_INTERVAL_IN_MS = 
DatabaseDescriptor.getDynamicResetInterval();
 private double BADNESS_THRESHOLD = 
DatabaseDescriptor.getDynamicBadnessThreshold();
+
+// the score for a merged set of endpoints must be this much worse than 
the score for separate endpoints to
+// warrant not merging two ranges into a single range
+private double RANGE_MERGING_PREFERENCE = 1.5;
+
 private String mbeanName;
 private boolean registered = false;
 
@@ -320,7 +325,7 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 if (maxMerged  0 || maxL1  0 || maxL2  0)
 return true;
 
-return maxMerged  maxL1 + maxL2;
+return maxMerged = (maxL1 + maxL2) * RANGE_MERGING_PREFERENCE;
 }
 
 // Return the max score for the endpoint in the provided list, or -1.0 if 
no node have a score.

[06/11] git commit: merge from 2.0

merge from 2.0


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

Branch: refs/heads/cassandra-2.1.0
Commit: 83ac8a631ed46bde023779d4ddb0fa0624f64965
Parents: 380583b a454461
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jul 11 23:50:46 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Jul 11 23:50:46 2014 -0500

--
 CHANGES.txt   | 1 +
 examples/hadoop_cql3_word_count/bin/word_count| 0
 examples/hadoop_cql3_word_count/bin/word_count_counters   | 0
 examples/hadoop_cql3_word_count/bin/word_count_setup  | 0
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 7 ++-
 5 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/83ac8a63/CHANGES.txt
--
diff --cc CHANGES.txt
index c0fd4c0,e1c8922..d3390f9
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,31 -1,6 +1,32 @@@
 -2.0.10
 +2.1.0-final
 + * (Windows) fix startup when WMI memory query fails (CASSANDRA-7505)
 + * Anti-compaction proceeds if any part of the repair failed (CASANDRA-7521)
 +Merged from 2.0:
+  * Fix range merging when DES scores are zero (CASSANDRA-7535)
   * Warn when SSL certificates have expired (CASSANDRA-7528)
 + * Fix error when doing reversed queries with static columns (CASSANDRA-7490)
 +Merged from 1.2:
 + * Set correct stream ID on responses when non-Exception Throwables
 +   are thrown while handling native protocol messages (CASSANDRA-7470)
 +
 +
 +2.1.0-rc3
 + * Consider expiry when reconciling otherwise equal cells (CASSANDRA-7403)
 + * Introduce CQL support for stress tool (CASSANDRA-6146)
 + * Fix ClassCastException processing expired messages (CASSANDRA-7496)
 + * Fix prepared marker for collections inside UDT (CASSANDRA-7472)
 + * Remove left-over populate_io_cache_on_flush and replicate_on_write
 +   uses (CASSANDRA-7493)
 + * (Windows) handle spaces in path names (CASSANDRA-7451)
 + * Ensure writes have completed after dropping a table, before recycling
 +   commit log segments (CASSANDRA-7437)
 + * Remove left-over rows_per_partition_to_cache (CASSANDRA-7493)
 + * Fix error when CONTAINS is used with a bind marker (CASSANDRA-7502)
 + * Properly reject unknown UDT field (CASSANDRA-7484)
 +Merged from 2.0:
 + * Fix CC#collectTimeOrderedData() tombstone optimisations (CASSANDRA-7394)
 + * Support DISTINCT for static columns and fix behaviour when DISTINC is
 +   not use (CASSANDRA-7305).
   * Workaround JVM NPE on JMX bind failure (CASSANDRA-7254)
   * Fix race in FileCacheService RemovalListener (CASSANDRA-7278)
   * Fix inconsistent use of consistencyForCommit that allowed LOCAL_QUORUM

[02/11] git commit: Fix range merging when DES scores are zero patch by thobbs; reviewed by jbellis for CASSANDRA-7535