[jira] [Commented] (CASSANDRA-10829) cleanup + repair generates a lot of logs

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-10829:
-

correct except:

bq. rate limit is already on 2.2+ (not related to this ticket)
no, that is the only thing that is needed on 2.2+

> cleanup + repair generates a lot of logs
> 
>
> Key: CASSANDRA-10829
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10829
> Project: Cassandra
>  Issue Type: Bug
> Environment: 5 nodes on Cassandra 2.1.11 (on Debian)
>Reporter: Fabien Rousseau
>Assignee: Marcus Eriksson
>
> One of our node generates a lot of cassandra logs (int the 10 MB/s) and CPU 
> usage has increased (by a factor 2-3).
> This was most probably triggered by a "nodetool snapshot" while a cleanup was 
> already running on this node.
> An example of those logs:
> 2015-12-08 09:15:17,794 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to 
> capture released readers [...]
> 2015-12-08 09:15:17,794 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to 
> capture all readers [...]
> 2015-12-08 09:15:17,795 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to 
> capture released readers [...]
> 2015-12-08 09:15:17,795 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to 
> capture all readers [...]
> (I removed SSTableReader information because it's rather long... I can share 
> it privately if needed)
> Note that the date has not been changed (only 1ms between logs)
> It should not generate that gigantic amount of logs :)
> This is probably linked to: 
> https://issues.apache.org/jira/browse/CASSANDRA-9637



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

[jira] [Commented] (CASSANDRA-10831) Fix the way we replace sstables after anticompaction

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-10831:
-

For the record, we have successfully done repair with anticompaction on a 
cluster with 500GB/node and vnodes 

> Fix the way we replace sstables after anticompaction
> 
>
> Key: CASSANDRA-10831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10831
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.1.x
>
>
> We have a bug when we replace sstables after anticompaction, we keep adding 
> duplicates which causes leveled compaction to fail after. Reason being that 
> LCS does not keep its sstables in a {{Set}}, so after first compaction, we 
> will keep around removed sstables in the leveled manifest and that will put 
> LCS in an infinite loop as it tries to mark non-existing sstables as 
> compacting



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

[jira] [Created] (CASSANDRA-10904) Add upgrade procedure related to new role based access control in NEWS.txt

[Reynald Bourtembourg (JIRA)]

Reynald Bourtembourg created CASSANDRA-10904:


 Summary: Add upgrade procedure related to new role based access 
control in NEWS.txt
 Key: CASSANDRA-10904
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10904
 Project: Cassandra
  Issue Type: Task
  Components: Documentation and Website
Reporter: Reynald Bourtembourg


The upgrade procedure related to new role based access control feature in 
Cassandra 2.2 is not documented in NEWS.txt file.

The upgrade procedure is described in this blog post:
http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra



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

[jira] [Comment Edited] (CASSANDRA-10831) Fix the way we replace sstables after anticompaction

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson edited comment on CASSANDRA-10831 at 12/18/15 9:09 AM:
---

For the record, we have successfully done repair with anticompaction on a 
cluster with 500GB/node and vnodes with the patch


was (Author: krummas):
For the record, we have successfully done repair with anticompaction on a 
cluster with 500GB/node and vnodes 

> Fix the way we replace sstables after anticompaction
> 
>
> Key: CASSANDRA-10831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10831
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.1.x
>
>
> We have a bug when we replace sstables after anticompaction, we keep adding 
> duplicates which causes leveled compaction to fail after. Reason being that 
> LCS does not keep its sstables in a {{Set}}, so after first compaction, we 
> will keep around removed sstables in the leveled manifest and that will put 
> LCS in an infinite loop as it tries to mark non-existing sstables as 
> compacting



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

[jira] [Comment Edited] (CASSANDRA-10371) Decommissioned nodes can remain in gossip

[Didier (JIRA)]

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

Didier edited comment on CASSANDRA-10371 at 12/18/15 9:46 AM:
--

Is it planned to release a fix for the 2.0.x branch for this issue ?

I have this problem in production with C* 2.0.16, is it fixed in C* 2.0.17 ?

Every n minutes we have a gossiping flood like that : 

 INFO [GossipStage:2] 2015-12-18 10:29:05,082 Gossiper.java (line 962) 
InetAddress /192.168.128.27 is now DOWN
 INFO [GossipStage:2] 2015-12-18 10:29:05,083 StorageService.java (line 1781) 
Removing tokens [100029758220565479311893935069170672938, , 
99324782484008101117663863086419168046] for /192.168.128.27
 INFO [GossipStage:2] 2015-12-18 10:40:44,253 Gossiper.java (line 962) 
InetAddress /192.168.128.27 is now DOWN
 INFO [GossipStage:2] 2015-12-18 10:40:44,254 StorageService.java (line 1781) 
Removing tokens [100029758220565479311893935069170672938, ..., 
99324782484008101117663863086419168046] for /192.168.128.27

The impacted nodes aren't in system.peers and nodetool ring/status, and they 
have been decommissioned properly from the DC.

Do you plan to release a new release 2.0.18 with a fix or do you recommand to 
upgrade to C* 2.1 or later ?

We also tried to assassinate the impacted nodes via JMX but without any success.

Best regards,

Didier


was (Author: didier.seg...@gmail.com):
Is it planned to release a fix for the 2.0.x branch for this issue ?

I have this problem in production with C* 2.0.16, is it fixed in C* 2.0.17 ?

Every n minutes we have a gossiping flood like that : 

 INFO [GossipStage:2] 2015-12-18 10:29:05,082 Gossiper.java (line 962) 
InetAddress /192.168.128.27 is now DOWN
 INFO [GossipStage:2] 2015-12-18 10:29:05,083 StorageService.java (line 1781) 
Removing tokens [100029758220565479311893935069170672938, , 
99324782484008101117663863086419168046] for /192.168.128.27
 INFO [GossipStage:2] 2015-12-18 10:40:44,253 Gossiper.java (line 962) 
InetAddress /192.168.128.27 is now DOWN
 INFO [GossipStage:2] 2015-12-18 10:40:44,254 StorageService.java (line 1781) 
Removing tokens [100029758220565479311893935069170672938, ..., 
99324782484008101117663863086419168046] for /192.168.128.27

The impacted nodes aren't in system.peers and nodetool ring/status, and they 
have been decommissioned properly from the DC.

Do you plan to release a new release 2.0.18 with a fix or do you recommand to 
upgrade to C* 2.1 or later ?

Best regards,

Didier

> Decommissioned nodes can remain in gossip
> -
>
> Key: CASSANDRA-10371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10371
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
>
> This may apply to other dead states as well.  Dead states should be expired 
> after 3 days.  In the case of decom we attach a timestamp to let the other 
> nodes know when it should be expired.  It has been observed that sometimes a 
> subset of nodes in the cluster never expire the state, and through heap 
> analysis of these nodes it is revealed that the epstate.isAlive check returns 
> true when it should return false, which would allow the state to be evicted.  
> This may have been affected by CASSANDRA-8336.



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

[jira] [Commented] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10887:
--

I can confirm that having a node both a natural endpoint and pending is bad 
(it's possible for node moving to have some of his range stay after the move, 
but in that case, these ranges shouldn't be added as pending). This would 
totally trigger CASSANDRA-10423 and is thus likely the culprit.

Not an expert in our pending range calculations though and not sure who is our 
expert there. [~blambov], you've worked on pseudo-related problems lately 
(token assignment), would you have some time to have a look? 

[~cdaw] would you have someone to turn [~sashley]'s reproduction step above 
into a dtest in parallel?

> Pending range calculator gives wrong pending ranges for moves
> -
>
> Key: CASSANDRA-10887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>Priority: Critical
>
> My understanding is the PendingRangeCalculator is meant to calculate who 
> should receive extra writes during range movements. However, it adds the 
> wrong ranges for moves. An extreme example of this can be seen in the 
> following reproduction. Create a 5 node cluster (I did this on 2.0.16 and 
> 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and 
> immediately kill -9 it. Now you see a node as down and moving in the ring. 
> Try a quorum write for a partition that is stored on that node - it will fail 
> with a timeout. Further, all CAS reads or writes fail immediately with 
> unavailable exception because they attempt to include the moving node twice. 
> This is likely to be the cause of CASSANDRA-10423.
> In my example I had this ring:
> 127.0.0.1  rack1   Up Normal  170.97 KB   20.00%  
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  124.06 KB   20.00%  
> -5534023222112865485
> 127.0.0.3  rack1   Down   Moving  108.7 KB40.00%  
> 1844674407370955160
> 127.0.0.4  rack1   Up Normal  142.58 KB   0.00%   
> 1844674407370955161
> 127.0.0.5  rack1   Up Normal  118.64 KB   20.00%  
> 5534023222112865484
> Node 3 was moving to -1844674407370955160. I added logging to print the 
> pending and natural endpoints. For ranges owned by node 3, node 3 appeared in 
> pending and natural endpoints. The blockFor is increased to 3 so we’re 
> effectively doing CL.ALL operations. This manifests as write timeouts and CAS 
> unavailables when the node is down.
> The correct pending range for this scenario is node 1 is gaining the range 
> (-1844674407370955160, 1844674407370955160). So node 1 should be added as a 
> destination for writes and CAS for this range, not node 3.



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

[jira] [Commented] (CASSANDRA-10371) Decommissioned nodes can remain in gossip

[Didier (JIRA)]

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

Didier commented on CASSANDRA-10371:


Is it planned to release a fix for the 2.0.x branch for this issue ?

I have this problem in production with C* 2.0.16, is it fixed in C* 2.0.17 ?

Every n minutes we have a gossiping flood like that : 

 INFO [GossipStage:2] 2015-12-18 10:29:05,082 Gossiper.java (line 962) 
InetAddress /192.168.128.27 is now DOWN
 INFO [GossipStage:2] 2015-12-18 10:29:05,083 StorageService.java (line 1781) 
Removing tokens [100029758220565479311893935069170672938, , 
99324782484008101117663863086419168046] for /192.168.128.27
 INFO [GossipStage:2] 2015-12-18 10:40:44,253 Gossiper.java (line 962) 
InetAddress /192.168.128.27 is now DOWN
 INFO [GossipStage:2] 2015-12-18 10:40:44,254 StorageService.java (line 1781) 
Removing tokens [100029758220565479311893935069170672938, ..., 
99324782484008101117663863086419168046] for /192.168.128.27

The impacted nodes aren't in system.peers and nodetool ring/status, and they 
have been decommissioned properly from the DC.

Do you plan to release a new release 2.0.18 with a fix or do you recommand to 
upgrade to C* 2.1 or later ?

Best regards,

Didier

> Decommissioned nodes can remain in gossip
> -
>
> Key: CASSANDRA-10371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10371
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
>
> This may apply to other dead states as well.  Dead states should be expired 
> after 3 days.  In the case of decom we attach a timestamp to let the other 
> nodes know when it should be expired.  It has been observed that sometimes a 
> subset of nodes in the cluster never expire the state, and through heap 
> analysis of these nodes it is revealed that the epstate.isAlive check returns 
> true when it should return false, which would allow the state to be evicted.  
> This may have been affected by CASSANDRA-8336.



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

[jira] [Commented] (CASSANDRA-10873) Allow sstableloader to work with 3rd party authentication providers

[Mike Adamson (JIRA)]

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

Mike Adamson commented on CASSANDRA-10873:
--

I have updated both branches with your changes.

> Allow sstableloader to work with 3rd party authentication providers
> ---
>
> Key: CASSANDRA-10873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Mike Adamson
>Assignee: Mike Adamson
> Fix For: 3.0.x
>
>
> When sstableloader was changed to use native protocol instead of thrift there 
> was a regression in that now sstableloader (BulkLoader) only takes 
> {{username}} and {{password}} as credentials so only works with the 
> {{PlainTextAuthProvider}} provided by the java driver.
> Previously it allowed 3rd party auth providers to be used, we need to add 
> back that ability by allowing the full classname of the auth provider to be 
> passed as a parameter.



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

[jira] [Commented] (CASSANDRA-10898) Migrate Compaction Strategy Node by Node

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10898:
--

I agree that it would be a nice option to have in principle. In fact, while I 
agree that compaction is probably the one option for which this is the most 
useful, I would argue that this could be useful for any setting that 
intrinsically change something local. So sstable compression parameters and 
caching parameters could good candidates for this as it could allow to test 
settings in real situation for extended periods of time but for only one or a 
couple of nodes.

The one imo big gotcha of the strategy in this blog post however is that the 
changes to a node are not persistant so a restarted node will revert back to 
the default strategy and that's really not fun. This is totally called out by 
the post btw and it's not at all a criticism of that post (which I think is a 
great solution given the current status quo), but if we're gonna offer that 
natively, I don't think we can ship with that "limitation".

Not sure what's the best solution for that though but one idea would be to 
allow a list of "exceptions" to the table parameters, that is something like:
{noformat}
ALTER TABLE myTable with compaction = {'class' : 'SizeTieredCompaction', 
'exceptions' : { 1.1.1.1 : { 'class' : 'LeveledCompactionStrategy'} } };
{noformat}
I do note that this solution has currently the one downside that if you want to 
migrate nodes one by one, you'd have to re-sent the _whole_ {{ALTER TABLE}} 
statement with the new
exception added, which, if done manually, is a tad annoying and error prone. We 
could however add some syntax like:
{noformat}
ALTER TABLE myTable with compaction['exceptions'] = compaction['exceptions'] + 
{ 1.1.1.2 : { 'class' : 'LeveledCompactionStrategy'} };
{noformat}


> Migrate Compaction Strategy Node by Node
> 
>
> Key: CASSANDRA-10898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10898
> Project: Cassandra
>  Issue Type: Wish
>  Components: Compaction, Tools
>Reporter: Andrew From
>
> It would be a great feature to be able to slowly change the compaction 
> strategy of a ColumnFamily node-by-node instead of cluster wide. Currently if 
> you change it cluster wide there's no good way to predict how long it will 
> take. Thus the process could run for days while you still need the live data, 
> but the cluster responds much more slowly due to the compaction strategy 
> migration.
> I stumbled across 
> http://blog.alteroot.org/articles/2015-04-20/change-cassandra-compaction-strategy-on-production-cluster.html
>  which gave me the idea. I was thinking this would be a nice feature to add 
> to NodeTool, provided that the strategy in the blog is sound I wouldn't mind 
> going ahead with the dev work to automate it. If not I would love to hear 
> other ideas on how to best make this happen.



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

[jira] [Commented] (CASSANDRA-10875) cqlsh fails to decode utf-8 characters for text typed columns.

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10875:
-

bq. Furthermore, cqlsh --encoding=utf8 doesn't seem to work correctly.

You're right. Although the encoding is correctly used for encoding the output, 
it's not being used to decode the input (which uses ascii by default).

The use of . Can you try the following approach?


> cqlsh fails to decode utf-8 characters for text typed columns.
> --
>
> Key: CASSANDRA-10875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10875
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Yasuharu Goto
>Assignee: Yasuharu Goto
>Priority: Minor
> Fix For: 2.1.13, 3.1
>
> Attachments: 10875-2.1.12.txt, 10875-3.1.txt
>
>
> Hi, we've found a bug that cqlsh can't handle unicode text in select 
> conditions even if it were text type.
> {noformat}
> $ ./bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.2-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> cqlsh> create table test.test(txt text primary key);
> cqlsh> insert into test.test (txt) values('日本語');
> cqlsh> select * from test.test where txt='日本語';
> 'ascii' codec can't decode byte 0xe6 in position 35: ordinal not in range(128)
> cqlsh> 
> {noformat}



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

[jira] [Comment Edited] (CASSANDRA-10875) cqlsh fails to decode utf-8 characters for text typed columns.

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-10875 at 12/18/15 12:45 PM:


bq. Furthermore, cqlsh --encoding=utf8 doesn't seem to work correctly.

You're right. Although the encoding is correctly used for encoding the output, 
it's not being used to decode the input (which uses ascii by default).

The use of {{sys.setdefaultencoding('utf-8')}} is 
[discouraged|http://blog.notdot.net/2010/07/Getting-unicode-right-in-Python]. 
Can you try the following approach?

{noformat}
diff --git a/bin/cqlsh b/bin/cqlsh
index 651420d..115cc09 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -929,7 +929,7 @@ class Shell(cmd.Cmd):
 
 def get_input_line(self, prompt=''):
 if self.tty:
-self.lastcmd = raw_input(prompt)
+self.lastcmd = raw_input(prompt).decode(self.encoding)
 line = self.lastcmd + '\n'
 else:
 self.lastcmd = self.stdin.readline()
{noformat}

If it works, please provide patches for 2.1, 2.2, 3.0 and trunk (if they don't 
merge up correctly).



was (Author: pauloricardomg):
bq. Furthermore, cqlsh --encoding=utf8 doesn't seem to work correctly.

You're right. Although the encoding is correctly used for encoding the output, 
it's not being used to decode the input (which uses ascii by default).

The use of . Can you try the following approach?


> cqlsh fails to decode utf-8 characters for text typed columns.
> --
>
> Key: CASSANDRA-10875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10875
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Yasuharu Goto
>Assignee: Yasuharu Goto
>Priority: Minor
> Fix For: 2.1.13, 3.1
>
> Attachments: 10875-2.1.12.txt, 10875-3.1.txt
>
>
> Hi, we've found a bug that cqlsh can't handle unicode text in select 
> conditions even if it were text type.
> {noformat}
> $ ./bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.2-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> cqlsh> create table test.test(txt text primary key);
> cqlsh> insert into test.test (txt) values('日本語');
> cqlsh> select * from test.test where txt='日本語';
> 'ascii' codec can't decode byte 0xe6 in position 35: ordinal not in range(128)
> cqlsh> 
> {noformat}



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

[jira] [Commented] (CASSANDRA-10875) cqlsh fails to decode utf-8 characters for text typed columns.

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10875:
-

Also, please include this in your patch:
{noformat}
diff --git a/bin/cqlsh b/bin/cqlsh
index 651420d..e852a8b 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -668,6 +668,8 @@ class Shell(cmd.Cmd):
 self.session.max_trace_wait = max_trace_wait
 if encoding is None:
 encoding = locale.getpreferredencoding()
+if encoding is None:
+  encoding = 'utf-8'
 self.encoding = encoding
 self.output_codec = codecs.lookup(encoding)
{noformat}

As apparently {{locale.getpreferredencoding()}} may [not be 
available|https://docs.python.org/2/library/locale.html#locale.getpreferredencoding]
 in some platforms.

> cqlsh fails to decode utf-8 characters for text typed columns.
> --
>
> Key: CASSANDRA-10875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10875
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Yasuharu Goto
>Assignee: Yasuharu Goto
>Priority: Minor
> Fix For: 2.1.13, 3.1
>
> Attachments: 10875-2.1.12.txt, 10875-3.1.txt
>
>
> Hi, we've found a bug that cqlsh can't handle unicode text in select 
> conditions even if it were text type.
> {noformat}
> $ ./bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.2-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> cqlsh> create table test.test(txt text primary key);
> cqlsh> insert into test.test (txt) values('日本語');
> cqlsh> select * from test.test where txt='日本語';
> 'ascii' codec can't decode byte 0xe6 in position 35: ordinal not in range(128)
> cqlsh> 
> {noformat}



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

[jira] [Updated] (CASSANDRA-10875) cqlsh fails to decode utf-8 characters for text typed columns.

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-10875:

Reproduced In: 3.0.0, 2.1.9, 3.2  (was: 2.1.9, 3.0.0, 3.2)
 Reviewer: Paulo Motta

> cqlsh fails to decode utf-8 characters for text typed columns.
> --
>
> Key: CASSANDRA-10875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10875
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Yasuharu Goto
>Assignee: Yasuharu Goto
>Priority: Minor
> Fix For: 2.1.13, 3.1
>
> Attachments: 10875-2.1.12.txt, 10875-3.1.txt
>
>
> Hi, we've found a bug that cqlsh can't handle unicode text in select 
> conditions even if it were text type.
> {noformat}
> $ ./bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.2-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> cqlsh> create table test.test(txt text primary key);
> cqlsh> insert into test.test (txt) values('日本語');
> cqlsh> select * from test.test where txt='日本語';
> 'ascii' codec can't decode byte 0xe6 in position 35: ordinal not in range(128)
> cqlsh> 
> {noformat}



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

[jira] [Commented] (CASSANDRA-10371) Decommissioned nodes can remain in gossip

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10371:
--

We will not fix this in 2.0 since it has reached end of life and there are no 
more planned releases for it.

We haven't started work on this issue yet so if is the same issue an upgrade 
wouldn't help at this stage. However it doesn't look like the exact same 
problem to me.

So you could try upgrading and if the problem persist would you be able to let 
us have some logs at TRACE level?


> Decommissioned nodes can remain in gossip
> -
>
> Key: CASSANDRA-10371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10371
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
>
> This may apply to other dead states as well.  Dead states should be expired 
> after 3 days.  In the case of decom we attach a timestamp to let the other 
> nodes know when it should be expired.  It has been observed that sometimes a 
> subset of nodes in the cluster never expire the state, and through heap 
> analysis of these nodes it is revealed that the epstate.isAlive check returns 
> true when it should return false, which would allow the state to be evicted.  
> This may have been affected by CASSANDRA-8336.



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

[jira] [Commented] (CASSANDRA-9258) Range movement causes CPU & performance impact

[Branimir Lambov (JIRA)]

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

Branimir Lambov commented on CASSANDRA-9258:


Thank you for writing the benchmark. There are a couple problems with it, 
though:
- the generated ranges cover the space up to {{maxValue * 10 + 15}}, but you 
only test tokens between 0 and {{maxValue}} which is skewing the result;
- ranges are non-overlapping except for a lot of wrap-around ones -- to better 
simulate the target usage, I'd just use a single wrap-around range;
- you could use more than one address for some of the ranges;
- make sure it follows the code conventions;
- could you post some before and after results?

A small correction on one of the changes you made on my request: 
{{addIntersection}} was meant to just do the {{for}} loop, so that it could be 
called like this:
{code}
if (ascendingTailMap.size() < descendingTailMap.size())
addIntersection(endpoints, ascendingTailMap, descendingTailMap);
else
addIntersection(endpoints, descendingTailMap, ascendingTailMap);
{code}


> Range movement causes CPU & performance impact
> --
>
> Key: CASSANDRA-9258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9258
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.1.4
>Reporter: Rick Branson
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: 0001-pending-ranges-map.patch, 
> 0001-pending-ranges-maps-for-2.2.patch, Screenshot 2015-12-16 16.11.36.png, 
> Screenshot 2015-12-16 16.11.51.png
>
>
> Observing big CPU & latency regressions when doing range movements on 
> clusters with many tens of thousands of vnodes. See CPU usage increase by 
> ~80% when a single node is being replaced.
> Top methods are:
> 1) Ljava/math/BigInteger;.compareTo in 
> Lorg/apache/cassandra/dht/ComparableObjectToken;.compareTo 
> 2) Lcom/google/common/collect/AbstractMapBasedMultimap;.wrapCollection in 
> Lcom/google/common/collect/AbstractMapBasedMultimap$AsMap$AsMapIterator;.next
> 3) Lorg/apache/cassandra/db/DecoratedKey;.compareTo in 
> Lorg/apache/cassandra/dht/Range;.contains
> Here's a sample stack from a thread dump:
> {code}
> "Thrift:50673" daemon prio=10 tid=0x7f2f20164800 nid=0x3a04af runnable 
> [0x7f2d878d]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.cassandra.dht.Range.isWrapAround(Range.java:260)
>   at org.apache.cassandra.dht.Range.contains(Range.java:51)
>   at org.apache.cassandra.dht.Range.contains(Range.java:110)
>   at 
> org.apache.cassandra.locator.TokenMetadata.pendingEndpointsFor(TokenMetadata.java:916)
>   at 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:775)
>   at 
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:541)
>   at 
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:616)
>   at 
> org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1101)
>   at 
> org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1083)
>   at 
> org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:976)
>   at 
> org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3996)
>   at 
> org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3980)
>   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
>   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
>   at 
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:205)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745){code}



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

