date:20150622

[jira] [Updated] (CASSANDRA-9607) Get high load after upgrading from 2.1.3 to cassandra 2.1.6

2015-06-22 Thread Jonathan Ellis (JIRA)


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

Jonathan Ellis updated CASSANDRA-9607:
--
Fix Version/s: (was: 2.2.0 rc2)
   2.2.x

 Get high load after upgrading from 2.1.3 to cassandra 2.1.6
 ---

 Key: CASSANDRA-9607
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9607
 Project: Cassandra
  Issue Type: Bug
 Environment: OS: 
 CentOS 6 * 4
 Ubuntu 14.04 * 2
 JDK: Oracle JDK 7, Oracle JDK 8
 VM: Azure VM Standard A3 * 6
 RAM: 7 GB
 Cores: 4
Reporter: Study Hsueh
Assignee: Tyler Hobbs
Priority: Critical
 Fix For: 2.1.x, 2.2.x

 Attachments: cassandra.yaml, load.png, log.zip, schema.zip


 After upgrading cassandra version from 2.1.3 to 2.1.6, the average load of my 
 cassandra cluster grows from 0.x~1.x to 3.x~6.x. 
 What kind of additional information should I provide for this problem?



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

[jira] [Commented] (CASSANDRA-9102) Consistency levels such as non-local quorum need better tests

2015-06-22 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-9102:
---

Sorry I am late to commenting on this. I think this is adding a lot of coverage
we don't have. The classes that concern me on the read and write path are
AbstractReadExecutor, and the StorageProxy read/write path. My beef with the
coverage there was that there is no unit test coverage before this task.

As far as I can tell those have little/no unit test coverage because they
aren't testable due to an inability to mock the entire thing. So that leads to
a dtest trying to hit all those paths. Even though it's a dtest it would be
helpful for it to behave more like a unit test when testing each branch. So
rather then having sessions racing and checking for the correct result of the
race (which may or may not race all) construct a scenario where you know
specific code will run. This will make it fail every time instead of just some
of the time when there is a bug. I think our focus for that kind of race would
be better handled by the kitchen sink harness which runs for a long time and
not on every commit.

Maybe from a unit testing (via dtests) perspective we want a way to blackhole
writes to part of the cluster to force recovery paths without failing nodes?
Otherwise from a dtest you would have to kill a node, do the write, and then
bring it back, in order to know the state of the node when you go to have it
participate in a read/write. This is all working around the fact that you can't
write it as a unit test without invasive refactoring (and maybe that is the
answer). I am kind of warming up to the idea of being able to ask a node to do
something like that from a dtest.

Consistency levels such as non-local quorum need better tests
-

Key: CASSANDRA-9102
URL: https://issues.apache.org/jira/browse/CASSANDRA-9102
Project: Cassandra
Issue Type: Test
Reporter: Ariel Weisberg
Assignee: Stefania

We didn't catch unit testing for this functionality. There is dtest
consistency_test but it doesn't cover non-local functionality.

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

[jira] [Updated] (CASSANDRA-9558) Cassandra-stress regression in 2.2

2015-06-22 Thread Jonathan Ellis (JIRA)


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

Jonathan Ellis updated CASSANDRA-9558:
--
Fix Version/s: (was: 2.2.0 rc2)
   2.2.x

 Cassandra-stress regression in 2.2
 --

 Key: CASSANDRA-9558
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9558
 Project: Cassandra
  Issue Type: Bug
Reporter: Alan Boudreault
 Fix For: 2.2.x

 Attachments: 2.1.log, 2.2.log, CASSANDRA-9558-2.patch, 
 CASSANDRA-9558-ProtocolV2.patch, atolber-CASSANDRA-9558-stress.tgz, 
 atolber-trunk-driver-coalescing-disabled.txt, 
 stress-2.1-java-driver-2.0.9.2.log, stress-2.1-java-driver-2.2+PATCH.log, 
 stress-2.1-java-driver-2.2.log, stress-2.2-java-driver-2.2+PATCH.log, 
 stress-2.2-java-driver-2.2.log


 We are seeing some regression in performance when using cassandra-stress 2.2. 
 You can see the difference at this url:
 http://riptano.github.io/cassandra_performance/graph_v5/graph.html?stats=stress_regression.jsonmetric=op_rateoperation=1_writesmoothing=1show_aggregates=truexmin=0xmax=108.57ymin=0ymax=168147.1
 The cassandra version of the cluster doesn't seem to have any impact. 
 //cc [~tjake] [~benedict]



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

[jira] [Updated] (CASSANDRA-9558) Cassandra-stress regression in 2.2