[1/2] cassandra git commit: Eliminate the dependency on jgrapht for UDT resolution

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 50f7e0204 -> a0f59dce5


Eliminate the dependency on jgrapht for UDT resolution

patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-10653


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

Branch: refs/heads/trunk
Commit: d877ba073f60b8aba9ab70a5e163cc13b232ffdd
Parents: 2da3c9d
Author: Aleksey Yeschenko 
Authored: Mon Nov 16 22:22:51 2015 +
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 15:39:33 2015 +

--
 CHANGES.txt |   1 +
 NOTICE.txt  |   4 -
 build.xml   |   2 -
 lib/jgrapht-core-0.9.1.jar  | Bin 351208 -> 0 bytes
 lib/licenses/jgrapht-core-0.9.1.txt | 227 ---
 src/java/org/apache/cassandra/schema/Types.java |  64 --
 6 files changed, 47 insertions(+), 251 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d877ba07/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a2951a8..e6ab5dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.3
+ * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
  * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
  * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)
 Merged from 2.2:

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d877ba07/NOTICE.txt
--
diff --git a/NOTICE.txt b/NOTICE.txt
index b880183..a20994f 100644
--- a/NOTICE.txt
+++ b/NOTICE.txt
@@ -83,7 +83,3 @@ BSD 3-clause
 ASM
 (http://asm.ow2.org/)
 Copyright (c) 2000-2011 INRIA, France Telecom
-
-JGraphT
-(http://jgrapht.org)
-Copyright 2003-2015, by Barak Naveh and Contributors.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d877ba07/build.xml
--
diff --git a/build.xml b/build.xml
index 0420652..cab361f 100644
--- a/build.xml
+++ b/build.xml
@@ -392,7 +392,6 @@
   
   
   
-  
   
   
   

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

[aleksey]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: a0f59dce5bb907dc8f4d08e17ac4e511cf5f81c7
Parents: 50f7e02 d877ba0
Author: Aleksey Yeschenko 
Authored: Fri Dec 18 15:43:52 2015 +
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 15:43:52 2015 +

--
 CHANGES.txt |   1 +
 NOTICE.txt  |   4 -
 build.xml   |   2 -
 lib/jgrapht-core-0.9.1.jar  | Bin 351208 -> 0 bytes
 lib/licenses/jgrapht-core-0.9.1.txt | 227 ---
 src/java/org/apache/cassandra/schema/Types.java |  64 --
 6 files changed, 47 insertions(+), 251 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a0f59dce/CHANGES.txt
--
diff --cc CHANGES.txt
index d49a75f,e6ab5dd..6bbded8
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,25 -1,5 +1,26 @@@
 -3.0.3
 +3.2
 + * Establish bootstrap stream sessions sequentially (CASSANDRA-6992)
 + * Sort compactionhistory output by timestamp (CASSANDRA-10464)
 + * More efficient BTree removal (CASSANDRA-9991)
 + * Make tablehistograms accept the same syntax as tablestats (CASSANDRA-10149)
 + * Group pending compactions based on table (CASSANDRA-10718)
 + * Add compressor name in sstablemetadata output (CASSANDRA-9879)
 + * Fix type casting for counter columns (CASSANDRA-10824)
 + * Prevent running Cassandra as root (CASSANDRA-8142)
 + * bound maximum in-flight commit log replay mutation bytes to 64 megabytes 
(CASSANDRA-8639)
 + * Normalize all scripts (CASSANDRA-10679)
 + * Make compression ratio much more accurate (CASSANDRA-10225)
 + * Optimize building of Clustering object when only one is created 
(CASSANDRA-10409)
 + * Make index building pluggable (CASSANDRA-10681)
 + * Add sstable flush observer (CASSANDRA-10678)
 + * Improve NTS endpoints calculation (CASSANDRA-10200)
 + * Improve performance of the folderSize function (CASSANDRA-10677)
 + * Add support for type casting in selection clause (CASSANDRA-10310)
 + * Added graphing option to cassandra-stress (CASSANDRA-7918)
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +Merged from 3.0:
+  * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
   * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
   * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)
  Merged from 2.2:

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

[jira] [Updated] (CASSANDRA-10896) Fix skipping logic on upgrade tests in dtest

[Jim Witschey (JIRA)]

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

Jim Witschey updated CASSANDRA-10896:
-
Assignee: DS Test Eng  (was: Jim Witschey)

> Fix skipping logic on upgrade tests in dtest
> 
>
> Key: CASSANDRA-10896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10896
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: DS Test Eng
> Fix For: 3.0.x
>
>
> This will be a general ticket for upgrade dtests that fail because of bad 
> logic surrounding skipping tests. We need a better system in place for 
> skipping tests that are not intended to work on certain versions of 
> Cassandra; at present, we run the upgrade tests with {{SKIP=false}} because, 
> again, the built-in skipping logic is bad.
> One such test is test_v2_protocol_IN_with_tuples:
> http://cassci.datastax.com/job/storage_engine_upgrade_dtest-22_tarball-311/lastCompletedBuild/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3/test_v2_protocol_IN_with_tuples/
> This shouldn't be run on clusters that include nodes running 3.0.



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

[jira] [Commented] (CASSANDRA-10750) Minor code improvements

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10750:
--

CI looks good now, the failing {{cqlsh_copy_tests}} are because we need to 
rebase on CASSANDRA-9302, since it has been committed the dtests have been 
updated and they fail without the latest cqlsh code, totally unrelated. 

+1 for commit.

> Minor code improvements
> ---
>
> Key: CASSANDRA-10750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10750
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
>
> Went though several IDE inspections and found some places in the code that 
> could be improved. These are just minor improvements and no bug fixes (except 
> one minor "theoretical" thing).
> The [branch on github against 
> trunk|https://github.com/snazy/cassandra/tree/10750-code-opts-trunk] contains 
> a series of commits:
> * simplify Mutation.apply to remove the casts
> * "minor code improvements" just replaces some expressions that are 
> effectively constant
> * remove unused assignments (probably just cosmetic)
> * collapse identical if-branches (probably just cosmetic)
> * empty array constants
> * fix printf usage (could potentially raise an exception in printf)
> * replace tail-recursion in some critical sections (as the JVM cannot 
> optimize that AFAIK)
> * remove methods identical to their super methods (probably just cosmetic)
> [cassci results 
> here|http://cassci.datastax.com/view/Dev/view/snazy/search/?q=snazy-10750-]



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

[jira] [Commented] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10252:
-

Thanks for checking in [~firstprayer]. Actually this functionality is 
implemented by the new options introduced in CASSANDRA-9303 using exactly the 
approach you described.

For this reason I will close this ticket and add a link to the new ticket which 
should be integrated soon.

> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
>  Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in 
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property 
> for both to prevent issues like CASSANDRA-8970.



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

[jira] [Resolved] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc

[Paulo Motta (JIRA)]

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

Paulo Motta resolved CASSANDRA-10252.
-
Resolution: Duplicate

> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
>  Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in 
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property 
> for both to prevent issues like CASSANDRA-8970.



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

[jira] [Updated] (CASSANDRA-10854) cqlsh COPY FROM csv having line with more than one consecutive ',' delimiter is throwing 'list index out of range'

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10854:
--
Priority: Minor  (was: Major)

> cqlsh COPY FROM csv having line with more than one consecutive  ',' delimiter 
>  is throwing 'list index out of range'
> 
>
> Key: CASSANDRA-10854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10854
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: cqlsh 5.0.1 | Cassandra 2.1.11.969 | DSE 4.8.3 | CQL 
> spec 3.2.1 
>Reporter: Puspendu Banerjee
>Priority: Minor
>
> cqlsh COPY FROM csv having line with more than one consecutive  ',' delimiter 
>  is throwing 'list index out of range'
> Steps to re-produce:
> CREATE TABLE tracks_by_album (
>   album_title TEXT,
>   album_year INT,
>   performer TEXT STATIC,
>   album_genre TEXT STATIC,
>   track_number INT,
>   track_title TEXT,
>   PRIMARY KEY ((album_title, album_year), track_number)
> );
> Create a file: tracks_by_album.csv having following 2 lines :
> album,year,performer,genre,number,title
> a,2015,b c d,e f g,,
> cqlsh> COPY music.tracks_by_album
>  (album_title, album_year, performer, album_genre, track_number, 
> track_title)
> FROM '~/tracks_by_album.csv'
> WITH HEADER = 'true';
> Error :
> Starting copy of music.tracks_by_album with columns ['album_title', 
> 'album_year', 'performer', 'album_genre', 'track_number', 'track_title'].
> list index out of range
> Aborting import at record #1. Previously inserted records are still present, 
> and some records after that may be present as well.



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

[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches

[Taiyuan Zhang (JIRA)]

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

Taiyuan Zhang commented on CASSANDRA-10876:
---

I would like to work on this. Just checking out related issues, in 8825 there 
suppose to be a discussion around the impact of batch size under different 
situation, but there wasn't. So did we reach a conclusion that the size of a 
single partition isn't a problem?

> Alter behavior of batch WARN and fail on single partition batches
> -
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Priority: Minor
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]



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

[jira] [Commented] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc

[Taiyuan Zhang (JIRA)]

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

Taiyuan Zhang commented on CASSANDRA-10252:
---

I'm half way through this. A couple of thoughts:

1. The current implementation is to use regular expression to match the time 
string against ALL possible CQL built-in datetime formats. I think this is very 
valuable and should be kept
2. Therefore, my idea of implementing this is, first try to parse using the 
current regular expression approach; if fail, then try to parse using 
user-specified format, coming either from explicit command or cqlshrc

Another thing I want to be clear about is: in this issue it says fix version: 
2.1.x. Does this mean I should do the modification on just the trunk branch, or 
just the 2.1.x branch, or all branches?

> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
>  Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in 
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property 
> for both to prevent issues like CASSANDRA-8970.



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

[jira] [Commented] (CASSANDRA-10846) sstableofflinerelevel_test is failing

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-10846:
--

See [this pull request|https://github.com/riptano/cassandra-dtest/pull/715] for 
a tentative fix.

> sstableofflinerelevel_test is failing
> -
>
> Key: CASSANDRA-10846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10846
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Testing, Tools
>Reporter: Philip Thompson
> Fix For: 2.2.x
>
>
> {{offline_tools_test.TestOfflineTools.sstableofflinerelevel_test}} is failing 
> consistently on 2.2-head on cassci. 2.1 and 3.0 appear unaffected.
> If you see here: 
> http://cassci.datastax.com/job/cassandra-2.2_dtest/439/testReport/ , it 
> appears that after running sstableofflinerelevel, all twenty sstables are 
> promoted to level 1, while we are expecting at least some to make it to L2. 
> I am unable to reproduce this locally on OSX



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

cassandra git commit: Eliminate the dependency on jgrapht for UDT resolution

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 2da3c9db1 -> d877ba073


Eliminate the dependency on jgrapht for UDT resolution

patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-10653


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

Branch: refs/heads/cassandra-3.0
Commit: d877ba073f60b8aba9ab70a5e163cc13b232ffdd
Parents: 2da3c9d
Author: Aleksey Yeschenko 
Authored: Mon Nov 16 22:22:51 2015 +
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 15:39:33 2015 +

--
 CHANGES.txt |   1 +
 NOTICE.txt  |   4 -
 build.xml   |   2 -
 lib/jgrapht-core-0.9.1.jar  | Bin 351208 -> 0 bytes
 lib/licenses/jgrapht-core-0.9.1.txt | 227 ---
 src/java/org/apache/cassandra/schema/Types.java |  64 --
 6 files changed, 47 insertions(+), 251 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d877ba07/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a2951a8..e6ab5dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.3
+ * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
  * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
  * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)
 Merged from 2.2:

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d877ba07/NOTICE.txt
--
diff --git a/NOTICE.txt b/NOTICE.txt
index b880183..a20994f 100644
--- a/NOTICE.txt
+++ b/NOTICE.txt
@@ -83,7 +83,3 @@ BSD 3-clause
 ASM
 (http://asm.ow2.org/)
 Copyright (c) 2000-2011 INRIA, France Telecom
-
-JGraphT
-(http://jgrapht.org)
-Copyright 2003-2015, by Barak Naveh and Contributors.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d877ba07/build.xml
--
diff --git a/build.xml b/build.xml
index 0420652..cab361f 100644
--- a/build.xml
+++ b/build.xml
@@ -392,7 +392,6 @@
   
   
   
-  
   
   
   

[jira] [Commented] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc

[Taiyuan Zhang (JIRA)]

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

Taiyuan Zhang commented on CASSANDRA-10252:
---

Thanks for the notice :)

> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
>  Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in 
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property 
> for both to prevent issues like CASSANDRA-8970.



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

[jira] [Commented] (CASSANDRA-9472) Reintroduce off heap memtables

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9472:
-

CI is good provided [this dtest pull 
request|https://github.com/riptano/cassandra-dtest/pull/715] is applied.

I move this to patch available. I'm +1 with [~benedict]'s code, he can cross 
review the new code and the points raised above when he's back.

> Reintroduce off heap memtables
> --
>
> Key: CASSANDRA-9472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9472
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Assignee: Stefania
> Fix For: 3.2
>
>
> CASSANDRA-8099 removes off heap memtables. We should reintroduce them ASAP.



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

[jira] [Commented] (CASSANDRA-9303) Match cassandra-loader options in COPY FROM

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-9303:


Looking very good, I tested the new config options and the ingest rate is now 
working like a charm. Some follow-up comments below:

bq. Done, I cleaned up the options a bit as well and removed the helper methods 
in the main cqlsh files.

* I was initially thinking that while \[copy\] is a global section, 
\[copy-from*\] and \[copy-to*\] are exclusive sections for these commands, so 
for example if you define INGESTRATE by mistake in the \[copy-to\] section it's 
not picked up by a copy-from execution.
* Can you also add some examples to {{conf/cqlshrc.sample}} ? And maybe also 
update the cql protocol version there which is quite old.
* Also in the {{Reading options from /home/paulo/.cqlsh/cqlshrc}} message, 
maybe print which options are being read to improve clarity (don't worry if not 
straightforward)

bq. If a file from a previous execution exists it will be ranamed to 
.MMDD_HHMMSS.

Cool! Since it's an edge-case I guess we can omit in the help and print a 
message instead in case it happens.

bq. So, I converted SKIPCOLS to a COPY FROM option and changed its semantic to 
just skip columns that exist in the file.

Sounds good, it just seems the skipped columns is still being printed on the 
message {{Starting copy of keyspace1.standard1 with columns \['key', 'C0', 
'C1', 'C2', 'C3', 'C4'\].}} (you fixed before, but it came back somehow).

Minor code style nits:

* Move csv_dialect_defaults from cqlsh.py to copyutil.py
* Move exclusive skip_columns field from CopyTask to ImportTask
* csv_options are a bit misleading since they are not exclusive csv-related 
options, can we maybe rename the tuple CopyOptions(csv, dialect, unrecognized) 
to Options(copy, dialect, unrecognized)?

We're getting there, I guess we'll be done by next round. :)

> Match cassandra-loader options in COPY FROM
> ---
>
> Key: CASSANDRA-9303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9303
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Jonathan Ellis
>Assignee: Stefania
>Priority: Critical
> Fix For: 2.1.x
>
>
> https://github.com/brianmhess/cassandra-loader added a bunch of options to 
> handle real world requirements, we should match those.



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

[jira] [Commented] (CASSANDRA-6696) Partition sstables by token range

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-6696:


pushed the flush writers fix and when re-running the tests i noticed a problem 
with ScrubTest and fixed that. Also fixed dtest multi data directory failure I 
had missed.

Test runs:
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-6696-11-testall
http://cassci.datastax.com/view/Dev/view/krummas/job/6696_dtest

> Partition sstables by token range
> -
>
> Key: CASSANDRA-6696
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6696
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Marcus Eriksson
>  Labels: compaction, correctness, dense-storage, 
> jbod-aware-compaction, performance
> Fix For: 3.2
>
>
> In JBOD, when someone gets a bad drive, the bad drive is replaced with a new 
> empty one and repair is run. 
> This can cause deleted data to come back in some cases. Also this is true for 
> corrupt stables in which we delete the corrupt stable and run repair. 
> Here is an example:
> Say we have 3 nodes A,B and C and RF=3 and GC grace=10days. 
> row=sankalp col=sankalp is written 20 days back and successfully went to all 
> three nodes. 
> Then a delete/tombstone was written successfully for the same row column 15 
> days back. 
> Since this tombstone is more than gc grace, it got compacted in Nodes A and B 
> since it got compacted with the actual data. So there is no trace of this row 
> column in node A and B.
> Now in node C, say the original data is in drive1 and tombstone is in drive2. 
> Compaction has not yet reclaimed the data and tombstone.  
> Drive2 becomes corrupt and was replaced with new empty drive. 
> Due to the replacement, the tombstone in now gone and row=sankalp col=sankalp 
> has come back to life. 
> Now after replacing the drive we run repair. This data will be propagated to 
> all nodes. 
> Note: This is still a problem even if we run repair every gc grace. 
>  



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

[jira] [Commented] (CASSANDRA-10653) Remove dependency on jgrapht for UDT resolution

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10653:
---

Done 
[here|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10653-testall/lastCompletedBuild/testReport/]
 and 
[here|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-10653-dtest/lastCompletedBuild/testReport/].

Committed as 
[d877ba073f60b8aba9ab70a5e163cc13b232ffdd|https://github.com/apache/cassandra/commit/d877ba073f60b8aba9ab70a5e163cc13b232ffdd]
 to 3.0 and merged with trunk. Thanks.

> Remove dependency on jgrapht for UDT resolution
> ---
>
> Key: CASSANDRA-10653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10653
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 3.0.x
>
>
> Now that the java-driver no longer pulls it as a dependency, it is silly to 
> pull a whole library for resolving UDTs dependencies.
> Should rewrite the resolution code without jgrapht (maybe reuse whatever code 
> java-driver ended up writing).



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

[jira] [Assigned] (CASSANDRA-10905) secondary_indexes_test.py:TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query flaps on 3.0+

[DS Test Eng (JIRA)]

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

DS Test Eng reassigned CASSANDRA-10905:
---

Assignee: DS Test Eng

> secondary_indexes_test.py:TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query
>  flaps on 3.0+
> --
>
> Key: CASSANDRA-10905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10905
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: DS Test Eng
> Fix For: 3.0.x
>
>
> This test flaps when it expects to find 1 of each of several trace events, 
> but doesn't find some of them. I noticed it on 3.0:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/438/testReport/junit/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query/history/
> But I've also seen it on trunk, so it would appear it hasn't been fixed:
> http://cassci.datastax.com/job/trunk_dtest/831/testReport/junit/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query/



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

[jira] [Commented] (CASSANDRA-10905) secondary_indexes_test.py:TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query flaps on 3.0+

[Jim Witschey (JIRA)]

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

Jim Witschey commented on CASSANDRA-10905:
--

This seems to be a likely test issue, so I've assigned the DataStax Test 
Engineering team account.

> secondary_indexes_test.py:TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query
>  flaps on 3.0+
> --
>
> Key: CASSANDRA-10905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10905
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: DS Test Eng
> Fix For: 3.0.x
>
>
> This test flaps when it expects to find 1 of each of several trace events, 
> but doesn't find some of them. I noticed it on 3.0:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/438/testReport/junit/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query/history/
> But I've also seen it on trunk, so it would appear it hasn't been fixed:
> http://cassci.datastax.com/job/trunk_dtest/831/testReport/junit/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query/



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

[jira] [Resolved] (CASSANDRA-10879) HSHA dtest for closing connections almost always fails on CASSCI developer branches

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne resolved CASSANDRA-10879.
--
Resolution: Duplicate

Unless I'm mistaken, that's a duplicate of CASSANDRA-10863.

> HSHA dtest for closing connections almost always fails on CASSCI developer 
> branches
> ---
>
> Key: CASSANDRA-10879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10879
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Branimir Lambov
>Priority: Critical
>
> The test consistently succeeds on 2.1/2.2 branches, but has been failing 
> almost every time on developer ones for quite a while, for example [9258 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-dikang85-9258-dtest/lastCompletedBuild/testReport/],
>  [10817 
> dtest|http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-10817-dtest/],
>  [10059 (committed) 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-10059-dtest/lastCompletedBuild/testReport/],
>  [unchanged 2.2 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-cassandra-2.2-dtest/lastCompletedBuild/testReport/]
>  and many others. The failures cannot be genuine if the same code committed 
> to the main branch no longer fails the test.
> This is making it hard to identify genuine failures and blocking 
> CASSANDRA-9669 in particular.



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

[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10733:

Reviewer: Tyler Hobbs

> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
>  Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
> Attachments: CASSANDRA-2.2-10733-CQLSH-Auto.patch, 
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some 
> inconsistent behaviour when completing part of the statement and hitting the 
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}} 
> works correctly. We see a list of all tables (or functions, types) in the 
> current keyspace plus a list of all available keyspaces followed by a full 
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE 
>  minutedata   system_distributed.
> ;rawtickdatabylp  system_traces.
>   rawtickdatabysymbol  tickdata
> daydata  system.  
> fxaggr.  system_auth. 
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in 
> this case, only 1, called 'average') but does not display a list of available 
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate 
>  ;  average  fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type 
> .'}} works correctly. We see a list of all tables (or types) in the 
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata  rawtickdatabylp  tickdata
> minutedata   rawtickdatabysymbol  
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate 
> .'}} works inconsistently. In a keyspace with 2 functions, both 
> beginning with the letters 'avg', if I type {{'desc function '}} 
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg 
> '}} and will not display the matching functions. If I type {{'desc function 
> .'}} (note the trailing full stop) and hit tab, auto-complete will 
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal  avgstate  
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns  
> {{'desc aggregate  '}}  (it adds a space) and does not show me the 
> list of available aggregates. If I type {{'desc aggregate .'}} 
> (note the trailing full stop) and hit tab, auto-complete will work correctly.



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

[jira] [Resolved] (CASSANDRA-10723) Rewrite INITCOND after renames and alters of UDT fields

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko resolved CASSANDRA-10723.
---
   Resolution: Later
Fix Version/s: (was: 3.x)

> Rewrite INITCOND after renames and alters of UDT fields
> ---
>
> Key: CASSANDRA-10723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10723
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
>
> (Follow-up to CASSANDRA-10721)
> In order to re-write an INITCOND value when a UDT is changed (component 
> renamed or type altered), we will have to check for broken aggregates first 
> (as we do not know why _exactly_ these are broken; CASSANDRA-10721 added 
> {{Function.isBroken()}}).
> If one of the affected aggregates is broken, the request *must fail*.
> If none of the affected aggregates is broken, we can re-write the binary 
> representation of the INITCOND and push schema migrations for these 
> aggregates.
> Still unclear, if the user needs permissions on both the UDT _and_ the 
> affected UDAs for that.
> Further, the UDT change and all UDA changes should be migrated in a single 
> mutation, which feels to be the biggest change. This is not a strict 
> requirement but would keep that schema change atomic.



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

[jira] [Resolved] (CASSANDRA-10712) Performance dramatically impacted by using client SSL

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko resolved CASSANDRA-10712.
---
   Resolution: Duplicate
Reproduced In: 3.0.0, 2.1.11, 2.0.17  (was: 2.0.17, 2.1.11, 3.0.0)

> Performance dramatically impacted by using client SSL
> -
>
> Key: CASSANDRA-10712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10712
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Andy Tolbert
> Attachments: bench-graph.png, cpu_metrics.png, ssl-bench.tgz
>
>
> Throughput latency & throughput achieved via cassandra-stress is dramatically 
> impacted when using SSL (about 5-6x).
> !bench-graph.png!
> I haven't done much analysis of this yet, but one observation is that I do 
> notice a dramatic increase in context switches while running with SSL on the 
> server side.  In the charts below, the left-most data in a chart represents 
> running without SSL, and the right-most data represents running with SSL.  
> You'll observe that on the C* node that while the CPU utilization is down 
> when running stress with SSL, the context switches are higher.
> !cpu_metrics.png!
> Attached is [^ssl-bench.tgz] that includes output for each run, the 
> parameters used and an html file that is the output of running stress with 
> [CASSANDRA-7918].
> If you need some ready made keystore / truststore files to work with, some 
> can be found 
> [here|https://github.com/datastax/java-driver/tree/2.1/driver-core/src/test/resources].



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

[jira] [Updated] (CASSANDRA-10657) Re-enable/improve value skipping

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10657:
--
Fix Version/s: (was: 3.2)
   3.x

> Re-enable/improve value skipping
> 
>
> Key: CASSANDRA-10657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10657
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
>
> This is a followup to CASSANDRA-10655, to re-enable the optimization of 
> skipping values for the columns that are not requested by users in a CQL 
> query. See CASSANDRA-10655 for why it was disabled, the goal here is to 
> re-enable it minus the bugs.



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

[jira] [Commented] (CASSANDRA-9923) stress write and counter_write hangs

[T Jake Luciani (JIRA)]

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

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

.bq WDYT

You can't change the -Xmx once the process starts

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>Priority: Minor
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0
> total,   4996565,  45,  45,  45, 0.9, 0.7, 0.9,   

[jira] [Resolved] (CASSANDRA-10878) Unable to read obsolete message version 1; The earliest version supported is 2.0.0

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie resolved CASSANDRA-10878.
-
Resolution: Duplicate

>  Unable to read obsolete message version 1; The earliest version supported is 
> 2.0.0
> ---
>
> Key: CASSANDRA-10878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10878
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: esala wona
>  Labels: starter
>
> I used cassandra version 2.1.2, but I get some error about that:
>  error message 
> ERROR [Thread-83674153] 2015-12-15 10:54:42,980 CassandraDaemon.java:153 - 
> Exception in thread Thread[Thread-83674153,5,main]
> java.lang.UnsupportedOperationException: Unable to read obsolete message 
> version 1; The earliest version supported is 2.0.0
>   at 
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
>  ~[apache-cassandra-2.1.2.jar:2.1.2]
> = end 
> == nodetool information 
> ces@ICESSuse3631:/opt/ces/cassandra/bin> ./nodetool gossipinfo
> /192.168.0.1
>   generation:1450148624
>   heartbeat:299069
>   SCHEMA:194168a3-f66e-3ab9-b811-4f7a7c3b89ca
>   STATUS:NORMAL,-111061256928956495
>   RELEASE_VERSION:2.1.2
>   RACK:rack1
>   DC:datacenter1
>   RPC_ADDRESS:192.144.36.32
>   HOST_ID:11f793f0-999b-4ba8-8bdd-0f0c73ae2e23
>   NET_VERSION:8
>   SEVERITY:0.0
>   LOAD:1.3757700946E10
> /192.168.0.2
>   generation:1450149068
>   heartbeat:297714
>   SCHEMA:194168a3-f66e-3ab9-b811-4f7a7c3b89ca
>   RELEASE_VERSION:2.1.2
>   STATUS:NORMAL,-1108435478195556849
>   RACK:rack1
>   DC:datacenter1
>   RPC_ADDRESS:192.144.36.33
>   HOST_ID:0f1a2dab-1d39-4419-bb68-03386c1a79df
>   NET_VERSION:8
>   SEVERITY:7.611548900604248
>   LOAD:8.295301191E9
> end=



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

[jira] [Assigned] (CASSANDRA-10903) AssertionError while reading sstable when querying static column

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne reassigned CASSANDRA-10903:


Assignee: Sylvain Lebresne

> AssertionError while reading sstable when querying static column
> 
>
> Key: CASSANDRA-10903
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10903
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Sylvain Lebresne
>
> I'm able to consistently reproduce the following error:
> {noformat}
> 1  WARN [SharedPool-Worker-1] 2015-12-17 17:37:00,196  
> AbstractTracingAwareExecutorService.java (line 169) Uncaught exception on 
> thread Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:463)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:268)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:158)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:352)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:369)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:189)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:158)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:426)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:286)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) 
> ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:298)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:288) 
> ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1692)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2346)
>  ~[cassandra-all-3.0.0.740.jar:3.0.0.740]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_45]
> at 
> 