2015-06-22 Thread Jonathan Ellis (JIRA)


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

Jonathan Ellis updated CASSANDRA-9558:
--
Assignee: T Jake Luciani

 Cassandra-stress regression in 2.2
 --

 Key: CASSANDRA-9558
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9558
 Project: Cassandra
  Issue Type: Bug
Reporter: Alan Boudreault
Assignee: T Jake Luciani
 Fix For: 2.2.x

 Attachments: 2.1.log, 2.2.log, CASSANDRA-9558-2.patch, 
 CASSANDRA-9558-ProtocolV2.patch, atolber-CASSANDRA-9558-stress.tgz, 
 atolber-trunk-driver-coalescing-disabled.txt, 
 stress-2.1-java-driver-2.0.9.2.log, stress-2.1-java-driver-2.2+PATCH.log, 
 stress-2.1-java-driver-2.2.log, stress-2.2-java-driver-2.2+PATCH.log, 
 stress-2.2-java-driver-2.2.log


 We are seeing some regression in performance when using cassandra-stress 2.2. 
 You can see the difference at this url:
 http://riptano.github.io/cassandra_performance/graph_v5/graph.html?stats=stress_regression.jsonmetric=op_rateoperation=1_writesmoothing=1show_aggregates=truexmin=0xmax=108.57ymin=0ymax=168147.1
 The cassandra version of the cluster doesn't seem to have any impact. 
 //cc [~tjake] [~benedict]



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

[jira] [Updated] (CASSANDRA-9624) unable to bootstrap; streaming fails with NullPointerException

2015-06-22 Thread Philip Thompson (JIRA)


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

Philip Thompson updated CASSANDRA-9624:
---
Assignee: Yuki Morishita

 unable to bootstrap; streaming fails with NullPointerException
 --

 Key: CASSANDRA-9624
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9624
 Project: Cassandra
  Issue Type: Bug
 Environment: Debian Jessie, 7u79-2.5.5-1~deb8u1, Cassandra 2.1.3