[jira] [Updated] (CASSANDRA-10850) v4 spec has tons of grammatical mistakes

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10850:
-
Reviewer: Sylvain Lebresne

> v4 spec has tons of grammatical mistakes
> 
>
> Key: CASSANDRA-10850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10850
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation and Website
>Reporter: Sandeep Tamhankar
> Fix For: 3.0.2
>
> Attachments: v4-protocol.patch
>
>
> https://github.com/apache/cassandra/blob/cassandra-3.0/doc/native_protocol_v4.spec
> I notice the following in the first section of the spec and then gave up:
> "The list of allowed opcode is defined Section 2.3" => "The list of allowed 
> opcode*s* is defined in Section 2.3"
> "the details of each corresponding message is described Section 4" => "the 
> details of each corresponding message are described in Section 4" since the 
> subject is details, not message.
> "Requests are those frame sent by" => "Requests are those frame*s* sent by"
> I think someone should go through the whole spec and fix all the mistakes 
> rather than me pointing out the ones I notice piece-meal. I found the grammar 
> errors to be rather distracting.



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

[jira] [Updated] (CASSANDRA-9923) stress write and counter_write hangs

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-9923:
--
Component/s: Tools

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>Priority: Minor
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0
> total,   4996565,  45,  45,  45, 0.9, 0.7, 0.9,   
>   1.5,84.7,   218.3,  551.5,  0.11872,  0,  1, 248, 248, 

[jira] [Updated] (CASSANDRA-9923) stress write and counter_write hangs

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-9923:
--
Priority: Minor  (was: Major)

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>Priority: Minor
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0
> total,   4996565,  45,  45,  45, 0.9, 0.7, 0.9,   
>   1.5,84.7,   218.3,  551.5,  0.11872,  0,  1, 

[jira] [Updated] (CASSANDRA-10714) tcp retransmission issue seen in cassandra cluster

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10714:
--
Issue Type: Bug  (was: Improvement)

> tcp retransmission issue seen in cassandra cluster
> --
>
> Key: CASSANDRA-10714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10714
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Liu
>
> I have been seen tcp package retransmission issue in various stacks in our 
> environment. ( AWS with no VPC). I'm currently using hsha rpc server type on 
> cassandra 2.1.6 version. The information captured by wireshark shows that the 
> retransmission happened both between client-to-server and server-to-server. 
> Even within a cluster that doesn't have any client traffic, sporadic 
> retransmission still happens.
> It's pretty easy to reproduce this issue by watching "netstat -s | grep 
> retrans". 



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

[jira] [Commented] (CASSANDRA-9923) stress write and counter_write hangs

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-9923:
-

bq. Mainly stress is running low on heap.
Makes sense to me.

Maybe just add a "generic" {{-Jfoo}} option to pass JVM arguments to stress. 
WDYT?

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>Priority: Minor
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0

[jira] [Comment Edited] (CASSANDRA-9923) stress write and counter_write hangs

[T Jake Luciani (JIRA)]

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

T Jake Luciani edited comment on CASSANDRA-9923 at 12/18/15 6:16 PM:
-

bq. WDYT

You can't change the -Xmx once the process starts


was (Author: tjake):
.bq WDYT

You can't change the -Xmx once the process starts

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>Priority: Minor
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,   

cassandra git commit: Minor code improvements

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/trunk a0f59dce5 -> 0f5e78078


Minor code improvements

patch by Robert Stupp; reviewed by Stefania for CASSANDRA-10750


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

Branch: refs/heads/trunk
Commit: 0f5e780781ce3f0cb3732515dacc7e467571a7c9
Parents: a0f59dc
Author: Robert Stupp 
Authored: Fri Dec 18 09:14:57 2015 -0800
Committer: Robert Stupp 
Committed: Fri Dec 18 09:14:57 2015 -0800

--
 .../cassandra/auth/PasswordAuthenticator.java   |   4 +-
 .../org/apache/cassandra/cql3/CQL3Type.java |   5 -
 .../restrictions/PrimaryKeyRestrictionSet.java  |  12 --
 .../cassandra/cql3/selection/FieldSelector.java |   5 -
 .../cql3/statements/BatchStatement.java |  13 +-
 .../cql3/statements/ModificationStatement.java  |   9 +-
 .../apache/cassandra/db/CounterMutation.java|   7 +-
 src/java/org/apache/cassandra/db/IMutation.java |   2 +-
 .../org/apache/cassandra/db/LegacyLayout.java   |  18 +--
 src/java/org/apache/cassandra/db/Mutation.java  |   7 +-
 .../cassandra/db/UnfilteredDeserializer.java|   2 +-
 .../db/commitlog/CommitLogReplayer.java |   2 +-
 .../db/compaction/CompactionController.java |   5 +-
 .../UnfilteredPartitionIterators.java   |   6 -
 .../apache/cassandra/db/transform/Stack.java|   6 +-
 src/java/org/apache/cassandra/dht/Range.java|   8 +-
 .../internal/composites/CompositesSearcher.java | 122 +--
 .../io/sstable/SSTableSimpleIterator.java   |  33 ++---
 .../io/sstable/format/SSTableReader.java|   2 +-
 .../io/util/FileSegmentInputStream.java |   6 -
 .../io/util/RebufferingInputStream.java |  12 --
 .../locator/NetworkTopologyStrategy.java|   6 -
 .../apache/cassandra/metrics/TableMetrics.java  |   5 +-
 .../cassandra/serializers/AsciiSerializer.java  |   2 +-
 .../cassandra/serializers/UTF8Serializer.java   |   4 +-
 .../apache/cassandra/service/CacheService.java  |   6 +-
 .../apache/cassandra/service/StorageProxy.java  |   2 +-
 .../apache/cassandra/streaming/StreamPlan.java  |   5 +-
 .../apache/cassandra/tools/nodetool/Ring.java   |   4 +-
 .../apache/cassandra/tools/nodetool/Status.java |   4 +-
 .../cassandra/utils/HistogramBuilder.java   |   7 +-
 .../apache/cassandra/utils/IntervalTree.java|  23 ++--
 .../apache/cassandra/utils/MergeIterator.java   |   3 -
 .../org/apache/cassandra/utils/MerkleTree.java  |  84 -
 .../cassandra/utils/btree/TreeCursor.java   |   3 +-
 .../org/apache/cassandra/stress/Operation.java  |  10 +-
 .../operations/predefined/CqlOperation.java |   9 +-
 .../predefined/PredefinedOperation.java |   3 +-
 .../operations/userdefined/SchemaStatement.java |   9 --
 .../userdefined/ValidatingSchemaQuery.java  |  17 +--
 .../cassandra/stress/util/TimingInterval.java   |   3 +-
 41 files changed, 223 insertions(+), 272 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0f5e7807/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
--
diff --git a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java 
b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
index 0482199..3bee0e3 100644
--- a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
+++ b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
@@ -213,10 +213,10 @@ public class PasswordAuthenticator implements 
IAuthenticator
 }
 }
 
-if (user == null)
-throw new AuthenticationException("Authentication ID must not 
be null");
 if (pass == null)
 throw new AuthenticationException("Password must not be null");
+if (user == null)
+throw new AuthenticationException("Authentication ID must not 
be null");
 
 username = new String(user, StandardCharsets.UTF_8);
 password = new String(pass, StandardCharsets.UTF_8);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0f5e7807/src/java/org/apache/cassandra/cql3/CQL3Type.java
--
diff --git a/src/java/org/apache/cassandra/cql3/CQL3Type.java 
b/src/java/org/apache/cassandra/cql3/CQL3Type.java
index 4e67346..989fcf8 100644
--- a/src/java/org/apache/cassandra/cql3/CQL3Type.java
+++ b/src/java/org/apache/cassandra/cql3/CQL3Type.java
@@ -815,11 +815,6 @@ public interface CQL3Type
 return true;
 }
 
-public boolean isCollection()
- 

[jira] [Commented] (CASSANDRA-10784) ZonedDateTime as new CQL data type

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10784:


I'm -1 on including a type like this.

There is no way to just compare by the UTC time in a partition key; we use the 
bytes of the full value, so it wouldn't resolve correctly. Because we can't 
drop the zone from the partition key, a query would also require the time zone 
to be incorporated, and we the two values wouldn't be on the same node, so they 
would both exist. This behavior would preclude ZonedDateTime from being 
included in Cassandra.

There are other ways to get the desired behavior. The best would be to split 
the zone out into a new column; it would need to be a static column for the 
primary key, and a regular column for the clustering key. A UDT would get you 
the same behavior as is described in the previous paragraph. And if you wanted 
to add a new data type for use with clustering columns, you can implement the 
{{AbstractType}} and deploy it in a jar alongside your Cassandra.

> ZonedDateTime as new CQL data type
> --
>
> Key: CASSANDRA-10784
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10784
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL, Documentation and Website
>Reporter: ZhaoYang
>Assignee: ZhaoYang
> Fix For: 3.x
>
>
> For globalization, ZonedDateTime is very important. Timestamp is not enough 
> and Zone info should be included. So Cassandra should support ZonedDateTime 
> as native data type and ordering using ZonedDateTime's utc value.



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

[jira] [Updated] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10887:
-
Assignee: Branimir Lambov

> Pending range calculator gives wrong pending ranges for moves
> -
>
> Key: CASSANDRA-10887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>Assignee: Branimir Lambov
>Priority: Critical
>
> My understanding is the PendingRangeCalculator is meant to calculate who 
> should receive extra writes during range movements. However, it adds the 
> wrong ranges for moves. An extreme example of this can be seen in the 
> following reproduction. Create a 5 node cluster (I did this on 2.0.16 and 
> 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and 
> immediately kill -9 it. Now you see a node as down and moving in the ring. 
> Try a quorum write for a partition that is stored on that node - it will fail 
> with a timeout. Further, all CAS reads or writes fail immediately with 
> unavailable exception because they attempt to include the moving node twice. 
> This is likely to be the cause of CASSANDRA-10423.
> In my example I had this ring:
> 127.0.0.1  rack1   Up Normal  170.97 KB   20.00%  
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  124.06 KB   20.00%  
> -5534023222112865485
> 127.0.0.3  rack1   Down   Moving  108.7 KB40.00%  
> 1844674407370955160
> 127.0.0.4  rack1   Up Normal  142.58 KB   0.00%   
> 1844674407370955161
> 127.0.0.5  rack1   Up Normal  118.64 KB   20.00%  
> 5534023222112865484
> Node 3 was moving to -1844674407370955160. I added logging to print the 
> pending and natural endpoints. For ranges owned by node 3, node 3 appeared in 
> pending and natural endpoints. The blockFor is increased to 3 so we’re 
> effectively doing CL.ALL operations. This manifests as write timeouts and CAS 
> unavailables when the node is down.
> The correct pending range for this scenario is node 1 is gaining the range 
> (-1844674407370955160, 1844674407370955160). So node 1 should be added as a 
> destination for writes and CAS for this range, not node 3.



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

[jira] [Reopened] (CASSANDRA-10879) HSHA dtest for closing connections almost always fails on CASSCI developer branches

[Branimir Lambov (JIRA)]

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

Branimir Lambov reopened CASSANDRA-10879:
-

No, this is a different and IMO more serious issue. The test does not flap or 
fail at all for 2.1 or 2.2, unless you are testing a developer branch, where it 
usually fails.

This looks like a problem of the infrastructure. A fix for 10863 _could_ fix 
this, but most probably won't.

> HSHA dtest for closing connections almost always fails on CASSCI developer 
> branches
> ---
>
> Key: CASSANDRA-10879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10879
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Branimir Lambov
>Priority: Critical
>
> The test consistently succeeds on 2.1/2.2 branches, but has been failing 
> almost every time on developer ones for quite a while, for example [9258 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-dikang85-9258-dtest/lastCompletedBuild/testReport/],
>  [10817 
> dtest|http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-10817-dtest/],
>  [10059 (committed) 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-10059-dtest/lastCompletedBuild/testReport/],
>  [unchanged 2.2 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-cassandra-2.2-dtest/lastCompletedBuild/testReport/]
>  and many others. The failures cannot be genuine if the same code committed 
> to the main branch no longer fails the test.
> This is making it hard to identify genuine failures and blocking 
> CASSANDRA-9669 in particular.



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

[jira] [Commented] (CASSANDRA-10879) HSHA dtest for closing connections almost always fails on CASSCI developer branches

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10879:


I'm running the fix that I have in CASSANDRA-10863 through 
[2.1|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10863-2.1-dtest/]
 and 
[2.2|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10863-2.2-dtest/]
 now.

> HSHA dtest for closing connections almost always fails on CASSCI developer 
> branches
> ---
>
> Key: CASSANDRA-10879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10879
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Branimir Lambov
>Assignee: Carl Yeksigian
>Priority: Critical
>
> The test consistently succeeds on 2.1/2.2 branches, but has been failing 
> almost every time on developer ones for quite a while, for example [9258 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-dikang85-9258-dtest/lastCompletedBuild/testReport/],
>  [10817 
> dtest|http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-10817-dtest/],
>  [10059 (committed) 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-10059-dtest/lastCompletedBuild/testReport/],
>  [unchanged 2.2 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-cassandra-2.2-dtest/lastCompletedBuild/testReport/]
>  and many others. The failures cannot be genuine if the same code committed 
> to the main branch no longer fails the test.
> This is making it hard to identify genuine failures and blocking 
> CASSANDRA-9669 in particular.



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

[jira] [Updated] (CASSANDRA-10829) cleanup + repair generates a lot of logs

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10829:

Reviewer: Carl Yeksigian

> cleanup + repair generates a lot of logs
> 
>
> Key: CASSANDRA-10829
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10829
> Project: Cassandra
>  Issue Type: Bug
> Environment: 5 nodes on Cassandra 2.1.11 (on Debian)
>Reporter: Fabien Rousseau
>Assignee: Marcus Eriksson
> Fix For: 2.1.x
>
>
> One of our node generates a lot of cassandra logs (int the 10 MB/s) and CPU 
> usage has increased (by a factor 2-3).
> This was most probably triggered by a "nodetool snapshot" while a cleanup was 
> already running on this node.
> An example of those logs:
> 2015-12-08 09:15:17,794 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to 
> capture released readers [...]
> 2015-12-08 09:15:17,794 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to 
> capture all readers [...]
> 2015-12-08 09:15:17,795 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to 
> capture released readers [...]
> 2015-12-08 09:15:17,795 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to 
> capture all readers [...]
> (I removed SSTableReader information because it's rather long... I can share 
> it privately if needed)
> Note that the date has not been changed (only 1ms between logs)
> It should not generate that gigantic amount of logs :)
> This is probably linked to: 
> https://issues.apache.org/jira/browse/CASSANDRA-9637



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

[jira] [Updated] (CASSANDRA-10111) reconnecting snitch can bypass cluster name check

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10111:

Reproduced In: 3.0.1, 2.2.4, 2.1.12, 2.0.15  (was: 2.0.15, 2.1.12, 2.2.4, 
3.0.1)
 Reviewer: Paulo Motta

> reconnecting snitch can bypass cluster name check
> -
>
> Key: CASSANDRA-10111
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10111
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Chris Burroughs
>Assignee: Joel Knighton
>  Labels: gossip
> Fix For: 3.x
>
>
> Setup:
>  * Two clusters: A & B
>  * Both are two DC cluster
>  * Both use GossipingPropertyFileSnitch with different 
> listen_address/broadcast_address
> A new node was added to cluster A with a broadcast_address of an existing 
> node in cluster B (due to an out of data DNS entry).  Cluster B  added all of 
> the nodes from cluster A, somehow bypassing the cluster name mismatch check 
> for this nodes.  The first reference to cluster A nodes in cluster B logs is 
> when then were added:
> {noformat}
>  INFO [GossipStage:1] 2015-08-17 15:08:33,858 Gossiper.java (line 983) Node 
> /8.37.70.168 is now part of the cluster
> {noformat}
> Cluster B nodes then tried to gossip to cluster A nodes, but cluster A kept 
> them out with 'ClusterName mismatch'.  Cluster B however tried to send to 
> send reads/writes to cluster A and general mayhem ensued.
> Obviously this is a Bad (TM) config that Should Not Be Done.  However, since 
> the consequence of crazy merged clusters are really bad (the reason there is 
> the name mismatch check in the first place) I think the hole is reasonable to 
> plug.  I'm not sure exactly what the code path is that skips the check in 
> GossipDigestSynVerbHandler.



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

[jira] [Updated] (CASSANDRA-10879) HSHA dtest for closing connections almost always fails on CASSCI developer branches

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-10879:
-
Assignee: Carl Yeksigian

> HSHA dtest for closing connections almost always fails on CASSCI developer 
> branches
> ---
>
> Key: CASSANDRA-10879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10879
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Branimir Lambov
>Assignee: Carl Yeksigian
>Priority: Critical
>
> The test consistently succeeds on 2.1/2.2 branches, but has been failing 
> almost every time on developer ones for quite a while, for example [9258 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-dikang85-9258-dtest/lastCompletedBuild/testReport/],
>  [10817 
> dtest|http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-10817-dtest/],
>  [10059 (committed) 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-10059-dtest/lastCompletedBuild/testReport/],
>  [unchanged 2.2 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-cassandra-2.2-dtest/lastCompletedBuild/testReport/]
>  and many others. The failures cannot be genuine if the same code committed 
> to the main branch no longer fails the test.
> This is making it hard to identify genuine failures and blocking 
> CASSANDRA-9669 in particular.



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

[jira] [Commented] (CASSANDRA-9923) stress write and counter_write hangs

[T Jake Luciani (JIRA)]

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

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

This is a known error.  Mainly stress is running low on heap.  We can add an 
env variable for stress shell script to change the max heap, or maybe just set 
mx to something high [~snazy]

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0
> total,

[jira] [Commented] (CASSANDRA-10863) HSHA test_closing_connections test still flaps on 3.0

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10863:


I have a new [dtest 
branch|https://github.com/carlyeks/cassandra-dtest/tree/10863] which switched 
from using {{lsof}} to the jmx {{connectedThriftClients}}, which was also non-0 
in the original ticket (CASSANDRA-6546).

A [3.0 
branch|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10863-3.0-dtest/lastSuccessfulBuild/testReport/thrift_hsha_test/ThriftHSHATest/test_closing_connections/history/]
 on cassci looks OK.

> HSHA test_closing_connections test still flaps on 3.0
> -
>
> Key: CASSANDRA-10863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10863
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> The problem reported in CASSANDRA-10570 still seems to be happening on 
> CassCI, as recently as a couple days ago:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/433/
> [~carlyeks] The fix in #10570 was to increase how long we'd sleep in the 
> tests. Should we just bump it up further, or does this make you suspect a 
> larger problem here?



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

[jira] [Assigned] (CASSANDRA-10863) HSHA test_closing_connections test still flaps on 3.0

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian reassigned CASSANDRA-10863:
--

Assignee: Carl Yeksigian

> HSHA test_closing_connections test still flaps on 3.0
> -
>
> Key: CASSANDRA-10863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10863
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> The problem reported in CASSANDRA-10570 still seems to be happening on 
> CassCI, as recently as a couple days ago:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/433/
> [~carlyeks] The fix in #10570 was to increase how long we'd sleep in the 
> tests. Should we just bump it up further, or does this make you suspect a 
> larger problem here?



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

[jira] [Commented] (CASSANDRA-9977) Support counter-columns for native aggregates (sum,avg,max,min)

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-9977:
-

Fair enough. Will change it to {{counter}} type in the branch.

> Support counter-columns for native aggregates (sum,avg,max,min)
> ---
>
> Key: CASSANDRA-9977
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9977
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Noam Liran
>Assignee: Robert Stupp
> Fix For: 2.2.x
>
>
> When trying to SUM a column of type COUNTER, this error is returned:
> {noformat}
> InvalidRequest: code=2200 [Invalid query] message="Invalid call to function 
> sum, none of its type signatures match (known type signatures: system.sum : 
> (tinyint) -> tinyint, system.sum : (smallint) -> smallint, system.sum : (int) 
> -> int, system.sum : (bigint) -> bigint, system.sum : (float) -> float, 
> system.sum : (double) -> double, system.sum : (decimal) -> decimal, 
> system.sum : (varint) -> varint)"
> {noformat}
> This might be relevant for other agg. functions.
> CQL for reproduction:
> {noformat}
> CREATE TABLE test (
> key INT,
> ctr COUNTER,
> PRIMARY KEY (
> key
> )
> );
> UPDATE test SET ctr = ctr + 1 WHERE key = 1;
> SELECT SUM(ctr) FROM test;
> {noformat}



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

[jira] [Commented] (CASSANDRA-10829) cleanup + repair generates a lot of logs

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10829:


We need to ensure we only {{unmarkCompacting}} the sstables which we haven't 
already unmarked, otherwise we could be running a different compaction 
operation on the previously unmarked sstables and unmark it again after this 
operation is finished.

> cleanup + repair generates a lot of logs
> 
>
> Key: CASSANDRA-10829
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10829
> Project: Cassandra
>  Issue Type: Bug
> Environment: 5 nodes on Cassandra 2.1.11 (on Debian)
>Reporter: Fabien Rousseau
>Assignee: Marcus Eriksson
> Fix For: 2.1.x
>
>
> One of our node generates a lot of cassandra logs (int the 10 MB/s) and CPU 
> usage has increased (by a factor 2-3).
> This was most probably triggered by a "nodetool snapshot" while a cleanup was 
> already running on this node.
> An example of those logs:
> 2015-12-08 09:15:17,794 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to 
> capture released readers [...]
> 2015-12-08 09:15:17,794 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to 
> capture all readers [...]
> 2015-12-08 09:15:17,795 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to 
> capture released readers [...]
> 2015-12-08 09:15:17,795 INFO  
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to 
> capture all readers [...]
> (I removed SSTableReader information because it's rather long... I can share 
> it privately if needed)
> Note that the date has not been changed (only 1ms between logs)
> It should not generate that gigantic amount of logs :)
> This is probably linked to: 
> https://issues.apache.org/jira/browse/CASSANDRA-9637



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

[jira] [Updated] (CASSANDRA-9923) stress write and counter_write hangs

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-9923:
---
Assignee: T Jake Luciani

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0
> total,   4996565,  45,  45,  45, 0.9, 0.7, 0.9,   
>   1.5,84.7,   218.3,  551.5,  0.11872,  0,  1, 248, 248,  
>  0,1180
> java.lang.RuntimeException: 

[jira] [Commented] (CASSANDRA-10879) HSHA dtest for closing connections almost always fails on CASSCI developer branches

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10879:
--

Ok, fair enough. Going to assign to [~carlyeks] though as it's related in any 
case.

> HSHA dtest for closing connections almost always fails on CASSCI developer 
> branches
> ---
>
> Key: CASSANDRA-10879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10879
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Branimir Lambov
>Priority: Critical
>
> The test consistently succeeds on 2.1/2.2 branches, but has been failing 
> almost every time on developer ones for quite a while, for example [9258 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-dikang85-9258-dtest/lastCompletedBuild/testReport/],
>  [10817 
> dtest|http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-10817-dtest/],
>  [10059 (committed) 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-10059-dtest/lastCompletedBuild/testReport/],
>  [unchanged 2.2 
> dtest|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-cassandra-2.2-dtest/lastCompletedBuild/testReport/]
>  and many others. The failures cannot be genuine if the same code committed 
> to the main branch no longer fails the test.
> This is making it hard to identify genuine failures and blocking 
> CASSANDRA-9669 in particular.



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

[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10733:
--
Issue Type: Bug  (was: Improvement)

> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
>  Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
> Attachments: CASSANDRA-2.2-10733-CQLSH-Auto.patch, 
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some 
> inconsistent behaviour when completing part of the statement and hitting the 
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}} 
> works correctly. We see a list of all tables (or functions, types) in the 
> current keyspace plus a list of all available keyspaces followed by a full 
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE 
>  minutedata   system_distributed.
> ;rawtickdatabylp  system_traces.
>   rawtickdatabysymbol  tickdata
> daydata  system.  
> fxaggr.  system_auth. 
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in 
> this case, only 1, called 'average') but does not display a list of available 
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate 
>  ;  average  fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type 
> .'}} works correctly. We see a list of all tables (or types) in the 
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata  rawtickdatabylp  tickdata
> minutedata   rawtickdatabysymbol  
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate 
> .'}} works inconsistently. In a keyspace with 2 functions, both 
> beginning with the letters 'avg', if I type {{'desc function '}} 
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg 
> '}} and will not display the matching functions. If I type {{'desc function 
> .'}} (note the trailing full stop) and hit tab, auto-complete will 
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal  avgstate  
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns  
> {{'desc aggregate  '}}  (it adds a space) and does not show me the 
> list of available aggregates. If I type {{'desc aggregate .'}} 
> (note the trailing full stop) and hit tab, auto-complete will work correctly.



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