Reporter: Eric Evans
Assignee: Yuki Morishita
 Fix For: 2.1.x


 When attempting to bootstrap a new node into a 2.1.3 cluster, the stream 
 source fails with a {{NullPointerException}}:
 {noformat}
 ERROR [STREAM-IN-/10.xx.x.xxx] 2015-06-13 00:02:01,264 StreamSession.java:477 
 - [Stream #60e8c120-
 115f-11e5-9fee-] Streaming error occurred
 java.lang.NullPointerException: null
 at 
 org.apache.cassandra.io.sstable.SSTableReader.getPositionsForRanges(SSTableReader.java:1277)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.getSSTableSectionsForRanges(StreamSession.java:313)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.addTransferRanges(StreamSession.java:266)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.prepare(StreamSession.java:493) 
 ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:425)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:251)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
 INFO  [STREAM-IN-/10.xx.x.xxx] 2015-06-13 00:02:01,265 
 StreamResultFuture.java:180 - [Stream #60e8c120-115f-11e5-9fee-] 
 Session with /10.xx.x.xx1 is complete
 {noformat}



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

[jira] [Updated] (CASSANDRA-9624) unable to bootstrap; streaming fails with NullPointerException

2015-06-22 Thread Philip Thompson (JIRA)


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

Philip Thompson updated CASSANDRA-9624:
---
Reproduced In: 2.1.3
Fix Version/s: 2.1.x

 unable to bootstrap; streaming fails with NullPointerException
 --

 Key: CASSANDRA-9624
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9624
 Project: Cassandra
  Issue Type: Bug
 Environment: Debian Jessie, 7u79-2.5.5-1~deb8u1, Cassandra 2.1.3
Reporter: Eric Evans
 Fix For: 2.1.x


 When attempting to bootstrap a new node into a 2.1.3 cluster, the stream 
 source fails with a {{NullPointerException}}:
 {noformat}
 ERROR [STREAM-IN-/10.xx.x.xxx] 2015-06-13 00:02:01,264 StreamSession.java:477 
 - [Stream #60e8c120-
 115f-11e5-9fee-] Streaming error occurred
 java.lang.NullPointerException: null
 at 
 org.apache.cassandra.io.sstable.SSTableReader.getPositionsForRanges(SSTableReader.java:1277)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.getSSTableSectionsForRanges(StreamSession.java:313)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.addTransferRanges(StreamSession.java:266)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.prepare(StreamSession.java:493) 
 ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:425)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at 
 org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:251)
  ~[apache-cassandra-2.1.3.jar:2.1.3]
 at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
 INFO  [STREAM-IN-/10.xx.x.xxx] 2015-06-13 00:02:01,265 
 StreamResultFuture.java:180 - [Stream #60e8c120-115f-11e5-9fee-] 
 Session with /10.xx.x.xx1 is complete
 {noformat}



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

[jira] [Updated] (CASSANDRA-9132) resumable_bootstrap_test can hang

2015-06-22 Thread T Jake Luciani (JIRA)


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

T Jake Luciani updated CASSANDRA-9132:
--
Fix Version/s: (was: 2.0.16)
   2.0.x

 resumable_bootstrap_test can hang
 -

 Key: CASSANDRA-9132
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9132
 Project: Cassandra
  Issue Type: Bug
  Components: Tests
Reporter: Tyler Hobbs
Assignee: Yuki Morishita
 Fix For: 2.1.6, 2.0.x, 2.2.0 rc1

 Attachments: 9132-2.0.txt, 9132-followup-2.0.txt


 The {{bootstrap_test.TestBootstrap.resumable_bootstrap_test}} can hang 
 sometimes.  It looks like the following line never completes:
 {noformat}
 node3.watch_log_for(Listening for thrift clients...)
 {noformat}
 I'm not familiar enough with the recent bootstrap changes to know why that's 
 not happening.



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

Git Push Summary

2015-06-22 Thread jake

Repository: cassandra
Updated Tags:  refs/tags/2.0.16-tentative [deleted] 23e66a9d1

[jira] [Updated] (CASSANDRA-9618) Consider deprecating sstable2json/json2sstable in 2.2

2015-06-22 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-9618:

Attachment: 0001-Deprecate-sstable2json-and-json2sstable.patch

Simple patch that adds a warning to the 2 tools and document the deprecation in 
the changes file.

 Consider deprecating sstable2json/json2sstable in 2.2
 -

 Key: CASSANDRA-9618
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9618
 Project: Cassandra
  Issue Type: Task
Reporter: Sylvain Lebresne
 Fix For: 2.2.0 rc2

 Attachments: 0001-Deprecate-sstable2json-and-json2sstable.patch


 The rational is explained in CASSANDRA-7464 but to rephrase a bit:
 * json2sstable is pretty much useless, {{CQLSSTableWriter}} is way more 
 flexible if you need to write sstable directly.
 * sstable2json is really only potentially useful for debugging, but it's 
 pretty bad at that (it's output is not really all that helpul in modern 
 Cassandra in particular).
 Now, it happens that updating those tool for CASSANDRA-8099, while possible, 
 is a bit involved. So I don't think it make sense to invest effort in 
 maintain these tools. So I propose to deprecate these in 2.2 with removal in 
 3.0.
 I'll note that having a tool to help debugging sstable can be useful, but I 
 propose to add a tool for that purpose with CASSANDRA-7464.



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

[jira] [Commented] (CASSANDRA-9628) Unknown keyspace system_traces exception when using nodetool on a new cluster

2015-06-22 Thread Philip Thompson (JIRA)


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

Philip Thompson commented on CASSANDRA-9628:


I'm unable to reproduce this with 2.1.2. Are you running into the issue on a 
newer version (2.1.5 or 2.1.6)?

 Unknown keyspace system_traces exception when using nodetool on a new 
 cluster
 ---

 Key: CASSANDRA-9628
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9628
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: tzach
Priority: Minor

 When creating a new cluster from scratch,  nodetool status fails on 
 system_traces as follow
 {code}
 $ nodetool status
 error: Unknown keyspace system_traces
 -- StackTrace --
 java.lang.AssertionError: Unknown keyspace system_traces
   at org.apache.cassandra.db.Keyspace.init(Keyspace.java:270)
   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:119)
   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:96)
 ...
 {code}
 the problem disappear when creating an empty keyspace
 {code}
 cqlsh create keyspace temp WITH REPLICATION = { 'class' : 'SimpleStrategy', 
 'replication_factor' : 2 };
 {code}
 My guess is system_traces initialization complete only after any data 
 insertion.
 Before it does, any attempt to read  from it either from nodetool, cqlsh or 
 streaming to a new node will fail.



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

[jira] [Resolved] (CASSANDRA-6490) Please delete old releases from mirroring system

2015-06-22 Thread T Jake Luciani (JIRA)


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

T Jake Luciani resolved CASSANDRA-6490.
---
Resolution: Fixed

I've cleaned up the system but I well say I like to include the latest and 
previous releases since when a release happens we wait to update the website 
till the mirrors are updated (otherwise users get a 404) if we push delete the 
old release and add the new then users get the worst of both worlds during the 
transition. 404 on the old versions and 404 on the new till all mirrors are 
updated.  

 Please delete old releases from mirroring system
 

 Key: CASSANDRA-6490
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6490
 Project: Cassandra
  Issue Type: Bug
 Environment: http://www.apache.org/dist/cassandra/