[jira] [Assigned] (CASSANDRA-10856) CHANGES and NEWS updated incorrectly when "thrift by default" was deprecated

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne reassigned CASSANDRA-10856:


Assignee: Sylvain Lebresne

> CHANGES and NEWS updated incorrectly when "thrift by default" was deprecated
> 
>
> Key: CASSANDRA-10856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10856
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Sylvain Lebresne
>
> Thrift was no longer started by default in CASSANDRA-9319. This change 
> affects 2.2+, but the CHANGES and NEWS document the change as affecting 3.0+:
> https://github.com/apache/cassandra/commit/fa4a020ac922fcdc0f3c2bebe35777cfa2e223c1
> I think this is incorrect; [~iamaleksey] can you confirm?



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

[jira] [Updated] (CASSANDRA-10840) Replacing an aggregate with a new version doesn't reset INITCOND

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-10840:

Reproduced In: 3.0.1, 2.2.4  (was: 2.2.4, 3.0.1)
 Reviewer: Benjamin Lerer

> Replacing an aggregate with a new version doesn't reset INITCOND
> 
>
> Key: CASSANDRA-10840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10840
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Observed in Cassandra 2.2.4, though it might be an issue 
> in 3.0 as well
>Reporter: Sandeep Tamhankar
>Assignee: Robert Stupp
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> {code}
> use simplex;
>   CREATE FUNCTION state_group_and_sum(state map, star_rating 
> int)
>   CALLED ON NULL INPUT
>   RETURNS map
>   LANGUAGE java
>   AS 'if (state.get(star_rating) == null) 
> state.put(star_rating, 1); else state.put(star_rating, ((Integer) 
> state.get(star_rating)) + 1); return state;';
>   CREATE FUNCTION percent_stars(state map)
>   RETURNS NULL ON NULL INPUT
>   RETURNS map
>   LANGUAGE java AS $$
> Integer sum = 0; 
> for(Object k : state.keySet()) { 
> sum = sum + (Integer) state.get((Integer) k);
> }
> java.util.Map results = new java.util.HashMap Integer>();
> for(Object k : state.keySet()) {
> results.put((Integer) k, ((Integer) state.get((Integer) k))*100 / sum);
> }
> return results;
> $$;
> {code}
> {code}
> CREATE OR REPLACE AGGREGATE group_and_sum(int)
> SFUNC state_group_and_sum
> STYPE map
> FINALFUNC percent_stars
> INITCOND {}
> {code}
> 1. View the aggregates
> {{select * from system.schema_aggregates;}}
> 2. Now update
> {code}
> CREATE OR REPLACE AGGREGATE group_and_sum(int)
> SFUNC state_group_and_sum
> STYPE map
> FINALFUNC percent_stars
> INITCOND NULL
> {code}
> 3. View the aggregates
> {{select * from system.schema_aggregates;}}
> Expected result:
> * The update should have made initcond null
> Actual result:
> * The update did not touch INITCOND.



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

[jira] [Updated] (CASSANDRA-8708) inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-8708:

Attachment: 8708-2.1-jmx-nodetool-bulkloader-v2.txt

There were a couple of missing declarations in nodetool.  Those are fixed and I 
will run the dtests with this latest patch with a branch from my github.

> inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited
> -
>
> Key: CASSANDRA-8708
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8708
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Adam Hattrell
>Assignee: Jeremy Hanna
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 8708-2.1-jmx-nodetool-bulkloader-v2.txt, 
> 8708-2.1-jmx-nodetool-bulkloader.txt, 8708-2.1-with-jmx-nodetool.txt, 
> 8708-2.1.txt
>
>
> inter_dc_stream_throughput_outbound_megabits_per_sec was introduced in 
> CASSANDRA-6596.
> There's some discussion in the ticket of the intention to link the default to 
> whatever stream_throughput_outbound_megabits_per_sec is set to.  
> However, it looks like it's just set to 0 - from 
> /src/java/org/apache/cassandra/config/Config.java
> This is a bit of a pain - usually folks want to set the inter dc limits lower 
> than the base streaming figure.



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

[jira] [Commented] (CASSANDRA-9923) stress write and counter_write hangs

[T Jake Luciani (JIRA)]

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

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

Ah I understand. ok.

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>Priority: Minor
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0
> total,   4996565,  45,  45,  45, 0.9, 0.7, 0.9,   
>   1.5,84.7,   218.3,  551.5,  

[jira] [Commented] (CASSANDRA-10859) AssertionError in nodetool cfhistograms

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10859:
-

code and tests look good, marking as ready to commit. thanks!

> AssertionError in nodetool cfhistograms
> ---
>
> Key: CASSANDRA-10859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10859
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Tools
>Reporter: Jim Witschey
>Assignee: Yuki Morishita
> Fix For: 3.0.x, 3.x
>
>
> {{nodetool cfhistograms}} raises an {{AssertionError}} on the CassCI 
> {{trunk}} jobs:
> http://cassci.datastax.com/job/trunk_dtest/lastCompletedBuild/testReport/jmx_test/TestJMX/cfhistograms_test/history/
> This regression started in this build on CassCI and has failed consistently 
> since then:
> http://cassci.datastax.com/job/trunk_dtest/806/testReport/junit/jmx_test/TestJMX/cfhistograms_test/
> I can't find any recent dtest changes to this method, so I believe it's a 
> Cassandra bug. Here's the changeset for the first failing build:
> http://cassci.datastax.com/job/trunk_dtest/806/changes
> Maybe something in the changes to the scripts here introduced the bug:
> https://github.com/apache/cassandra/commit/b5240204d7aa2a32c6649d19da2b961c856cde28
> [~jjordan] could you have a look at this please?
> This appears to only affect {{trunk}} at present.



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

[jira] [Commented] (CASSANDRA-9923) stress write and counter_write hangs

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-9923:
-

Yea, sure. You can pass JVM_OPTS. Was thinking of something like 
{{cassandra-stress -J-Xmx4G ...}}, which could also be used with cstar.

> stress write and counter_write hangs
> 
>
> Key: CASSANDRA-9923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9923
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
>Priority: Minor
>  Labels: stress
>
> (Sorry for the vague description)
> I tried some cstar tests against counter columns. But all these tests against 
> 2.1 and 2.2 ended (hang) during with the following output:
> {noformat}
> Created keyspaces. Sleeping 3s for propagation.
> Sleeping 2s...
> Warming up COUNTER_WRITE with 15 iterations...
> Running COUNTER_WRITE with 300 threads for 1500 iteration
> type,  total ops,op/s,pk/s,   row/s,mean, med, .95,   
>   .99,.999, max,   time,   stderr, errors,  gc: #,  max ms,  sum ms,  
> sdv ms,  mb
> total, 98073,   98054,   98054,   98054, 3.1, 1.7, 8.9,   
>  23.2,89.9,   107.7,1.0,  0.0,  0,  0,   0,   0,  
>  0,   0
> total,188586,   72492,   72492,   72492, 4.1, 1.5,10.0,   
>  61.4,   202.8,   214.7,2.2,  0.13101,  0,  3, 564, 564,  
>  6,3447
> total,363880,  137986,  137986,  137986, 2.2, 1.4, 4.1,   
>   9.6,   207.1,   253.3,3.5,  0.18684,  0,  0,   0,   0,  
>  0,   0
> total,460122,  105062,  105062,  105062, 2.8, 1.4, 4.6,   
>  14.7,   225.6,   236.2,4.4,  0.13969,  0,  1, 214, 214,  
>  0,1199
> total,600625,  111453,  111453,  111453, 2.7, 1.4, 3.8,   
>  10.4,   231.5,   241.6,5.7,  0.11366,  0,  2, 442, 442,  
>  1,2389
> total,745680,  149583,  149583,  149583, 2.0, 1.4, 3.6,   
>   6.7,   155.8,   159.7,6.7,  0.11318,  0,  0,   0,   0,  
>  0,   0
> total,828453,   63632,   63632,   63632, 4.7, 1.4, 4.8,   
> 261.9,   274.5,   279.3,8.0,  0.12645,  0,  3, 782, 782,  
>  1,3542
> total,   1009560,  172429,  172429,  172429, 1.7, 1.4, 3.7,   
>   6.1,16.2,29.7,9.0,  0.11629,  0,  0,   0,   0,  
>  0,   0
> total,   1062409,   53860,   53860,   53860, 5.5, 1.3, 8.6,   
> 270.3,   293.4,   324.3,   10.0,  0.12738,  0,  2, 542, 542,  
>  7,2354
> total,   1186672,   96540,   96540,   96540, 3.1, 1.5, 5.9,   
>  14.5,   266.4,   277.6,   11.3,  0.11451,  0,  1, 260, 260,  
>  0,1183
> {noformat}
> ...
> {noformat}
> total,   4977251, 238, 238, 238, 0.7, 0.6, 0.7,   
>   1.3, 3.4,   158.5,  352.3,  0.11749,  0,  0,   0,   0,  
>  0,   0
> total,   4979839, 214, 214, 214, 0.6, 0.6, 0.7,   
>   1.3, 2.5, 2.8,  364.4,  0.11761,  0,  0,   0,   0,  
>  0,   0
> total,   4981729, 191, 191, 191, 0.6, 0.6, 0.7,   
>   1.3, 3.2, 3.3,  374.3,  0.11774,  0,  0,   0,   0,  
>  0,   0
> total,   4983362, 167, 167, 167, 0.8, 0.7, 1.8,   
>   2.7, 3.9, 5.8,  384.0,  0.11787,  0,  0,   0,   0,  
>  0,   0
> total,   4985171, 153, 153, 153, 0.7, 0.6, 1.2,   
>   1.4, 2.0, 3.3,  395.9,  0.11799,  0,  0,   0,   0,  
>  0,   0
> total,   4986684, 137, 137, 137, 0.7, 0.6, 0.8,   
>   1.3, 2.0, 2.0,  406.9,  0.11812,  0,  0,   0,   0,  
>  0,   0
> total,   4988410, 121, 121, 121, 0.7, 0.7, 0.8,   
>   1.3, 2.0, 2.8,  421.1,  0.11824,  0,  0,   0,   0,  
>  0,   0
> total,   4990216,  99,  99,  99, 0.7, 0.7, 0.8,   
>   1.4, 2.6, 2.8,  439.5,  0.11836,  0,  0,   0,   0,  
>  0,   0
> total,   4991765,  81,  81,  81, 0.8, 0.7, 0.8,   
>   1.4,30.1,81.6,  458.7,  0.11848,  0,  1, 159, 159,  
>  0,1179
> total,   4993731,  67,  67,  67, 0.7, 0.7, 0.8,   
>   1.4, 3.2, 3.2,  488.1,  0.11860,  0,  0,   0,   0,  
>  0,   0
> 

[jira] [Commented] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves

[Philip Thompson (JIRA)]

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

Philip Thompson commented on CASSANDRA-10887:
-

I've written up a dtest here: 
https://github.com/riptano/cassandra-dtest/pull/717 and pinged Branimir about 
it. I can't reproduce manually with Simon's steps or with my test on 2.1, 2.2, 
or 3.0. I've asked Jim to take a look as well.

> Pending range calculator gives wrong pending ranges for moves
> -
>
> Key: CASSANDRA-10887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>Assignee: Branimir Lambov
>Priority: Critical
>
> My understanding is the PendingRangeCalculator is meant to calculate who 
> should receive extra writes during range movements. However, it adds the 
> wrong ranges for moves. An extreme example of this can be seen in the 
> following reproduction. Create a 5 node cluster (I did this on 2.0.16 and 
> 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and 
> immediately kill -9 it. Now you see a node as down and moving in the ring. 
> Try a quorum write for a partition that is stored on that node - it will fail 
> with a timeout. Further, all CAS reads or writes fail immediately with 
> unavailable exception because they attempt to include the moving node twice. 
> This is likely to be the cause of CASSANDRA-10423.
> In my example I had this ring:
> 127.0.0.1  rack1   Up Normal  170.97 KB   20.00%  
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  124.06 KB   20.00%  
> -5534023222112865485
> 127.0.0.3  rack1   Down   Moving  108.7 KB40.00%  
> 1844674407370955160
> 127.0.0.4  rack1   Up Normal  142.58 KB   0.00%   
> 1844674407370955161
> 127.0.0.5  rack1   Up Normal  118.64 KB   20.00%  
> 5534023222112865484
> Node 3 was moving to -1844674407370955160. I added logging to print the 
> pending and natural endpoints. For ranges owned by node 3, node 3 appeared in 
> pending and natural endpoints. The blockFor is increased to 3 so we’re 
> effectively doing CL.ALL operations. This manifests as write timeouts and CAS 
> unavailables when the node is down.
> The correct pending range for this scenario is node 1 is gaining the range 
> (-1844674407370955160, 1844674407370955160). So node 1 should be added as a 
> destination for writes and CAS for this range, not node 3.



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

[jira] [Comment Edited] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves

[Philip Thompson (JIRA)]

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

Philip Thompson edited comment on CASSANDRA-10887 at 12/18/15 7:07 PM:
---

I've written up a dtest here: 
https://github.com/riptano/cassandra-dtest/pull/717 and pinged Branimir about 
it. I can't reproduce manually with Simon's steps or with my test on 2.1, 2.2, 
or 3.0. I've asked [~mambocab] to take a look as well.


was (Author: philipthompson):
I've written up a dtest here: 
https://github.com/riptano/cassandra-dtest/pull/717 and pinged Branimir about 
it. I can't reproduce manually with Simon's steps or with my test on 2.1, 2.2, 
or 3.0. I've asked Jim to take a look as well.

> Pending range calculator gives wrong pending ranges for moves
> -
>
> Key: CASSANDRA-10887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>Assignee: Branimir Lambov
>Priority: Critical
>
> My understanding is the PendingRangeCalculator is meant to calculate who 
> should receive extra writes during range movements. However, it adds the 
> wrong ranges for moves. An extreme example of this can be seen in the 
> following reproduction. Create a 5 node cluster (I did this on 2.0.16 and 
> 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and 
> immediately kill -9 it. Now you see a node as down and moving in the ring. 
> Try a quorum write for a partition that is stored on that node - it will fail 
> with a timeout. Further, all CAS reads or writes fail immediately with 
> unavailable exception because they attempt to include the moving node twice. 
> This is likely to be the cause of CASSANDRA-10423.
> In my example I had this ring:
> 127.0.0.1  rack1   Up Normal  170.97 KB   20.00%  
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  124.06 KB   20.00%  
> -5534023222112865485
> 127.0.0.3  rack1   Down   Moving  108.7 KB40.00%  
> 1844674407370955160
> 127.0.0.4  rack1   Up Normal  142.58 KB   0.00%   
> 1844674407370955161
> 127.0.0.5  rack1   Up Normal  118.64 KB   20.00%  
> 5534023222112865484
> Node 3 was moving to -1844674407370955160. I added logging to print the 
> pending and natural endpoints. For ranges owned by node 3, node 3 appeared in 
> pending and natural endpoints. The blockFor is increased to 3 so we’re 
> effectively doing CL.ALL operations. This manifests as write timeouts and CAS 
> unavailables when the node is down.
> The correct pending range for this scenario is node 1 is gaining the range 
> (-1844674407370955160, 1844674407370955160). So node 1 should be added as a 
> destination for writes and CAS for this range, not node 3.



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

[jira] [Commented] (CASSANDRA-10902) Skip saved cache directory when checking SSTables at startup

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10902:


Pushed a branch which fixes this; I included the commitlog and hints 
directories (on 3.0+), even though they don't currently contain any .db files. 
I pushed [a dtest|https://github.com/carlyeks/cassandra-dtest/tree/10902] that 
demonstrates the problem.

||2.2||3.0||trunk||
|[branch|https://github.com/carlyeks/cassandra/tree/ticket/10902/2.2]|[branch|https://github.com/carlyeks/cassandra/tree/ticket/10902/3.0]|[branch|https://github.com/carlyeks/cassandra/tree/ticket/10902/trunk]|
|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10902-2.2-testall/]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10902-3.0-testall/]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10902-trunk-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10902-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10902-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-10902-trunk-dtest/]|

> Skip saved cache directory when checking SSTables at startup
> 
>
> Key: CASSANDRA-10902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10902
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
>
> The SSTable StartupCheck looks for all files which end with "*.db" and 
> compares the version. This causes problems if {{saved_cache_directory}} is a 
> subdirectory of a {{data_file_directories}}. We should make sure that we are 
> not checking any subdirectory where we might be writing *.db files.
> This is the cause of not being able to restart in CASSANDRA-10821.



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

[jira] [Commented] (CASSANDRA-9830) Option to disable bloom filter in highest level of LCS sstables

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-9830:


Rebased and submitted cstar_perf tests comparing LCS with default settings vs 
enabled {{skip_top_level_bloom_filter}} option on 
[ssd|http://cstar.datastax.com/tests/id/35023b30-a5bc-11e5-aa2d-0256e416528f] 
and 
[hdd|http://cstar.datastax.com/tests/id/3d14a8ac-a5bd-11e5-aa2d-0256e416528f].

Will report back when results are ready and maybe play around with parameters 
(sstable size, bloom filter fp chance, etc) after initial results.

> Option to disable bloom filter in highest level of LCS sstables
> ---
>
> Key: CASSANDRA-9830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9830
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction
>Reporter: Jonathan Ellis
>Assignee: Paulo Motta
>Priority: Minor
>  Labels: performance
> Fix For: 3.2
>
>
> We expect about 90% of data to be in the highest level of LCS in a fully 
> populated series.  (See also CASSANDRA-9829.)
> Thus if the user is primarily asking for data (partitions) that has actually 
> been inserted, the bloom filter on the highest level only helps reject 
> sstables about 10% of the time.
> We should add an option that suppresses bloom filter creation on top-level 
> sstables.  This will dramatically reduce memory usage for LCS and may even 
> improve performance as we no longer check a low-value filter.
> (This is also an idea from RocksDB.)



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

[jira] [Commented] (CASSANDRA-10779) AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread Thread

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-10779:


I think there is a different issue lurking here, which is that we are 
responding to mutations early on the replicas if we don't acquire the lock 
right away. We are returning early from the {{mutation.apply}} call because we 
were unable to acquire the lock, but in the {{MutationVerbHandler}}, we're only 
don't reply in the case we get a WTE (which only happens in the MV path).

The reason we changed this to put itself back on the queue when it was unable 
to acquire the lock was that we would otherwise be blocking other mutations 
that are waiting, especially the coordinator batchlog mutations. Since we 
aren't doing the coordinator batchlog, it might be best to just switch back to 
waiting for the lock synchronously. The other option would be to include a 
callback function with the mutation to run on success/failure.

I'm currently testing the impact of changing this to acquiring the lock 
synchronously; I'll also look into the amount of change required to add 
callback functions.

> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread
> --
>
> Key: CASSANDRA-10779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10779
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: Windows 7 64-bit, Cassandra v3.0.0, Java 1.8u60
>Reporter: Will Zhang
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> Hi guys,
> I encountered the following warning message when I was testing to upgrade 
> from v2.2.2 to v3.0.0. 
> It looks like a write time-out but in an uncaught exception. Could this be an 
> easy fix?
> Log file section below. Thank you!
> {code}
>   WARN  [SharedPool-Worker-64] 2015-11-26 14:04:24,678 
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-64,10,main]: {}
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out - 
> received only 0 responses.
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:427) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:386) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:205) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.db.Keyspace.lambda$apply$59(Keyspace.java:435) 
> ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.0.jar:3.0.0]
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.0.jar:3.0.0]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
>   INFO  [IndexSummaryManager:1] 2015-11-26 14:41:10,527 
> IndexSummaryManager.java:257 - Redistributing index summaries
> {code}



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

[jira] [Commented] (CASSANDRA-9428) Implement hints compression

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-9428:


Feedback:
* In {{CompressedChecksummedDataInput.reBufferStandard:L65}}, consider 
{{ICompressor.initialCompressedBufferLength}} rather than 5% allocation 
overhead.
* {{HintsWriter.bufferWrites}}: I'm not crazy about us having a volatile 
increment in the critical path that's only used in a testing context.
* In {{HintsCompressionTest.multiFlushAndDeserializeTest}}, bitshifting on init 
of {{bufferSize}} is unnecessary.
* Would prefer {{HintsCompressionTest}} to exercise all available compressor 
types as a matter of general hygiene.

Nits:
* extra space in yaml before new param
* extra space before closing brace in HintsWriter.create()
* unused imports in HintsCompressionTest
* some extra whitespace (doubled) in 
{{HintsCompressionTest.multiFlushAndDeserializeTest}}

I'm fine with both the caveats you mention above. Looking good so far!

> Implement hints compression
> ---
>
> Key: CASSANDRA-9428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9428
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination
>Reporter: Aleksey Yeschenko
>Assignee: Blake Eggleston
> Fix For: 3.0.x
>
>
> CASSANDRA-6230 is being implemented with compression in mind, but it's not 
> going to be implemented by the original ticket.
> Adding it on top should be relatively straight-forward, and important, since 
> there are several users in the wild that use compression interface for 
> encryption purposes. DSE is one of them (but isn't the only one). Losing 
> encryption capabilities would be a regression.



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

cassandra git commit: Improve FailureDetector Unknown EP Error Message

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk ce7f5cc33 -> ff5b7099a


Improve FailureDetector Unknown EP Error Message

patch by Anthony Cozzie; reviewed by Carl Yeksigian for CASSANDRA-10795


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

Branch: refs/heads/trunk
Commit: ff5b7099afa0c459c63bd2993387d966c01d7fcf
Parents: ce7f5cc
Author: Anthony Cozzie 
Authored: Tue Dec 1 10:36:32 2015 -0700
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 22:58:54 2015 +

--
 src/java/org/apache/cassandra/gms/FailureDetector.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ff5b7099/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java 
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index a0754b1..5a1179f 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -246,7 +246,7 @@ public class FailureDetector implements IFailureDetector, 
FailureDetectorMBean
 // it's worth being defensive here so minor bugs don't cause 
disproportionate
 // badness.  (See CASSANDRA-1463 for an example).
 if (epState == null)
-logger.error("unknown endpoint {}", ep);
+logger.error("Unknown endpoint: " + ep, new 
IllegalArgumentException(""));
 return epState != null && epState.isAlive();
 }
 

[2/3] cassandra git commit: Add back support for 3rd party auth providers to bulk loader

[yukim]

Add back support for 3rd party auth providers to bulk loader

patch by Mike Adamson; reviewed by yukim for CASSANDRA-10873


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

Branch: refs/heads/trunk
Commit: fa18880e73f7f3bdbb1075c0baa54a7df3e667d0
Parents: 2e09583
Author: Mike Adamson 
Authored: Wed Dec 16 10:37:47 2015 +
Committer: Yuki Morishita 
Committed: Fri Dec 18 17:09:28 2015 -0600

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/tools/BulkLoader.java  | 79 ++--
 .../utils/NativeSSTableLoaderClient.java| 16 ++--
 3 files changed, 84 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa18880e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e6ab5dd..199e374 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.3
+ * Add back support for 3rd party auth providers to bulk loader 
(CASSANDRA-10873)
  * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
  * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
  * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa18880e/src/java/org/apache/cassandra/tools/BulkLoader.java
--
diff --git a/src/java/org/apache/cassandra/tools/BulkLoader.java 
b/src/java/org/apache/cassandra/tools/BulkLoader.java
index 73194a1..2b94a68 100644
--- a/src/java/org/apache/cassandra/tools/BulkLoader.java
+++ b/src/java/org/apache/cassandra/tools/BulkLoader.java
@@ -19,6 +19,8 @@ package org.apache.cassandra.tools;
 
 import java.io.File;
 import java.io.IOException;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.InvocationTargetException;
 import java.net.InetAddress;
 import java.net.MalformedURLException;
 import java.net.UnknownHostException;
@@ -28,6 +30,8 @@ import com.google.common.collect.HashMultimap;
 import com.google.common.collect.Multimap;
 import org.apache.commons.cli.*;
 
+import com.datastax.driver.core.AuthProvider;
+import com.datastax.driver.core.PlainTextAuthProvider;
 import com.datastax.driver.core.SSLOptions;
 import javax.net.ssl.SSLContext;
 import org.apache.cassandra.config.*;
@@ -50,6 +54,7 @@ public class BulkLoader
 private static final String NATIVE_PORT_OPTION = "port";
 private static final String USER_OPTION = "username";
 private static final String PASSWD_OPTION = "password";
+private static final String AUTH_PROVIDER_OPTION = "auth-provider";
 private static final String THROTTLE_MBITS = "throttle";
 
 /* client encryption options */
@@ -67,15 +72,14 @@ public class BulkLoader
 public static void main(String args[])
 {
 Config.setClientMode(true);
-LoaderOptions options = LoaderOptions.parseArgs(args);
+LoaderOptions options = 
LoaderOptions.parseArgs(args).validateArguments();
 OutputHandler handler = new 
OutputHandler.SystemOutput(options.verbose, options.debug);
 SSTableLoader loader = new SSTableLoader(
 options.directory,
 new ExternalClient(
 options.hosts,
 options.nativePort,
-options.user,
-options.passwd,
+options.authProvider,
 options.storagePort,
 options.sslStoragePort,
 options.serverEncOptions,
@@ -277,14 +281,13 @@ public class BulkLoader
 
 public ExternalClient(Set hosts,
   int port,
-  String user,
-  String passwd,
+  AuthProvider authProvider,
   int storagePort,
   int sslStoragePort,
   EncryptionOptions.ServerEncryptionOptions 
serverEncryptionOptions,
   SSLOptions sslOptions)
 {
-super(hosts, port, user, passwd, sslOptions);
+super(hosts, port, authProvider, sslOptions);
 this.storagePort = storagePort;
 this.sslStoragePort = sslStoragePort;
 this.serverEncOptions = serverEncryptionOptions;
@@ -307,6 +310,8 @@ public class BulkLoader
 public int nativePort = 9042;
 public String user;
 public String 

[1/3] cassandra git commit: Add back support for 3rd party auth providers to bulk loader

[yukim]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 2e095833d -> fa18880e7
  refs/heads/trunk ff5b7099a -> 622d1f7c0


Add back support for 3rd party auth providers to bulk loader

patch by Mike Adamson; reviewed by yukim for CASSANDRA-10873


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

Branch: refs/heads/cassandra-3.0
Commit: fa18880e73f7f3bdbb1075c0baa54a7df3e667d0
Parents: 2e09583
Author: Mike Adamson 
Authored: Wed Dec 16 10:37:47 2015 +
Committer: Yuki Morishita 
Committed: Fri Dec 18 17:09:28 2015 -0600

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/tools/BulkLoader.java  | 79 ++--
 .../utils/NativeSSTableLoaderClient.java| 16 ++--
 3 files changed, 84 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa18880e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e6ab5dd..199e374 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.3
+ * Add back support for 3rd party auth providers to bulk loader 
(CASSANDRA-10873)
  * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
  * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
  * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa18880e/src/java/org/apache/cassandra/tools/BulkLoader.java
--
diff --git a/src/java/org/apache/cassandra/tools/BulkLoader.java 
b/src/java/org/apache/cassandra/tools/BulkLoader.java
index 73194a1..2b94a68 100644
--- a/src/java/org/apache/cassandra/tools/BulkLoader.java
+++ b/src/java/org/apache/cassandra/tools/BulkLoader.java
@@ -19,6 +19,8 @@ package org.apache.cassandra.tools;
 
 import java.io.File;
 import java.io.IOException;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.InvocationTargetException;
 import java.net.InetAddress;
 import java.net.MalformedURLException;
 import java.net.UnknownHostException;
@@ -28,6 +30,8 @@ import com.google.common.collect.HashMultimap;
 import com.google.common.collect.Multimap;
 import org.apache.commons.cli.*;
 
+import com.datastax.driver.core.AuthProvider;
+import com.datastax.driver.core.PlainTextAuthProvider;
 import com.datastax.driver.core.SSLOptions;
 import javax.net.ssl.SSLContext;
 import org.apache.cassandra.config.*;
@@ -50,6 +54,7 @@ public class BulkLoader
 private static final String NATIVE_PORT_OPTION = "port";
 private static final String USER_OPTION = "username";
 private static final String PASSWD_OPTION = "password";
+private static final String AUTH_PROVIDER_OPTION = "auth-provider";
 private static final String THROTTLE_MBITS = "throttle";
 
 /* client encryption options */
@@ -67,15 +72,14 @@ public class BulkLoader
 public static void main(String args[])
 {
 Config.setClientMode(true);
-LoaderOptions options = LoaderOptions.parseArgs(args);
+LoaderOptions options = 
LoaderOptions.parseArgs(args).validateArguments();
 OutputHandler handler = new 
OutputHandler.SystemOutput(options.verbose, options.debug);
 SSTableLoader loader = new SSTableLoader(
 options.directory,
 new ExternalClient(
 options.hosts,
 options.nativePort,
-options.user,
-options.passwd,
+options.authProvider,
 options.storagePort,
 options.sslStoragePort,
 options.serverEncOptions,
@@ -277,14 +281,13 @@ public class BulkLoader
 
 public ExternalClient(Set hosts,
   int port,
-  String user,
-  String passwd,
+  AuthProvider authProvider,
   int storagePort,
   int sslStoragePort,
   EncryptionOptions.ServerEncryptionOptions 
serverEncryptionOptions,
   SSLOptions sslOptions)
 {
-super(hosts, port, user, passwd, sslOptions);
+super(hosts, port, authProvider, sslOptions);
 this.storagePort = storagePort;
 this.sslStoragePort = sslStoragePort;
 this.serverEncOptions = 

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

[yukim]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 622d1f7c0a37c679da2d703fc0bc9ac8bf5ce68d
Parents: ff5b709 fa18880
Author: Yuki Morishita 
Authored: Fri Dec 18 17:12:25 2015 -0600
Committer: Yuki Morishita 
Committed: Fri Dec 18 17:12:25 2015 -0600

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/tools/BulkLoader.java  | 79 ++--
 .../utils/NativeSSTableLoaderClient.java| 16 ++--
 3 files changed, 84 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/622d1f7c/CHANGES.txt
--
diff --cc CHANGES.txt
index e8fbc0d,199e374..5cbbb62
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,26 -1,5 +1,27 @@@
 -3.0.3
 +3.2
 + * Fix EstimatedHistogram creation in nodetool tablehistograms 
(CASSANDRA-10859)
 + * Establish bootstrap stream sessions sequentially (CASSANDRA-6992)
 + * Sort compactionhistory output by timestamp (CASSANDRA-10464)
 + * More efficient BTree removal (CASSANDRA-9991)
 + * Make tablehistograms accept the same syntax as tablestats (CASSANDRA-10149)
 + * Group pending compactions based on table (CASSANDRA-10718)
 + * Add compressor name in sstablemetadata output (CASSANDRA-9879)
 + * Fix type casting for counter columns (CASSANDRA-10824)
 + * Prevent running Cassandra as root (CASSANDRA-8142)
 + * bound maximum in-flight commit log replay mutation bytes to 64 megabytes 
(CASSANDRA-8639)
 + * Normalize all scripts (CASSANDRA-10679)
 + * Make compression ratio much more accurate (CASSANDRA-10225)
 + * Optimize building of Clustering object when only one is created 
(CASSANDRA-10409)
 + * Make index building pluggable (CASSANDRA-10681)
 + * Add sstable flush observer (CASSANDRA-10678)
 + * Improve NTS endpoints calculation (CASSANDRA-10200)
 + * Improve performance of the folderSize function (CASSANDRA-10677)
 + * Add support for type casting in selection clause (CASSANDRA-10310)
 + * Added graphing option to cassandra-stress (CASSANDRA-7918)
 + * Abort in-progress queries that time out (CASSANDRA-7392)
 + * Add transparent data encryption core classes (CASSANDRA-9945)
 +Merged from 3.0:
+  * Add back support for 3rd party auth providers to bulk loader 
(CASSANDRA-10873)
   * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
   * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
   * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)

[jira] [Updated] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-10887:
--
Attachment: CASSANDRA-10887.diff

> Pending range calculator gives wrong pending ranges for moves
> -
>
> Key: CASSANDRA-10887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>Assignee: sankalp kohli
>Priority: Critical
> Attachments: CASSANDRA-10887.diff
>
>
> My understanding is the PendingRangeCalculator is meant to calculate who 
> should receive extra writes during range movements. However, it adds the 
> wrong ranges for moves. An extreme example of this can be seen in the 
> following reproduction. Create a 5 node cluster (I did this on 2.0.16 and 
> 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and 
> immediately kill -9 it. Now you see a node as down and moving in the ring. 
> Try a quorum write for a partition that is stored on that node - it will fail 
> with a timeout. Further, all CAS reads or writes fail immediately with 
> unavailable exception because they attempt to include the moving node twice. 
> This is likely to be the cause of CASSANDRA-10423.
> In my example I had this ring:
> 127.0.0.1  rack1   Up Normal  170.97 KB   20.00%  
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  124.06 KB   20.00%  
> -5534023222112865485
> 127.0.0.3  rack1   Down   Moving  108.7 KB40.00%  
> 1844674407370955160
> 127.0.0.4  rack1   Up Normal  142.58 KB   0.00%   
> 1844674407370955161
> 127.0.0.5  rack1   Up Normal  118.64 KB   20.00%  
> 5534023222112865484
> Node 3 was moving to -1844674407370955160. I added logging to print the 
> pending and natural endpoints. For ranges owned by node 3, node 3 appeared in 
> pending and natural endpoints. The blockFor is increased to 3 so we’re 
> effectively doing CL.ALL operations. This manifests as write timeouts and CAS 
> unavailables when the node is down.
> The correct pending range for this scenario is node 1 is gaining the range 
> (-1844674407370955160, 1844674407370955160). So node 1 should be added as a 
> destination for writes and CAS for this range, not node 3.



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

[jira] [Commented] (CASSANDRA-10795) Improve Failure Detector Unknown EP message

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10795:
---

Committed to trunk as 
[ff5b7099afa0c459c63bd2993387d966c01d7fcf|https://github.com/apache/cassandra/commit/ff5b7099afa0c459c63bd2993387d966c01d7fcf],
 thanks.

> Improve Failure Detector Unknown EP message
> ---
>
> Key: CASSANDRA-10795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10795
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Anthony Cozzie
>Assignee: Anthony Cozzie
>Priority: Minor
> Fix For: 3.2
>
> Attachments: trunk-10795-2.txt, trunk-10795.txt
>
>
> When the failure detector is asked whether an unknown endpoint is alive, it 
> prints an uninformative error message.  This patch adds a stack trace to the 
> print statement.



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

[jira] [Updated] (CASSANDRA-10795) Improve Failure Detector Unknown EP message

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-10795:
--
Issue Type: Improvement  (was: Bug)

> Improve Failure Detector Unknown EP message
> ---
>
> Key: CASSANDRA-10795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10795
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Anthony Cozzie
>Assignee: Anthony Cozzie
>Priority: Minor
> Fix For: 3.2
>
> Attachments: trunk-10795-2.txt, trunk-10795.txt
>
>
> When the failure detector is asked whether an unknown endpoint is alive, it 
> prints an uninformative error message.  This patch adds a stack trace to the 
> print statement.



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

[jira] [Commented] (CASSANDRA-9494) Need to set TTL with COPY command

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-9494:
--

Committed to trunk only as 
[99880d22de0023081a6d5829bef991eb96f7c342|https://github.com/apache/cassandra/commit/99880d22de0023081a6d5829bef991eb96f7c342].
 Time for us to get stricter with 'feature only go into 3.x' mode.

> Need to set TTL with COPY command
> -
>
> Key: CASSANDRA-9494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9494
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: CQL
>Reporter: Ed Chen
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 3.2
>
>
> I can import a chunk of data into Cassandra table with COPY command like:
> COPY my_table (name, address) FROM my_file.csv WITH option='value' ... ;
> But I am not able to specify a finite TTL in COPY command with "USING TTL 
> 3600", for example. 



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

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

[aleksey]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: 2800bf1082e773daf0af29516b61c711acda626b
Parents: fa18880 bcd68b5
Author: Aleksey Yeschenko 
Authored: Fri Dec 18 23:30:16 2015 +
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:30:16 2015 +

--
 CHANGES.txt  |  1 +
 bin/cqlsh.py | 21 +++--
 2 files changed, 8 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2800bf10/CHANGES.txt
--
diff --cc CHANGES.txt
index 199e374,88ef42e..b4419fa
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 -2.2.5
 +3.0.3
 + * Add back support for 3rd party auth providers to bulk loader 
(CASSANDRA-10873)
 + * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
 + * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
 + * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)
 +Merged from 2.2:
+  * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813)
   * Add new types to Stress (CASSANDRA-9556)
   * Add property to allow listening on broadcast interface (CASSANDRA-9748)
   * Fix regression in split size on CqlInputFormat (CASSANDRA-10835)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2800bf10/bin/cqlsh.py
--

[1/3] cassandra git commit: (cqlsh) show correct column names for empty result sets

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 99880d22d -> 01b3508e0


(cqlsh) show correct column names for empty result sets

patch by Adam Holmberg; reviewed by Ariel Weisberg for CASSANDRA-9813


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

Branch: refs/heads/trunk
Commit: bcd68b546b7e449afd5f4233e01a45e0e4609307
Parents: 9dd2b5e
Author: Adam Holmberg 
Authored: Fri Dec 11 16:18:49 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:26:53 2015 +

--
 CHANGES.txt  |  1 +
 bin/cqlsh.py | 21 +++--
 2 files changed, 8 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bcd68b54/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1480960..88ef42e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.5
+ * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813)
  * Add new types to Stress (CASSANDRA-9556)
  * Add property to allow listening on broadcast interface (CASSANDRA-9748)
  * Fix regression in split size on CqlInputFormat (CASSANDRA-10835)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bcd68b54/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 1119289..427fc29 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -1242,7 +1242,7 @@ class Shell(cmd.Cmd):
 elif result:
 # CAS INSERT/UPDATE
 self.writeresult("")
-self.print_static_result(list(result), 
self.parse_for_table_meta(statement.query_string))
+self.print_static_result(result.column_names, list(result), 
self.parse_for_table_meta(statement.query_string))
 self.flush_output()
 return True, future
 
@@ -1256,7 +1256,7 @@ class Shell(cmd.Cmd):
 page = result.current_rows
 if page:
 num_rows += len(page)
-self.print_static_result(page, table_meta)
+self.print_static_result(result.column_names, page, 
table_meta)
 if result.has_more_pages:
 raw_input("---MORE---")
 result.fetch_next_page()
@@ -1265,7 +1265,7 @@ class Shell(cmd.Cmd):
 else:
 rows = list(result)
 num_rows = len(rows)
-self.print_static_result(rows, table_meta)
+self.print_static_result(result.column_names, rows, table_meta)
 self.writeresult("(%d rows)" % num_rows)
 
 if self.decoding_errors:
@@ -1275,18 +1275,11 @@ class Shell(cmd.Cmd):
 self.writeresult('%d more decoding errors suppressed.'
  % (len(self.decoding_errors) - 2), color=RED)
 
-def print_static_result(self, rows, table_meta):
-if not rows:
-if not table_meta:
-return
-# print header only
-colnames = table_meta.columns.keys()  # full header
-formatted_names = [self.myformat_colname(name, table_meta) for 
name in colnames]
-self.print_formatted_result(formatted_names, None)
+def print_static_result(self, column_names, rows, table_meta):
+if not column_names and not table_meta:
 return
-
-colnames = rows[0].keys()
-formatted_names = [self.myformat_colname(name, table_meta) for name in 
colnames]
+column_names = column_names or table_meta.columns.keys()
+formatted_names = [self.myformat_colname(name, table_meta) for name in 
column_names]
 formatted_values = [map(self.myformat_value, row.values()) for row in 
rows]
 
 if self.expand_enabled:

[1/2] cassandra git commit: (cqlsh) show correct column names for empty result sets

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 fa18880e7 -> 2800bf108


(cqlsh) show correct column names for empty result sets

patch by Adam Holmberg; reviewed by Ariel Weisberg for CASSANDRA-9813


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

Branch: refs/heads/cassandra-3.0
Commit: bcd68b546b7e449afd5f4233e01a45e0e4609307
Parents: 9dd2b5e
Author: Adam Holmberg 
Authored: Fri Dec 11 16:18:49 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:26:53 2015 +

--
 CHANGES.txt  |  1 +
 bin/cqlsh.py | 21 +++--
 2 files changed, 8 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bcd68b54/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1480960..88ef42e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.5
+ * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813)
  * Add new types to Stress (CASSANDRA-9556)
  * Add property to allow listening on broadcast interface (CASSANDRA-9748)
  * Fix regression in split size on CqlInputFormat (CASSANDRA-10835)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bcd68b54/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 1119289..427fc29 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -1242,7 +1242,7 @@ class Shell(cmd.Cmd):
 elif result:
 # CAS INSERT/UPDATE
 self.writeresult("")
-self.print_static_result(list(result), 
self.parse_for_table_meta(statement.query_string))
+self.print_static_result(result.column_names, list(result), 
self.parse_for_table_meta(statement.query_string))
 self.flush_output()
 return True, future
 
@@ -1256,7 +1256,7 @@ class Shell(cmd.Cmd):
 page = result.current_rows
 if page:
 num_rows += len(page)
-self.print_static_result(page, table_meta)
+self.print_static_result(result.column_names, page, 
table_meta)
 if result.has_more_pages:
 raw_input("---MORE---")
 result.fetch_next_page()
@@ -1265,7 +1265,7 @@ class Shell(cmd.Cmd):
 else:
 rows = list(result)
 num_rows = len(rows)
-self.print_static_result(rows, table_meta)
+self.print_static_result(result.column_names, rows, table_meta)
 self.writeresult("(%d rows)" % num_rows)
 
 if self.decoding_errors:
@@ -1275,18 +1275,11 @@ class Shell(cmd.Cmd):
 self.writeresult('%d more decoding errors suppressed.'
  % (len(self.decoding_errors) - 2), color=RED)
 
-def print_static_result(self, rows, table_meta):
-if not rows:
-if not table_meta:
-return
-# print header only
-colnames = table_meta.columns.keys()  # full header
-formatted_names = [self.myformat_colname(name, table_meta) for 
name in colnames]
-self.print_formatted_result(formatted_names, None)
+def print_static_result(self, column_names, rows, table_meta):
+if not column_names and not table_meta:
 return
-
-colnames = rows[0].keys()
-formatted_names = [self.myformat_colname(name, table_meta) for name in 
colnames]
+column_names = column_names or table_meta.columns.keys()
+formatted_names = [self.myformat_colname(name, table_meta) for name in 
column_names]
 formatted_values = [map(self.myformat_value, row.values()) for row in 
rows]
 
 if self.expand_enabled:

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

[aleksey]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: 2800bf1082e773daf0af29516b61c711acda626b
Parents: fa18880 bcd68b5
Author: Aleksey Yeschenko 
Authored: Fri Dec 18 23:30:16 2015 +
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:30:16 2015 +

--
 CHANGES.txt  |  1 +
 bin/cqlsh.py | 21 +++--
 2 files changed, 8 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2800bf10/CHANGES.txt
--
diff --cc CHANGES.txt
index 199e374,88ef42e..b4419fa
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 -2.2.5
 +3.0.3
 + * Add back support for 3rd party auth providers to bulk loader 
(CASSANDRA-10873)
 + * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653)
 + * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
 + * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)
 +Merged from 2.2:
+  * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813)
   * Add new types to Stress (CASSANDRA-9556)
   * Add property to allow listening on broadcast interface (CASSANDRA-9748)
   * Fix regression in split size on CqlInputFormat (CASSANDRA-10835)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2800bf10/bin/cqlsh.py
--

[jira] [Comment Edited] (CASSANDRA-10593) Unintended interactions between commitlog archiving and commitlog recycling

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko edited comment on CASSANDRA-10593 at 12/18/15 11:41 PM:
--

Committed as 
[3740f815c21254bd625ad1cbe8d47aa657727a83|https://github.com/apache/cassandra/commit/3740f815c21254bd625ad1cbe8d47aa657727a83]
 to 2.1 and merged with 2.2, 3.0, and trunk. Thanks.


was (Author: iamaleksey):
Committed to 
[3740f815c21254bd625ad1cbe8d47aa657727a83|https://github.com/apache/cassandra/commit/3740f815c21254bd625ad1cbe8d47aa657727a83]
 and merged with 2.2, 3.0, and trunk. Thanks.

> Unintended interactions between commitlog archiving and commitlog recycling
> ---
>
> Key: CASSANDRA-10593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10593
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: J.B. Langston
>Assignee: Ariel Weisberg
> Fix For: 2.1.13, 2.2.5, 3.2, 3.0.3
>
> Attachments: cassandra.yaml, commitlog_archiving.properties, 
> system.log
>
>
> Currently the comments in commitlog_archiving.properties suggest using either 
> cp or ln for the archive_command.  
> Using ln is problematic because commitlog recycling marks segments as 
> recycled once the corresponding memtables are flushed and Cassandra will no 
> longer replay them. This means it's only possible to do PITR on any records 
> that were written since the last flush.
> Using cp works, and this is currently how OpsCenter does for PITR, however 
> [~brandon.williams] has pointed out this could have some performance impact 
> because of the additional I/O overhead of copying the commitlog segments.
> Starting in 2.1, we can disable commit log recycling in cassandra.yaml so I 
> thought this would allow me to do PITR without the extra overhead of using 
> cp.  However, when I disable commitlog recycling and try to do a PITR, 
> Cassandra blows up when trying to replay the restored commit logs:
> {code}
> ERROR 16:56:42  Exception encountered during startup
> java.lang.IllegalStateException: Cannot safely construct descriptor for 
> segment, as name and header descriptors do not match ((4,1445878452545) vs 
> (4,1445876822565)): /opt/dse/backup/CommitLog-4-1445876822565.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:207)
>  ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116) 
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:352) 
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>  ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at com.datastax.bdp.DseModule.main(DseModule.java:75) 
> [dse-core-4.8.0.jar:4.8.0]
> java.lang.IllegalStateException: Cannot safely construct descriptor for 
> segment, as name and header descriptors do not match ((4,1445878452545) vs 
> (4,1445876822565)): /opt/dse/backup/CommitLog-4-1445876822565.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:207)
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:352)
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>   at com.datastax.bdp.DseModule.main(DseModule.java:75)
> Exception encountered during startup: Cannot safely construct descriptor for 
> segment, as name and header descriptors do not match ((4,1445878452545) vs 
> (4,1445876822565)): /opt/dse/backup/CommitLog-4-1445876822565.log
> INFO  16:56:42  DSE shutting down...
> INFO  16:56:42  All plugins are stopped.
> ERROR 16:56:42  Exception in thread Thread[Thread-2,5,main]
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.gms.Gossiper.addLocalApplicationState(Gossiper.java:1403)
>  ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at com.datastax.bdp.gms.DseState.setActiveStatus(DseState.java:196) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at com.datastax.bdp.server.DseDaemon.preStop(DseDaemon.java:426) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at com.datastax.bdp.server.DseDaemon.safeStop(DseDaemon.java:436) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at com.datastax.bdp.server.DseDaemon$1.run(DseDaemon.java:676) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at 