Reporter: Sebb
Assignee: T Jake Luciani

 To reduce the load on the ASF mirrors, projects are required to delete old 
 releases [1]
 Please can you remove all non-current releases?
 Thanks!
 [Note that older releases are always available from the ASF archive server]
 Any links to older releases on download pages should first be adjusted to 
 point to the archive server.
 [1] http://www.apache.org/dev/release.html#when-to-archive



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

[jira] [Updated] (CASSANDRA-9625) GraphiteReporter not reporting

2015-06-22 Thread Philip Thompson (JIRA)


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

Philip Thompson updated CASSANDRA-9625:
---
Reproduced In: 2.1.6
Fix Version/s: 2.1.x

 GraphiteReporter not reporting
 --

 Key: CASSANDRA-9625
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9625
 Project: Cassandra
  Issue Type: Bug
 Environment: Debian Jessie, 7u79-2.5.5-1~deb8u1, Cassandra 2.1.3
Reporter: Eric Evans
 Fix For: 2.1.x

 Attachments: metrics.yaml, thread-dump.log


 When upgrading from 2.1.3 to 2.1.6, the Graphite metrics reporter stops 
 working.  The usual startup is logged, and one batch of samples is sent, but 
 the reporting interval comes and goes, and no other samples are ever sent.  
 The logs are free from errors.
 Frustratingly, metrics reporting works in our smaller (staging) environment 
 on 2.1.6; We are able to reproduce this on all 6 of production nodes, but not 
 on a 3 node (otherwise identical) staging cluster (maybe it takes a certain 
 level of concurrency?).
 Attached is a thread dump, and our metrics.yaml.



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

[jira] [Commented] (CASSANDRA-9618) Consider deprecating sstable2json/json2sstable in 2.2

2015-06-22 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-9618:
--

Should we write the warning to {{err}} instead? Printing to {{out}} might break
things for those who (wrongly or rightly) use sst2j and j2sst in an automated
fashion.

Otherwise +1.

Consider deprecating sstable2json/json2sstable in 2.2
-

Key: CASSANDRA-9618
URL: https://issues.apache.org/jira/browse/CASSANDRA-9618
Project: Cassandra
Issue Type: Task
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 2.2.0 rc2

Attachments: 0001-Deprecate-sstable2json-and-json2sstable.patch

The rational is explained in CASSANDRA-7464 but to rephrase a bit:
* json2sstable is pretty much useless, {{CQLSSTableWriter}} is way more
flexible if you need to write sstable directly.
* sstable2json is really only potentially useful for debugging, but it's
pretty bad at that (it's output is not really all that helpul in modern
Cassandra in particular).
Now, it happens that updating those tool for CASSANDRA-8099, while possible,
is a bit involved. So I don't think it make sense to invest effort in
maintain these tools. So I propose to deprecate these in 2.2 with removal in
3.0.
I'll note that having a tool to help debugging sstable can be useful, but I
propose to add a tool for that purpose with CASSANDRA-7464.

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

[jira] [Comment Edited] (CASSANDRA-9102) Consistency levels such as non-local quorum need better tests

2015-06-22 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg edited comment on CASSANDRA-9102 at 6/22/15 5:28 PM:

As far as I can tell those have little/no unit test coverage because they
aren't testable due to an inability to mock the entire thing. So that leads to
a dtest trying to hit all those paths. Even though it's a dtest it would be
helpful for it to behave more like a unit test when testing each branch. So
rather then having sessions racing and checking for the correct result of the
race (which may or may not race all) construct a scenario where you know
specific code will run. This will make it fail every time instead of just some
of the time when there is a bug. I think checking for races, or testing
functionality in a racy way, would be better handled by the kitchen sink
harness which runs for a long time and not on every commit.

was (Author: aweisberg):
Sorry I am late to commenting on this. I think this is adding a lot of coverage
we don't have. The classes that concern me on the read and write path are
AbstractReadExecutor, and the StorageProxy read/write path. My beef with the
coverage there was that there is no unit test coverage before this task.

Consistency levels such as non-local quorum need better tests
-

Key: CASSANDRA-9102
URL: https://issues.apache.org/jira/browse/CASSANDRA-9102
Project: Cassandra
Issue Type: Test
Reporter: Ariel Weisberg
Assignee: Stefania

We didn't catch unit testing for this functionality. There is dtest
consistency_test but it doesn't cover non-local functionality.

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

1 2 >

1 - 100 of 129 matches

Mail list logo