[jira] [Commented] (CASSANDRA-10593) Unintended interactions between commitlog archiving and commitlog recycling

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-10593:
---

Committed to 
[3740f815c21254bd625ad1cbe8d47aa657727a83|https://github.com/apache/cassandra/commit/3740f815c21254bd625ad1cbe8d47aa657727a83]
 and merged with 2.2, 3.0, and trunk. Thanks.

> Unintended interactions between commitlog archiving and commitlog recycling
> ---
>
> Key: CASSANDRA-10593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10593
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: J.B. Langston
>Assignee: Ariel Weisberg
> Fix For: 2.1.13, 2.2.5, 3.2, 3.0.3
>
> Attachments: cassandra.yaml, commitlog_archiving.properties, 
> system.log
>
>
> Currently the comments in commitlog_archiving.properties suggest using either 
> cp or ln for the archive_command.  
> Using ln is problematic because commitlog recycling marks segments as 
> recycled once the corresponding memtables are flushed and Cassandra will no 
> longer replay them. This means it's only possible to do PITR on any records 
> that were written since the last flush.
> Using cp works, and this is currently how OpsCenter does for PITR, however 
> [~brandon.williams] has pointed out this could have some performance impact 
> because of the additional I/O overhead of copying the commitlog segments.
> Starting in 2.1, we can disable commit log recycling in cassandra.yaml so I 
> thought this would allow me to do PITR without the extra overhead of using 
> cp.  However, when I disable commitlog recycling and try to do a PITR, 
> Cassandra blows up when trying to replay the restored commit logs:
> {code}
> ERROR 16:56:42  Exception encountered during startup
> java.lang.IllegalStateException: Cannot safely construct descriptor for 
> segment, as name and header descriptors do not match ((4,1445878452545) vs 
> (4,1445876822565)): /opt/dse/backup/CommitLog-4-1445876822565.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:207)
>  ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116) 
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:352) 
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>  ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at com.datastax.bdp.DseModule.main(DseModule.java:75) 
> [dse-core-4.8.0.jar:4.8.0]
> java.lang.IllegalStateException: Cannot safely construct descriptor for 
> segment, as name and header descriptors do not match ((4,1445878452545) vs 
> (4,1445876822565)): /opt/dse/backup/CommitLog-4-1445876822565.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeRestoreArchive(CommitLogArchiver.java:207)
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:116)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:352)
>   at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537)
>   at com.datastax.bdp.DseModule.main(DseModule.java:75)
> Exception encountered during startup: Cannot safely construct descriptor for 
> segment, as name and header descriptors do not match ((4,1445878452545) vs 
> (4,1445876822565)): /opt/dse/backup/CommitLog-4-1445876822565.log
> INFO  16:56:42  DSE shutting down...
> INFO  16:56:42  All plugins are stopped.
> ERROR 16:56:42  Exception in thread Thread[Thread-2,5,main]
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.gms.Gossiper.addLocalApplicationState(Gossiper.java:1403)
>  ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>   at com.datastax.bdp.gms.DseState.setActiveStatus(DseState.java:196) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at com.datastax.bdp.server.DseDaemon.preStop(DseDaemon.java:426) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at com.datastax.bdp.server.DseDaemon.safeStop(DseDaemon.java:436) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at com.datastax.bdp.server.DseDaemon$1.run(DseDaemon.java:676) 
> ~[dse-core-4.8.0.jar:4.8.0]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_31]
> {code}
> For the sake of completeness, I also tested using cp for the archive_command 
> and commitlog recycling disabled, and PITR works as expected, but this of 
> course defeats the point.
> It would be good to have some 

cassandra git commit: Fix bugs in commit log archiving startup behavior

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 124f1bd26 -> 3740f815c


Fix bugs in commit log archiving startup behavior

patch by Ariel Weisberg; reviewed by Branimir Lambov for CASSANDRA-10593


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

Branch: refs/heads/cassandra-2.1
Commit: 3740f815c21254bd625ad1cbe8d47aa657727a83
Parents: 124f1bd
Author: Ariel Weisberg 
Authored: Thu Dec 3 14:37:26 2015 -0500
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:37:05 2015 +

--
 CHANGES.txt|  1 +
 .../cassandra/db/commitlog/CommitLogArchiver.java  | 17 ++---
 .../db/commitlog/CommitLogSegmentManager.java  |  3 ++-
 3 files changed, 13 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3740f815/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 90f1bca..581784e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.13
+ * Fix bugs in commit log archiving startup behavior (CASSANDRA-10593)
  * (cqlsh) further optimise COPY FROM (CASSANDRA-9302)
  * Allow CREATE TABLE WITH ID (CASSANDRA-9179)
  * Make Stress compiles within eclipse (CASSANDRA-10807)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3740f815/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
index 91f3179..8d9a6b3 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
@@ -1,5 +1,5 @@
 /*
- * 
+ *
  * Licensed to the Apache Software Foundation (ASF) under one
  * or more contributor license agreements.  See the NOTICE file
  * distributed with this work for additional information
@@ -7,16 +7,16 @@
  * to you under the Apache License, Version 2.0 (the
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
- * 
+ *
  *   http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *
  * Unless required by applicable law or agreed to in writing,
  * software distributed under the License is distributed on an
  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  * KIND, either express or implied.  See the License for the
  * specific language governing permissions and limitations
  * under the License.
- * 
+ *
  */
 package org.apache.cassandra.db.commitlog;
 
@@ -173,10 +173,13 @@ public class CommitLogArchiver
 }
 catch (ExecutionException e)
 {
-if (e.getCause() instanceof IOException)
+if (e.getCause() instanceof RuntimeException)
 {
-logger.error("Looks like the archiving of file {} failed 
earlier, cassandra is going to ignore this segment for now.", name);
-return false;
+if (e.getCause().getCause() instanceof IOException)
+{
+logger.error("Looks like the archiving of file {} failed 
earlier, cassandra is going to ignore this segment for now.", name, 
e.getCause().getCause());
+return false;
+}
 }
 throw new RuntimeException(e);
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3740f815/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
--
diff --git 
a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
index 9310d67..0ea54ab 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
@@ -383,7 +383,8 @@ public class CommitLogSegmentManager
 void recycleSegment(final File file)
 {
 if (isCapExceeded()
-|| 
CommitLogDescriptor.fromFileName(file.getName()).getMessagingVersion() != 
MessagingService.current_version)
+|| 
CommitLogDescriptor.fromFileName(file.getName()).getMessagingVersion() != 
MessagingService.current_version
+|| !DatabaseDescriptor.getCommitLogSegmentRecyclingEnabled())
 {
 // (don't decrease managed size, since this was never a "live" 
segment)
 

[1/2] cassandra git commit: Fix bugs in commit log archiving startup behavior

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 bcd68b546 -> c26b39716


Fix bugs in commit log archiving startup behavior

patch by Ariel Weisberg; reviewed by Branimir Lambov for CASSANDRA-10593


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

Branch: refs/heads/cassandra-2.2
Commit: 3740f815c21254bd625ad1cbe8d47aa657727a83
Parents: 124f1bd
Author: Ariel Weisberg 
Authored: Thu Dec 3 14:37:26 2015 -0500
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:37:05 2015 +

--
 CHANGES.txt|  1 +
 .../cassandra/db/commitlog/CommitLogArchiver.java  | 17 ++---
 .../db/commitlog/CommitLogSegmentManager.java  |  3 ++-
 3 files changed, 13 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3740f815/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 90f1bca..581784e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.13
+ * Fix bugs in commit log archiving startup behavior (CASSANDRA-10593)
  * (cqlsh) further optimise COPY FROM (CASSANDRA-9302)
  * Allow CREATE TABLE WITH ID (CASSANDRA-9179)
  * Make Stress compiles within eclipse (CASSANDRA-10807)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3740f815/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
index 91f3179..8d9a6b3 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
@@ -1,5 +1,5 @@
 /*
- * 
+ *
  * Licensed to the Apache Software Foundation (ASF) under one
  * or more contributor license agreements.  See the NOTICE file
  * distributed with this work for additional information
@@ -7,16 +7,16 @@
  * to you under the Apache License, Version 2.0 (the
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
- * 
+ *
  *   http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *
  * Unless required by applicable law or agreed to in writing,
  * software distributed under the License is distributed on an
  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  * KIND, either express or implied.  See the License for the
  * specific language governing permissions and limitations
  * under the License.
- * 
+ *
  */
 package org.apache.cassandra.db.commitlog;
 
@@ -173,10 +173,13 @@ public class CommitLogArchiver
 }
 catch (ExecutionException e)
 {
-if (e.getCause() instanceof IOException)
+if (e.getCause() instanceof RuntimeException)
 {
-logger.error("Looks like the archiving of file {} failed 
earlier, cassandra is going to ignore this segment for now.", name);
-return false;
+if (e.getCause().getCause() instanceof IOException)
+{
+logger.error("Looks like the archiving of file {} failed 
earlier, cassandra is going to ignore this segment for now.", name, 
e.getCause().getCause());
+return false;
+}
 }
 throw new RuntimeException(e);
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3740f815/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
--
diff --git 
a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
index 9310d67..0ea54ab 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManager.java
@@ -383,7 +383,8 @@ public class CommitLogSegmentManager
 void recycleSegment(final File file)
 {
 if (isCapExceeded()
-|| 
CommitLogDescriptor.fromFileName(file.getName()).getMessagingVersion() != 
MessagingService.current_version)
+|| 
CommitLogDescriptor.fromFileName(file.getName()).getMessagingVersion() != 
MessagingService.current_version
+|| !DatabaseDescriptor.getCommitLogSegmentRecyclingEnabled())
 {
 // (don't decrease managed size, since this was never a "live" 
segment)
 

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

[aleksey]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: c26b3971622f55589f4f080516c9e01311b4e7b1
Parents: bcd68b5 3740f81
Author: Aleksey Yeschenko 
Authored: Fri Dec 18 23:38:40 2015 +
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:38:40 2015 +

--
 CHANGES.txt | 1 +
 .../apache/cassandra/db/commitlog/CommitLogArchiver.java| 9 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c26b3971/CHANGES.txt
--
diff --cc CHANGES.txt
index 88ef42e,581784e..1ff1a5c
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,12 -1,5 +1,13 @@@
 -2.1.13
 +2.2.5
 + * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813)
 + * Add new types to Stress (CASSANDRA-9556)
 + * Add property to allow listening on broadcast interface (CASSANDRA-9748)
 + * Fix regression in split size on CqlInputFormat (CASSANDRA-10835)
 + * Better handling of SSL connection errors inter-node (CASSANDRA-10816)
 + * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474)
 + * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761)
 +Merged from 2.1:
+  * Fix bugs in commit log archiving startup behavior (CASSANDRA-10593)
   * (cqlsh) further optimise COPY FROM (CASSANDRA-9302)
   * Allow CREATE TABLE WITH ID (CASSANDRA-9179)
   * Make Stress compiles within eclipse (CASSANDRA-10807)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c26b3971/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java
--

[jira] [Commented] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-10887:
---

I have added a patch along with many unit tests. Looks like the issue with 
moves is there since the feature was added in CASSANDRA-1427. 
This patch fixes the following issues
1) It will add the correct endpoints to the pending range not just the endpoint 
which is moving. 
2) It will remove the ranges which the endpoint is already getting. Eg: If an 
endpoint is getting range 10-20 before the move and needs range say 15-20 after 
the move, it will only add 15-20. 

I think 2) will solve the problem of duplicate endpoints in pending endpoint 
and natural endpoint. Thought I have not tested this part. 

Most of the patch is unit tests which simulate many types of moves. We should 
see if there is any case of move which is missing. 

PS: I have not tested this patch apart from the unit test :)

> Pending range calculator gives wrong pending ranges for moves
> -
>
> Key: CASSANDRA-10887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>Assignee: sankalp kohli
>Priority: Critical
> Attachments: CASSANDRA-10887.diff
>
>
> My understanding is the PendingRangeCalculator is meant to calculate who 
> should receive extra writes during range movements. However, it adds the 
> wrong ranges for moves. An extreme example of this can be seen in the 
> following reproduction. Create a 5 node cluster (I did this on 2.0.16 and 
> 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and 
> immediately kill -9 it. Now you see a node as down and moving in the ring. 
> Try a quorum write for a partition that is stored on that node - it will fail 
> with a timeout. Further, all CAS reads or writes fail immediately with 
> unavailable exception because they attempt to include the moving node twice. 
> This is likely to be the cause of CASSANDRA-10423.
> In my example I had this ring:
> 127.0.0.1  rack1   Up Normal  170.97 KB   20.00%  
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  124.06 KB   20.00%  
> -5534023222112865485
> 127.0.0.3  rack1   Down   Moving  108.7 KB40.00%  
> 1844674407370955160
> 127.0.0.4  rack1   Up Normal  142.58 KB   0.00%   
> 1844674407370955161
> 127.0.0.5  rack1   Up Normal  118.64 KB   20.00%  
> 5534023222112865484
> Node 3 was moving to -1844674407370955160. I added logging to print the 
> pending and natural endpoints. For ranges owned by node 3, node 3 appeared in 
> pending and natural endpoints. The blockFor is increased to 3 so we’re 
> effectively doing CL.ALL operations. This manifests as write timeouts and CAS 
> unavailables when the node is down.
> The correct pending range for this scenario is node 1 is gaining the range 
> (-1844674407370955160, 1844674407370955160). So node 1 should be added as a 
> destination for writes and CAS for this range, not node 3.



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

[jira] [Commented] (CASSANDRA-9428) Implement hints compression

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-9428:


I've pushed up some additional commits to my branch addressing your points. 
Thanks for suggesting I exercise all compressor types, it uncovered some 
problems with the way I was allocating buffers, which I fixed.

> Implement hints compression
> ---
>
> Key: CASSANDRA-9428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9428
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination
>Reporter: Aleksey Yeschenko
>Assignee: Blake Eggleston
> Fix For: 3.0.x
>
>
> CASSANDRA-6230 is being implemented with compression in mind, but it's not 
> going to be implemented by the original ticket.
> Adding it on top should be relatively straight-forward, and important, since 
> there are several users in the wild that use compression interface for 
> encryption purposes. DSE is one of them (but isn't the only one). Losing 
> encryption capabilities would be a regression.



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

[jira] [Commented] (CASSANDRA-10904) Add upgrade procedure related to new role based access control in NEWS.txt

[Kai Wang (JIRA)]

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

Kai Wang commented on CASSANDRA-10904:
--

It would be helpful if the doc can include:
1. what are the "legacy tables" that should be dropped.
2. how to verify if the schema upgrade is successful. In my case, I get to know 
this change long after upgrade is done. There might be other errors in 
system.log but unrelated to the schema upgrade. Is there any "select this 
table, if abc and xyz are there, you are good" kind of way?

> Add upgrade procedure related to new role based access control in NEWS.txt
> --
>
> Key: CASSANDRA-10904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10904
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: Reynald Bourtembourg
>  Labels: documentation
>
> The upgrade procedure related to new role based access control feature in 
> Cassandra 2.2 is not documented in NEWS.txt file.
> The upgrade procedure is described in this blog post:
> http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra



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

[jira] [Created] (CASSANDRA-10905) secondary_indexes_test.py:TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query flaps on 3.0+

[Jim Witschey (JIRA)]

Jim Witschey created CASSANDRA-10905:


 Summary: 
secondary_indexes_test.py:TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query
 flaps on 3.0+
 Key: CASSANDRA-10905
 URL: https://issues.apache.org/jira/browse/CASSANDRA-10905
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jim Witschey


This test flaps when it expects to find 1 of each of several trace events, but 
doesn't find some of them. I noticed it on 3.0:

http://cassci.datastax.com/job/cassandra-3.0_dtest/438/testReport/junit/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query/history/

But I've also seen it on trunk, so it would appear it hasn't been fixed:

http://cassci.datastax.com/job/trunk_dtest/831/testReport/junit/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query/




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

[jira] [Commented] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-8072:
-

I've reproduced it on 2.1 HEAD with this dtest, which follows the steps of 
CASSANDRA-8422:

{code}
def decommissioned_wiped_node_can_gossip_to_single_seed_test(self):
"""
@jira_ticket CASSANDRA-8072
@jira_ticket CASSANDRA-8422
Test that if we decommission a node, kill it and wipe its data, it can 
join a cluster with a single
seed node.
"""
cluster = self.cluster
cluster.populate(1)
cluster.start(wait_for_binary_proto=True)

# Add a new node, bootstrap=True ensures that it is not a seed
node2 = new_node(cluster, bootstrap=True)
node2.start(wait_for_binary_proto=True, wait_other_notice=True)

# Decommision the new node and kill it
node2.decommission()
node2.stop(gently=False)

# Wipe its data
data_dir = os.path.join(node2.get_path(), 'data')
commitlog_dir = os.path.join(node2.get_path(), 'commitlogs')
debug("Deleting {}".format(data_dir))
shutil.rmtree(data_dir)
shutil.rmtree(commitlog_dir)

# Now start it, it should be allowed to join
mark = node2.mark_log()
node2.start(wait_other_notice=False)
node2.watch_log_for("JOINING:", from_mark=mark)
{code} 

This results in the following exception in node2:

{code}
ERROR [main] 2015-12-18 16:21:07,357 CassandraDaemon.java:581 - Exception 
encountered during startup
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337) 
~[main/:na]
at 
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:721) 
~[main/:na]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:612) 
~[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:389) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:653) 
[main/:na]
WARN  [StorageServiceShutdownHook] 2015-12-18 16:21:07,360 Gossiper.java:1454 - 
No local state or state is in silent shutdown, not announcing shutdown
INFO  [StorageServiceShutdownHook] 2015-12-18 16:21:07,361 
MessagingService.java:734 - Waiting for messaging service to quiesce
INFO  [ACCEPT-/127.0.0.2] 2015-12-18 16:21:07,361 MessagingService.java:1018 - 
MessagingService has terminated the accept() thread
{code}

> Exception during startup: Unable to gossip with any seeds
> -
>
> Key: CASSANDRA-8072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8072
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
>Reporter: Ryan Springer
>Assignee: Stefania
> Fix For: 2.1.x
>
> Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, 
> cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, 
> casandra-system-log-with-assert-patch.log, screenshot-1.png, 
> trace_logs.tar.bz2
>
>
> When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster 
> in either ec2 or locally, an error occurs sometimes with one of the nodes 
> refusing to start C*.  The error in the /var/log/cassandra/system.log is:
> ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) 
> Exception encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444)
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:609)
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:502)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
>  INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java 
> (line 1279) Announcing shutdown
>  INFO [StorageServiceShutdownHook] 

cassandra git commit: (cqlsh) allow setting TTL with COPY

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 622d1f7c0 -> 99880d22d


(cqlsh) allow setting TTL with COPY

patch by Stefania Alborghetti; reviewed by Adam Holmberg for
CASSANDRA-9494


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

Branch: refs/heads/trunk
Commit: 99880d22de0023081a6d5829bef991eb96f7c342
Parents: 622d1f7
Author: Stefania Alborghetti 
Authored: Thu Nov 19 14:51:40 2015 +0800
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:14:15 2015 +

--
 CHANGES.txt| 1 +
 bin/cqlsh.py   | 3 ++-
 pylib/cqlshlib/copyutil.py | 5 +
 3 files changed, 8 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/99880d22/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5cbbb62..47863e9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.2
+ * (cqlsh) allow setting TTL with COPY (CASSANDRA-9494)
  * Fix EstimatedHistogram creation in nodetool tablehistograms 
(CASSANDRA-10859)
  * Establish bootstrap stream sessions sequentially (CASSANDRA-6992)
  * Sort compactionhistory output by timestamp (CASSANDRA-10464)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/99880d22/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 0f6b39c..e48857d 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -460,7 +460,7 @@ def complete_copy_column_names(ctxt, cqlsh):
 
 COPY_COMMON_OPTIONS = ['DELIMITER', 'QUOTE', 'ESCAPE', 'HEADER', 'NULL',
'MAXATTEMPTS', 'REPORTFREQUENCY']
-COPY_FROM_OPTIONS = ['CHUNKSIZE', 'INGESTRATE', 'MAXBATCHSIZE', 'MINBATCHSIZE']
+COPY_FROM_OPTIONS = ['CHUNKSIZE', 'INGESTRATE', 'MAXBATCHSIZE', 
'MINBATCHSIZE', 'TTL']
 COPY_TO_OPTIONS = ['ENCODING', 'TIMEFORMAT', 'PAGESIZE', 'PAGETIMEOUT', 
'MAXREQUESTS']
 
 
@@ -1812,6 +1812,7 @@ class Shell(cmd.Cmd):
   MAXBATCHSIZE=20 - the maximum size of an import batch (COPY 
FROM)
   MINBATCHSIZE=2  - the minimum size of an import batch (COPY 
FROM)
   REPORTFREQUENCY=0.25- the frequency with which we display status 
updates in seconds
+  TTL=3600- the time to live in seconds, by default 
data will not expire (COPY FROM)
 
 When entering CSV data on STDIN, you can use the sequence "\."
 on a line by itself to end the data input.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/99880d22/pylib/cqlshlib/copyutil.py
--
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index a117ec3..d7d7790 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -83,6 +83,7 @@ def parse_options(shell, opts):
 csv_options['maxbatchsize'] = int(opts.pop('maxbatchsize', 20))
 csv_options['minbatchsize'] = int(opts.pop('minbatchsize', 2))
 csv_options['reportfrequency'] = float(opts.pop('reportfrequency', 0.25))
+csv_options['ttl'] = int(opts.pop('ttl', -1))
 
 return csv_options, dialect_options, opts
 
@@ -1063,6 +1064,7 @@ class ImportProcess(ChildProcess):
 self.max_attempts = csv_options['maxattempts']
 self.min_batch_size = csv_options['minbatchsize']
 self.max_batch_size = csv_options['maxbatchsize']
+self.ttl = csv_options['ttl']
 self._session = None
 
 @property
@@ -1140,6 +1142,9 @@ class ImportProcess(ChildProcess):
 protect_name(self.cf),
 ', 
'.join(protect_names(self.columns),),
 ', '.join(['?' for _ 
in self.columns]))
+if self.ttl >= 0:
+query += 'USING TTL %s' % (self.ttl,)
+
 query_statement = self.session.prepare(query)
 conv = ImportConversion(self, table_meta, query_statement)
 

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

[aleksey]

Merge branch 'cassandra-3.0' into trunk


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

Branch: refs/heads/trunk
Commit: 01b3508e0f0025bb859d96fb163ff457d3d94662
Parents: 99880d2 2800bf1
Author: Aleksey Yeschenko 
Authored: Fri Dec 18 23:30:39 2015 +
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:30:39 2015 +

--
 CHANGES.txt  |  1 +
 bin/cqlsh.py | 21 +++--
 2 files changed, 8 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/01b3508e/CHANGES.txt
--
diff --cc CHANGES.txt
index 47863e9,b4419fa..0df24d5
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -27,8 -4,13 +27,9 @@@ Merged from 3.0
   * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes 
(CASSANDRA-1837)
   * Fix sstableloader not working with upper case keyspace name 
(CASSANDRA-10806)
  Merged from 2.2:
+  * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813)
   * Add new types to Stress (CASSANDRA-9556)
   * Add property to allow listening on broadcast interface (CASSANDRA-9748)
 - * Fix regression in split size on CqlInputFormat (CASSANDRA-10835)
 - * Better handling of SSL connection errors inter-node (CASSANDRA-10816)
 - * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474)
 - * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761)
  Merged from 2.1:
   * (cqlsh) further optimise COPY FROM (CASSANDRA-9302)
   * Allow CREATE TABLE WITH ID (CASSANDRA-9179)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/01b3508e/bin/cqlsh.py
--

cassandra git commit: (cqlsh) show correct column names for empty result sets

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 9dd2b5ea0 -> bcd68b546


(cqlsh) show correct column names for empty result sets

patch by Adam Holmberg; reviewed by Ariel Weisberg for CASSANDRA-9813


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

Branch: refs/heads/cassandra-2.2
Commit: bcd68b546b7e449afd5f4233e01a45e0e4609307
Parents: 9dd2b5e
Author: Adam Holmberg 
Authored: Fri Dec 11 16:18:49 2015 -0600
Committer: Aleksey Yeschenko 
Committed: Fri Dec 18 23:26:53 2015 +

--
 CHANGES.txt  |  1 +
 bin/cqlsh.py | 21 +++--
 2 files changed, 8 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bcd68b54/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1480960..88ef42e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.5
+ * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813)
  * Add new types to Stress (CASSANDRA-9556)
  * Add property to allow listening on broadcast interface (CASSANDRA-9748)
  * Fix regression in split size on CqlInputFormat (CASSANDRA-10835)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bcd68b54/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 1119289..427fc29 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -1242,7 +1242,7 @@ class Shell(cmd.Cmd):
 elif result:
 # CAS INSERT/UPDATE
 self.writeresult("")
-self.print_static_result(list(result), 
self.parse_for_table_meta(statement.query_string))
+self.print_static_result(result.column_names, list(result), 
self.parse_for_table_meta(statement.query_string))
 self.flush_output()
 return True, future
 
@@ -1256,7 +1256,7 @@ class Shell(cmd.Cmd):
 page = result.current_rows
 if page:
 num_rows += len(page)
-self.print_static_result(page, table_meta)
+self.print_static_result(result.column_names, page, 
table_meta)
 if result.has_more_pages:
 raw_input("---MORE---")
 result.fetch_next_page()
@@ -1265,7 +1265,7 @@ class Shell(cmd.Cmd):
 else:
 rows = list(result)
 num_rows = len(rows)
-self.print_static_result(rows, table_meta)
+self.print_static_result(result.column_names, rows, table_meta)
 self.writeresult("(%d rows)" % num_rows)
 
 if self.decoding_errors:
@@ -1275,18 +1275,11 @@ class Shell(cmd.Cmd):
 self.writeresult('%d more decoding errors suppressed.'
  % (len(self.decoding_errors) - 2), color=RED)
 
-def print_static_result(self, rows, table_meta):
-if not rows:
-if not table_meta:
-return
-# print header only
-colnames = table_meta.columns.keys()  # full header
-formatted_names = [self.myformat_colname(name, table_meta) for 
name in colnames]
-self.print_formatted_result(formatted_names, None)
+def print_static_result(self, column_names, rows, table_meta):
+if not column_names and not table_meta:
 return
-
-colnames = rows[0].keys()
-formatted_names = [self.myformat_colname(name, table_meta) for name in 
colnames]
+column_names = column_names or table_meta.columns.keys()
+formatted_names = [self.myformat_colname(name, table_meta) for name in 
column_names]
 formatted_values = [map(self.myformat_value, row.values()) for row in 
rows]
 
 if self.expand_enabled: