[jira] [Updated] (CASSANDRA-5626) Support empty IN queries

2013-07-17 Thread Alexander Solovyev (JIRA)

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

Alexander Solovyev updated CASSANDRA-5626:
--

Description: 
It would be nice to have support of empty IN queries. 
Example: SELECT a FROM t WHERE aKey IN (). 
One of the reasons is to have such support in DataStax Java Driver (see 
discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106).

  was:
It would be nice to have support of empty IN queries, an example: SELECT a 
FROM t WHERE aKey IN (). 
One of the reasons is to have such support in DataStax Java Driver (see 
discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106).


 Support empty IN queries
 

 Key: CASSANDRA-5626
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5626
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Alexander Solovyev

 It would be nice to have support of empty IN queries. 
 Example: SELECT a FROM t WHERE aKey IN (). 
 One of the reasons is to have such support in DataStax Java Driver (see 
 discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5761) Issue with secondary index sstable.

2013-07-17 Thread Andriy Yevsyukov (JIRA)

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

Andriy Yevsyukov commented on CASSANDRA-5761:
-

Hi, anyone, please help with this issue, it's really very critical.

 Issue with secondary index sstable.
 ---

 Key: CASSANDRA-5761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5761
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Andriy Yevsyukov
Priority: Critical

 With Cassandra 1.2.5 having issue very similar to 
 [CASSANDRA-5225|https://issues.apache.org/jira/browse/CASSANDRA-5225] but for 
 secondary index sstable. Every query that uses this index fails in Hector 
 with ConnectionTimeout but cassandra log says that reason is:
 {noformat}
 ERROR [ReadStage:55803] 2013-07-15 12:11:35,392 CassandraDaemon.java (line 
 175) Exception in thread Thread[ReadStage:55803,5,main]
 java.lang.RuntimeException: 
 org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db,
  19658 bytes remaining)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1582)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db,
  19658 bytes remaining)
   at 
 org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:108)
   at 
 org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:39)
   at 
 com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
   at 
 com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
   at 
 org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:90)
   at 
 org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:171)
   at 
 org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:154)
   at 
 org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:143)
   at 
 org.apache.cassandra.utils.MergeIterator$ManyToOne.init(MergeIterator.java:86)
   at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:45)
   at 
 org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:134)
   at 
 org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:84)
   at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:293)
   at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:65)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1357)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1214)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1126)
   at 
 org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:140)
   at 
 org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:109)
   at 
 com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
   at 
 com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1466)
   at 
 org.apache.cassandra.db.index.keys.KeysSearcher.search(KeysSearcher.java:82)
   at 
 org.apache.cassandra.db.index.SecondaryIndexManager.search(SecondaryIndexManager.java:548)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.search(ColumnFamilyStore.java:1454)
   at 
 org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44)
   at 
 org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1076)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1578)
   ... 3 more
 Caused by: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: 
 invalid column name length 0 
 

[jira] [Created] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1

2013-07-17 Thread Andy Cobley (JIRA)
Andy Cobley created CASSANDRA-5768:
--

 Summary: If a Seed can't be contacted, a new node comes up as a 
cluster of 1
 Key: CASSANDRA-5768
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Andy Cobley
Priority: Minor


Setting up a new test cluster using  2.0.0-beta1 and I noticed the following 
behaviour with vnodes turned on.  

I bring up one node all well and good.  however if I bring up a second node, 
that can't contact the first (the first being the seed for the second) after a 
short period of time, the second goes ahead and assumes it's the only node and 
bootstraps with all tokens.  

NOTE also this email from Robert Coli 
To: u...@cassandra.apache.org
Obviously if you have defined a seed and cannot contact it, the node should not 
start as a cluster of one. I have a to-do list item to file a JIRA on the 
subject, but if you wanted to file and link us, that'd be super. :)


Startup trace (from the can't contact the seed messages below).




DEBUG 17:57:46,134 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:57:46,139 Cannot handshake version with /192.168.0.10
 INFO 17:57:46,147 Handshaking version with /192.168.0.10
DEBUG 17:57:51,147 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:57:51,151 Cannot handshake version with /192.168.0.10
DEBUG 17:57:51,156 attempting to connect to /192.168.0.10
 INFO 17:57:51,164 Handshaking version with /192.168.0.10
DEBUG 17:57:56,163 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:57:56,168 Cannot handshake version with /192.168.0.10
 INFO 17:57:56,177 Handshaking version with /192.168.0.10
DEBUG 17:58:01,176 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:58:01,195 Cannot handshake version with /192.168.0.10
DEBUG 17:58:01,199 attempting to connect to /192.168.0.10
 INFO 17:58:01,211 Handshaking version with /192.168.0.10
DEBUG 17:58:06,210 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:58:06,229 Cannot handshake version with /192.168.0.10
 INFO 17:58:06,243 Handshaking version with /192.168.0.10
DEBUG 17:58:11,240 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:58:11,257 Cannot handshake version with /192.168.0.10
DEBUG 17:58:11,265 attempting to connect to /192.168.0.10
DEBUG 17:58:11,249 Disseminating load info ...
 INFO 17:58:11,277 Handshaking version with /192.168.0.10
 INFO 17:58:12,918 JOINING: Starting to bootstrap...
DEBUG 17:58:12,922 Beginning bootstrap process
 INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 
7540920246740048508, 8343754522398236724, 8408024349763410671, 
2958176648006585896, -4558504792860463383, 6505045068820279515, 
-2723585437376250373, 6295277530571293136, -632036933490110017, 
7076829522639601545, -972040818133908807, -8032509273357338597, 
-8195415716479930448, 2815056297233670800, -8514945661303914275, 
-1404986336850055825, 1902287316263855857, 2271127848797136099, 
2253027225668615491, -4596682821656889301, -3829603337268068014, 
6732451001921723049, -7525322146388049675, -7520469144418445567, 
-42294142306824200, -3583505036108061780, 2037651260804506174, 
-8857382013269212764, -287803492046061484, -2387955156962752445, 
5851040736860755910, -2566990238894069943, -4862528385953509677, 
-6934815927114679513, 436339434870862426, -9024405707727859684, 
-5712896424965939691, -7306151990958768726, 1972562868127181045, 
432233230504092, 3274187527528688964, -170723646511099548, 
-5215516480259793274, -5433009735911985650, 1611629741105319295, 
-1003574501709202508, -342125947698355485, -6982367747787992083, 
-1265530805719316699, -3787322892048394796, 4335532059375005778, 
-4955726035129474058, -3371084287244267978, -1356714364316547864, 
2509890377680956235, -1688681099182070115, 4105757083923252042, 
6251650102550794764, 6814340446137923947, 2350550282350068760, 
-5827526901688128468, 6417310693620297152, -3072998771907077372, 
-1401160349313134159, 5689378233308186158, -4579053362657493044, 
-1974282572872555977, 6030416333994244776, -6459751443485456668, 
-7053683753232252424, 3313304008102967685, -3323360202881321267, 
1777100483859232105, 644078824255348160, 9174385969124367717, 
-3152648150979214720, -5810274955975592409, -2417697781941443512, 
2097979287894624485, 1306279112226821961, -5471073413421323422, 
-899964525929809433, 5721993461796585132, 6287709076354945844, 
-2618973873461192043, -4901233632190356360, 2810307178808259886, 
414264499406348099, 9204881637988352346, 2756156004752906240, 
4264704223664142541, 6966682145360577932, 456907978019976961, 
3526133307919328434, 6663482402885505474, 1208521381475842799, 
3709424135702812997, 2664447310834129793, 

[jira] [Created] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol

2013-07-17 Thread Duncan Sands (JIRA)
Duncan Sands created CASSANDRA-5769:
---

 Summary: Not all STATUS_CHANGE UP events reported via the native 
protocol
 Key: CASSANDRA-5769
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.6, 1.2.5
 Environment: Uubuntu 12.04, x86, 64 bit
Reporter: Duncan Sands
Priority: Minor


Not all gossip UP events are pushed to native protocol users who have 
registered for them.  This seems to be a native protocol issue because nodes 
themselves get the UP event (as seen in their logs).  I can consistently 
reproduce this issue as follows:

1) connect a client to a cluster node (node1) using the native protocol, 
register for TOPOLOGY_CHANGE and STATUS_CHANGE events.  (Probably you only need 
to register for STATUS_CHANGE to see this, however my client registers for 
both).
2) on another node (node2), send SIGSTOP to the Cassandra process.
3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event for 
the stopped node.
4) on node2, send SIGCONT to the the Cassandra process.
5) wait forever to get a STATUS_CHANGE UP event.  This is failure: no event is 
ever received.

Observe that node1 does know that node2 is back up: in its system log I see for 
example
  INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) 
InetAddress /172.18.34.169 is now UP
shortly after sending SIGCONT to the stopped process.

To eliminate the possibility that my client is at fault, I performed the 
following sanity check:

2') on node2, stopped Cassandra nicely using: sudo service cassandra stop
4') on node2, restarted Cassandra using: sudo service cassandra start

In this case the client soon after gets a STATUS_CHANGE DOWN event followed by 
a STATUS_CHANGE UP event for node2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (CASSANDRA-5757) assertionError in repair

2013-07-17 Thread Yuki Morishita (JIRA)

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

Yuki Morishita edited comment on CASSANDRA-5757 at 7/17/13 3:15 PM:


Hmm, the patch broke SSTableReaderTest#testGetScannerForNoIntersectionRanges.

{code}
java.util.NoSuchElementException
at 
com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:169)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:42)
at 
org.apache.cassandra.io.sstable.SSTableReaderTest.testGetScannerForNoIntersectingRanges(SSTableReaderTest.java:302)
{code}

  was (Author: yukim):
Hmm, the patch broke SSTableReader#testGetScannerForNoIntersectionRanges.

{code}
java.util.NoSuchElementException
at 
com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:169)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:42)
at 
org.apache.cassandra.io.sstable.SSTableReaderTest.testGetScannerForNoIntersectingRanges(SSTableReaderTest.java:302)
{code}
  
 assertionError in repair
 

 Key: CASSANDRA-5757
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5757
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0 beta 1
Reporter: Radim Kolar
Assignee: Sylvain Lebresne
 Fix For: 2.0 beta 2

 Attachments: 5757.txt


 i increased replication factor and run repair, some token ranges were 
 repaired okay, but one failed with:
  INFO 13:03:52,234 [repair #dd7937a0-ebab-11e2-ba07-c38e7fba9d51] session 
 completed successfully
 ERROR 13:03:52,343 Exception in thread Thread[ValidationExecutor:2,1,main]
 java.lang.AssertionError: (max(9099058114996150811),max(-5486100704702537010)]
 at org.apache.cassandra.db.DataRange.init(DataRange.java:50)
 at org.apache.cassandra.db.DataRange.forKeyRange(DataRange.java:74)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReade
 r.java:1033)
 at 
 org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScan
 ners(AbstractCompactionStrategy.java:214)
 at 
 org.apache.cassandra.db.compaction.CompactionManager$ValidationCompac
 tionIterable.init(CompactionManager.java:751)
 at 
 org.apache.cassandra.db.compaction.CompactionManager.doValidationComp
 action(CompactionManager.java:657)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5757) assertionError in repair

2013-07-17 Thread Yuki Morishita (JIRA)

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

Yuki Morishita commented on CASSANDRA-5757:
---

Hmm, the patch broke SSTableReader#testGetScannerForNoIntersectionRanges.

{code}
java.util.NoSuchElementException
at 
com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:169)
at 
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:42)
at 
org.apache.cassandra.io.sstable.SSTableReaderTest.testGetScannerForNoIntersectingRanges(SSTableReaderTest.java:302)
{code}

 assertionError in repair
 

 Key: CASSANDRA-5757
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5757
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0 beta 1
Reporter: Radim Kolar
Assignee: Sylvain Lebresne
 Fix For: 2.0 beta 2

 Attachments: 5757.txt


 i increased replication factor and run repair, some token ranges were 
 repaired okay, but one failed with:
  INFO 13:03:52,234 [repair #dd7937a0-ebab-11e2-ba07-c38e7fba9d51] session 
 completed successfully
 ERROR 13:03:52,343 Exception in thread Thread[ValidationExecutor:2,1,main]
 java.lang.AssertionError: (max(9099058114996150811),max(-5486100704702537010)]
 at org.apache.cassandra.db.DataRange.init(DataRange.java:50)
 at org.apache.cassandra.db.DataRange.forKeyRange(DataRange.java:74)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReade
 r.java:1033)
 at 
 org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScan
 ners(AbstractCompactionStrategy.java:214)
 at 
 org.apache.cassandra.db.compaction.CompactionManager$ValidationCompac
 tionIterable.init(CompactionManager.java:751)
 at 
 org.apache.cassandra.db.compaction.CompactionManager.doValidationComp
 action(CompactionManager.java:657)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (CASSANDRA-5770) Minor bugs in the native protocol v2 on 2.0.0-beta1

2013-07-17 Thread Sylvain Lebresne (JIRA)
Sylvain Lebresne created CASSANDRA-5770:
---

 Summary: Minor bugs in the native protocol v2 on 2.0.0-beta1
 Key: CASSANDRA-5770
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5770
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.0 beta 2


There is a few minor bugs in the new features of the native protocol. Attaching 
patch to fix those.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5770) Minor bugs in the native protocol v2 on 2.0.0-beta1

2013-07-17 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5770:


Attachment: 5770.txt

 Minor bugs in the native protocol v2 on 2.0.0-beta1
 ---

 Key: CASSANDRA-5770
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5770
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.0 beta 2

 Attachments: 5770.txt


 There is a few minor bugs in the new features of the native protocol. 
 Attaching patch to fix those.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5542) BulkLoader is broken in trunk

2013-07-17 Thread Yuki Morishita (JIRA)

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

Yuki Morishita updated CASSANDRA-5542:
--

Fix Version/s: (was: 2.0)
   2.0 beta 2

 BulkLoader is broken in trunk
 -

 Key: CASSANDRA-5542
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5542
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Yuki Morishita
Assignee: Yuki Morishita
 Fix For: 2.0 beta 2

 Attachments: 0001-change-streaming-procedure.patch, 
 0002-make-BulkLoader-work-with-SSTableReader.patch, 
 0003-update-for-post-CASSANDRA-5171.patch, 5542-fix-NPE.txt, 5542.txt


 After CASSANDRA-5015 and CASSANDRA-5521, we need CFMetaData to open 
 SSTable(Reader), especially to get bloom_filter_fp_chance and index_interval.
 When using bulkloader, CFMetaData is not available, so we cannot open SSTable 
 to be streamed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1

2013-07-17 Thread Brandon Williams (JIRA)

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

Brandon Williams reassigned CASSANDRA-5768:
---

Assignee: Brandon Williams

 If a Seed can't be contacted, a new node comes up as a cluster of 1
 ---

 Key: CASSANDRA-5768
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Andy Cobley
Assignee: Brandon Williams
Priority: Minor

 Setting up a new test cluster using  2.0.0-beta1 and I noticed the following 
 behaviour with vnodes turned on.  
 I bring up one node all well and good.  however if I bring up a second node, 
 that can't contact the first (the first being the seed for the second) after 
 a short period of time, the second goes ahead and assumes it's the only node 
 and bootstraps with all tokens.  
 NOTE also this email from Robert Coli 
 To: u...@cassandra.apache.org
 Obviously if you have defined a seed and cannot contact it, the node should 
 not start as a cluster of one. I have a to-do list item to file a JIRA on the 
 subject, but if you wanted to file and link us, that'd be super. :)
 Startup trace (from the can't contact the seed messages below).
 DEBUG 17:57:46,134 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:57:46,139 Cannot handshake version with /192.168.0.10
  INFO 17:57:46,147 Handshaking version with /192.168.0.10
 DEBUG 17:57:51,147 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:57:51,151 Cannot handshake version with /192.168.0.10
 DEBUG 17:57:51,156 attempting to connect to /192.168.0.10
  INFO 17:57:51,164 Handshaking version with /192.168.0.10
 DEBUG 17:57:56,163 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:57:56,168 Cannot handshake version with /192.168.0.10
  INFO 17:57:56,177 Handshaking version with /192.168.0.10
 DEBUG 17:58:01,176 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:58:01,195 Cannot handshake version with /192.168.0.10
 DEBUG 17:58:01,199 attempting to connect to /192.168.0.10
  INFO 17:58:01,211 Handshaking version with /192.168.0.10
 DEBUG 17:58:06,210 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:58:06,229 Cannot handshake version with /192.168.0.10
  INFO 17:58:06,243 Handshaking version with /192.168.0.10
 DEBUG 17:58:11,240 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:58:11,257 Cannot handshake version with /192.168.0.10
 DEBUG 17:58:11,265 attempting to connect to /192.168.0.10
 DEBUG 17:58:11,249 Disseminating load info ...
  INFO 17:58:11,277 Handshaking version with /192.168.0.10
  INFO 17:58:12,918 JOINING: Starting to bootstrap...
 DEBUG 17:58:12,922 Beginning bootstrap process
  INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 
 7540920246740048508, 8343754522398236724, 8408024349763410671, 
 2958176648006585896, -4558504792860463383, 6505045068820279515, 
 -2723585437376250373, 6295277530571293136, -632036933490110017, 
 7076829522639601545, -972040818133908807, -8032509273357338597, 
 -8195415716479930448, 2815056297233670800, -8514945661303914275, 
 -1404986336850055825, 1902287316263855857, 2271127848797136099, 
 2253027225668615491, -4596682821656889301, -3829603337268068014, 
 6732451001921723049, -7525322146388049675, -7520469144418445567, 
 -42294142306824200, -3583505036108061780, 2037651260804506174, 
 -8857382013269212764, -287803492046061484, -2387955156962752445, 
 5851040736860755910, -2566990238894069943, -4862528385953509677, 
 -6934815927114679513, 436339434870862426, -9024405707727859684, 
 -5712896424965939691, -7306151990958768726, 1972562868127181045, 
 432233230504092, 3274187527528688964, -170723646511099548, 
 -5215516480259793274, -5433009735911985650, 1611629741105319295, 
 -1003574501709202508, -342125947698355485, -6982367747787992083, 
 -1265530805719316699, -3787322892048394796, 4335532059375005778, 
 -4955726035129474058, -3371084287244267978, -1356714364316547864, 
 2509890377680956235, -1688681099182070115, 4105757083923252042, 
 6251650102550794764, 6814340446137923947, 2350550282350068760, 
 -5827526901688128468, 6417310693620297152, -3072998771907077372, 
 -1401160349313134159, 5689378233308186158, -4579053362657493044, 
 -1974282572872555977, 6030416333994244776, -6459751443485456668, 
 -7053683753232252424, 3313304008102967685, -3323360202881321267, 
 1777100483859232105, 644078824255348160, 9174385969124367717, 
 -3152648150979214720, -5810274955975592409, -2417697781941443512, 
 2097979287894624485, 1306279112226821961, -5471073413421323422, 
 -899964525929809433, 

[jira] [Updated] (CASSANDRA-5771) Small bug in Range.intersects(Bound)

2013-07-17 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-5771:


Attachment: 5771.txt

Attaching patch to fix.

 Small bug in Range.intersects(Bound)
 

 Key: CASSANDRA-5771
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5771
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.7

 Attachments: 5771.txt


 Range.intersects(Bound) doesn't correctly handle the case where the bound in 
 argument has the same start and end (i.e. is a Bound of 1 value). It 
 basically always return true in that case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5757) assertionError in repair

2013-07-17 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-5757:
-

Turns out that this is a bug in Range.intersects(Bound) that this test happens 
to run into. And since that bug actually affect 1.2 too, I've created 
CASSANDRA-5771 for that specific problem. With the patch from CASSANDRA-5771, 
the test passes correctly.

 assertionError in repair
 

 Key: CASSANDRA-5757
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5757
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0 beta 1
Reporter: Radim Kolar
Assignee: Sylvain Lebresne
 Fix For: 2.0 beta 2

 Attachments: 5757.txt


 i increased replication factor and run repair, some token ranges were 
 repaired okay, but one failed with:
  INFO 13:03:52,234 [repair #dd7937a0-ebab-11e2-ba07-c38e7fba9d51] session 
 completed successfully
 ERROR 13:03:52,343 Exception in thread Thread[ValidationExecutor:2,1,main]
 java.lang.AssertionError: (max(9099058114996150811),max(-5486100704702537010)]
 at org.apache.cassandra.db.DataRange.init(DataRange.java:50)
 at org.apache.cassandra.db.DataRange.forKeyRange(DataRange.java:74)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReade
 r.java:1033)
 at 
 org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScan
 ners(AbstractCompactionStrategy.java:214)
 at 
 org.apache.cassandra.db.compaction.CompactionManager$ValidationCompac
 tionIterable.init(CompactionManager.java:751)
 at 
 org.apache.cassandra.db.compaction.CompactionManager.doValidationComp
 action(CompactionManager.java:657)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1

2013-07-17 Thread Brandon Williams (JIRA)

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

Brandon Williams updated CASSANDRA-5768:


Attachment: 5768.txt

It seems reasonable to me that we should ensure we've contacted a seed during 
bootstrap when one has been set. Patch to check for this and refuse if it fails.

 If a Seed can't be contacted, a new node comes up as a cluster of 1
 ---

 Key: CASSANDRA-5768
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Andy Cobley
Assignee: Brandon Williams
Priority: Minor
 Attachments: 5768.txt


 Setting up a new test cluster using  2.0.0-beta1 and I noticed the following 
 behaviour with vnodes turned on.  
 I bring up one node all well and good.  however if I bring up a second node, 
 that can't contact the first (the first being the seed for the second) after 
 a short period of time, the second goes ahead and assumes it's the only node 
 and bootstraps with all tokens.  
 NOTE also this email from Robert Coli 
 To: u...@cassandra.apache.org
 Obviously if you have defined a seed and cannot contact it, the node should 
 not start as a cluster of one. I have a to-do list item to file a JIRA on the 
 subject, but if you wanted to file and link us, that'd be super. :)
 Startup trace (from the can't contact the seed messages below).
 DEBUG 17:57:46,134 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:57:46,139 Cannot handshake version with /192.168.0.10
  INFO 17:57:46,147 Handshaking version with /192.168.0.10
 DEBUG 17:57:51,147 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:57:51,151 Cannot handshake version with /192.168.0.10
 DEBUG 17:57:51,156 attempting to connect to /192.168.0.10
  INFO 17:57:51,164 Handshaking version with /192.168.0.10
 DEBUG 17:57:56,163 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:57:56,168 Cannot handshake version with /192.168.0.10
  INFO 17:57:56,177 Handshaking version with /192.168.0.10
 DEBUG 17:58:01,176 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:58:01,195 Cannot handshake version with /192.168.0.10
 DEBUG 17:58:01,199 attempting to connect to /192.168.0.10
  INFO 17:58:01,211 Handshaking version with /192.168.0.10
 DEBUG 17:58:06,210 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:58:06,229 Cannot handshake version with /192.168.0.10
  INFO 17:58:06,243 Handshaking version with /192.168.0.10
 DEBUG 17:58:11,240 Target max version is -2147483648; no version information 
 yet, will retry
  INFO 17:58:11,257 Cannot handshake version with /192.168.0.10
 DEBUG 17:58:11,265 attempting to connect to /192.168.0.10
 DEBUG 17:58:11,249 Disseminating load info ...
  INFO 17:58:11,277 Handshaking version with /192.168.0.10
  INFO 17:58:12,918 JOINING: Starting to bootstrap...
 DEBUG 17:58:12,922 Beginning bootstrap process
  INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 
 7540920246740048508, 8343754522398236724, 8408024349763410671, 
 2958176648006585896, -4558504792860463383, 6505045068820279515, 
 -2723585437376250373, 6295277530571293136, -632036933490110017, 
 7076829522639601545, -972040818133908807, -8032509273357338597, 
 -8195415716479930448, 2815056297233670800, -8514945661303914275, 
 -1404986336850055825, 1902287316263855857, 2271127848797136099, 
 2253027225668615491, -4596682821656889301, -3829603337268068014, 
 6732451001921723049, -7525322146388049675, -7520469144418445567, 
 -42294142306824200, -3583505036108061780, 2037651260804506174, 
 -8857382013269212764, -287803492046061484, -2387955156962752445, 
 5851040736860755910, -2566990238894069943, -4862528385953509677, 
 -6934815927114679513, 436339434870862426, -9024405707727859684, 
 -5712896424965939691, -7306151990958768726, 1972562868127181045, 
 432233230504092, 3274187527528688964, -170723646511099548, 
 -5215516480259793274, -5433009735911985650, 1611629741105319295, 
 -1003574501709202508, -342125947698355485, -6982367747787992083, 
 -1265530805719316699, -3787322892048394796, 4335532059375005778, 
 -4955726035129474058, -3371084287244267978, -1356714364316547864, 
 2509890377680956235, -1688681099182070115, 4105757083923252042, 
 6251650102550794764, 6814340446137923947, 2350550282350068760, 
 -5827526901688128468, 6417310693620297152, -3072998771907077372, 
 -1401160349313134159, 5689378233308186158, -4579053362657493044, 
 -1974282572872555977, 6030416333994244776, -6459751443485456668, 
 -7053683753232252424, 3313304008102967685, -3323360202881321267, 
 1777100483859232105, 

[jira] [Created] (CASSANDRA-5771) Small bug in Range.intersects(Bound)

2013-07-17 Thread Sylvain Lebresne (JIRA)
Sylvain Lebresne created CASSANDRA-5771:
---

 Summary: Small bug in Range.intersects(Bound)
 Key: CASSANDRA-5771
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5771
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.7


Range.intersects(Bound) doesn't correctly handle the case where the bound in 
argument has the same start and end (i.e. is a Bound of 1 value). It basically 
always return true in that case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-:
---

[bump]

 Allow sstableloader to handle a larger number of files
 --

 Key: CASSANDRA-
 URL: https://issues.apache.org/jira/browse/CASSANDRA-
 Project: Cassandra
  Issue Type: Improvement
  Components: Core, Tools
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
 Fix For: 1.2.7

 Attachments: -01.txt, -02.txt, -2.txt, 
 -fix-heap-and-streaming-1.2.patch, 
 -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, 
 CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt


 With the default heap size, sstableloader will OOM when there are roughly 25k 
 files in the directory to load.  It's easy to reach this number of files in a 
 single LCS column family.
 By avoiding creating all SSTableReaders up front in SSTableLoader, we should 
 be able to increase the number of files that sstableloader can handle 
 considerably.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5704:
---

Yes, it's a memtable write ... to the system.local table, with information 
about the truncated table.

No doubt you would reply, then let's skip the flush when durable writes are 
disabled on the system keyspace, but you'll note that we've already special 
cased this flush even though the memtable writes is commitlogged -- we want it 
to persist immediately even with periodic commitlog mode.  Truncated data 
reappearing is very high on the list of Behaviors That Surprise People.

Therefore I propose the attached patch along the lines of what Jake and Brandon 
suggest, that adds a {{cassandra.unsafetruncate}} property.  (Normally I am not 
a fan of using a 'negative' property name like 'unsafe' but I don't want to 
encourage people to use it, who shouldn't, which I think we risk if we use 
{{quicktruncate}} or similar.)

 Truncate flushes to disk again in 1.2, even with durable_writes=false
 -

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Christian Spriegel
Priority: Minor
 Fix For: 1.2.7

 Attachments: 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, 
 CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-2524) Use SSTableBoundedScanner for cleanup

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-2524:
--

 Reviewer: jbellis  (was: slebresne)
Fix Version/s: (was: 2.0)
   2.0.1
 Assignee: Tyler Hobbs  (was: Marcus Eriksson)

 Use SSTableBoundedScanner for cleanup
 -

 Key: CASSANDRA-2524
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2524
 Project: Cassandra
  Issue Type: Improvement
Reporter: Stu Hood
Assignee: Tyler Hobbs
Priority: Minor
  Labels: lhf
 Fix For: 2.0.1

 Attachments: 
 0001-CASSANDRA-2524-use-SSTableBoundedScanner-for-cleanup.patch, 
 0001-Use-a-SSTableBoundedScanner-for-cleanup-and-improve-cl.txt, 
 0002-Oops.-When-indexes-or-counters-are-in-use-must-continu.txt


 SSTableBoundedScanner seeks rather than scanning through rows, so it would be 
 significantly more efficient than the existing per-key filtering that cleanup 
 does.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-2524) Use SSTableBoundedScanner for cleanup

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-2524:
---

Assigning to Tyler since his work on CASSANDRA-5722 gets us most of the way 
there.

 Use SSTableBoundedScanner for cleanup
 -

 Key: CASSANDRA-2524
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2524
 Project: Cassandra
  Issue Type: Improvement
Reporter: Stu Hood
Assignee: Tyler Hobbs
Priority: Minor
  Labels: lhf
 Fix For: 2.0.1

 Attachments: 
 0001-CASSANDRA-2524-use-SSTableBoundedScanner-for-cleanup.patch, 
 0001-Use-a-SSTableBoundedScanner-for-cleanup-and-improve-cl.txt, 
 0002-Oops.-When-indexes-or-counters-are-in-use-must-continu.txt


 SSTableBoundedScanner seeks rather than scanning through rows, so it would be 
 significantly more efficient than the existing per-key filtering that cleanup 
 does.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5761) Issue with secondary index sstable.

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5761:
---

You would get that error if you are inserting empty partition keys, but we 
guard against that.  Are you bypassing validation somehow, e.g. with 
json2sstable or by direct calls to StorageProxy?

 Issue with secondary index sstable.
 ---

 Key: CASSANDRA-5761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5761
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Andriy Yevsyukov
Priority: Critical

 With Cassandra 1.2.5 having issue very similar to 
 [CASSANDRA-5225|https://issues.apache.org/jira/browse/CASSANDRA-5225] but for 
 secondary index sstable. Every query that uses this index fails in Hector 
 with ConnectionTimeout but cassandra log says that reason is:
 {noformat}
 ERROR [ReadStage:55803] 2013-07-15 12:11:35,392 CassandraDaemon.java (line 
 175) Exception in thread Thread[ReadStage:55803,5,main]
 java.lang.RuntimeException: 
 org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db,
  19658 bytes remaining)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1582)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
 org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid 
 column name length 0 
 (/data/cassandra/data/betting/events/betting-events.events_sport_type_idx-ic-1-Data.db,
  19658 bytes remaining)
   at 
 org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:108)
   at 
 org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:39)
   at 
 com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
   at 
 com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
   at 
 org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:90)
   at 
 org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:171)
   at 
 org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:154)
   at 
 org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:143)
   at 
 org.apache.cassandra.utils.MergeIterator$ManyToOne.init(MergeIterator.java:86)
   at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:45)
   at 
 org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:134)
   at 
 org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:84)
   at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:293)
   at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:65)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1357)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1214)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1126)
   at 
 org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:140)
   at 
 org.apache.cassandra.db.index.keys.KeysSearcher$1.computeNext(KeysSearcher.java:109)
   at 
 com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
   at 
 com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1466)
   at 
 org.apache.cassandra.db.index.keys.KeysSearcher.search(KeysSearcher.java:82)
   at 
 org.apache.cassandra.db.index.SecondaryIndexManager.search(SecondaryIndexManager.java:548)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.search(ColumnFamilyStore.java:1454)
   at 
 org.apache.cassandra.service.RangeSliceVerbHandler.executeLocally(RangeSliceVerbHandler.java:44)
   at 
 org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1076)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1578)
   ... 3 more
 Caused by: 

[jira] [Commented] (CASSANDRA-5722) Cleanup should skip sstables that don't contain data outside a nodes ranges

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5722:
---

All right.  I'll commit once we branch off 2.0.0; thanks.

 Cleanup should skip sstables that don't contain data outside a nodes ranges
 ---

 Key: CASSANDRA-5722
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5722
 Project: Cassandra
  Issue Type: Improvement
Reporter: Nick Bailey
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Skip-cleanup-when-unneeded.patch


 Right now cleanup is optimized to simply delete sstables that *only* contain 
 data that doesn't belong on the node, for all other sstables though, it will 
 read them, check each row, and write out new sstables.
 Cleanup could be optimized to look at an sstable and determine that all data 
 within the sstable does belong on a node, and therefore skip re-writing that 
 sstable. This would make cleanup essentially a noop in the case where all 
 data on a node belongs on that node.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5704:
--

Attachment: 5704-v2.txt

 Truncate flushes to disk again in 1.2, even with durable_writes=false
 -

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Christian Spriegel
Priority: Minor
 Fix For: 1.2.7

 Attachments: 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, 
 CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5771) Small bug in Range.intersects(Bound)

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-5771:
---

+1, although I'm not sure what a punition is.

 Small bug in Range.intersects(Bound)
 

 Key: CASSANDRA-5771
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5771
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.7

 Attachments: 5771.txt


 Range.intersects(Bound) doesn't correctly handle the case where the bound in 
 argument has the same start and end (i.e. is a Bound of 1 value). It 
 basically always return true in that case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis reassigned CASSANDRA-5769:
-

Assignee: Tyler Hobbs

Tyler, can you reproduce?

 Not all STATUS_CHANGE UP events reported via the native protocol
 

 Key: CASSANDRA-5769
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5, 1.2.6
 Environment: Uubuntu 12.04, x86, 64 bit
Reporter: Duncan Sands
Assignee: Tyler Hobbs
Priority: Minor

 Not all gossip UP events are pushed to native protocol users who have 
 registered for them.  This seems to be a native protocol issue because nodes 
 themselves get the UP event (as seen in their logs).  I can consistently 
 reproduce this issue as follows:
 1) connect a client to a cluster node (node1) using the native protocol, 
 register for TOPOLOGY_CHANGE and STATUS_CHANGE events.  (Probably you only 
 need to register for STATUS_CHANGE to see this, however my client registers 
 for both).
 2) on another node (node2), send SIGSTOP to the Cassandra process.
 3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event 
 for the stopped node.
 4) on node2, send SIGCONT to the the Cassandra process.
 5) wait forever to get a STATUS_CHANGE UP event.  This is failure: no event 
 is ever received.
 Observe that node1 does know that node2 is back up: in its system log I see 
 for example
   INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) 
 InetAddress /172.18.34.169 is now UP
 shortly after sending SIGCONT to the stopped process.
 To eliminate the possibility that my client is at fault, I performed the 
 following sanity check:
 2') on node2, stopped Cassandra nicely using: sudo service cassandra stop
 4') on node2, restarted Cassandra using: sudo service cassandra start
 In this case the client soon after gets a STATUS_CHANGE DOWN event followed 
 by a STATUS_CHANGE UP event for node2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5768:
--

Description: 
Setting up a new test cluster using  2.0.0-beta1 and I noticed the following 
behaviour with vnodes turned on.  

I bring up one node all well and good.  however if I bring up a second node, 
that can't contact the first (the first being the seed for the second) after a 
short period of time, the second goes ahead and assumes it's the only node and 
bootstraps with all tokens.  

NOTE also this email from Robert Coli 
To: u...@cassandra.apache.org
Obviously if you have defined a seed and cannot contact it, the node should not 
start as a cluster of one. I have a to-do list item to file a JIRA on the 
subject, but if you wanted to file and link us, that'd be super. :)


Startup trace (from the can't contact the seed messages below).

http://aep.appspot.com/display/ABcWltCES1srzPrj5CkS69-GB8o/

  was:
Setting up a new test cluster using  2.0.0-beta1 and I noticed the following 
behaviour with vnodes turned on.  

I bring up one node all well and good.  however if I bring up a second node, 
that can't contact the first (the first being the seed for the second) after a 
short period of time, the second goes ahead and assumes it's the only node and 
bootstraps with all tokens.  

NOTE also this email from Robert Coli 
To: u...@cassandra.apache.org
Obviously if you have defined a seed and cannot contact it, the node should not 
start as a cluster of one. I have a to-do list item to file a JIRA on the 
subject, but if you wanted to file and link us, that'd be super. :)


Startup trace (from the can't contact the seed messages below).




DEBUG 17:57:46,134 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:57:46,139 Cannot handshake version with /192.168.0.10
 INFO 17:57:46,147 Handshaking version with /192.168.0.10
DEBUG 17:57:51,147 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:57:51,151 Cannot handshake version with /192.168.0.10
DEBUG 17:57:51,156 attempting to connect to /192.168.0.10
 INFO 17:57:51,164 Handshaking version with /192.168.0.10
DEBUG 17:57:56,163 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:57:56,168 Cannot handshake version with /192.168.0.10
 INFO 17:57:56,177 Handshaking version with /192.168.0.10
DEBUG 17:58:01,176 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:58:01,195 Cannot handshake version with /192.168.0.10
DEBUG 17:58:01,199 attempting to connect to /192.168.0.10
 INFO 17:58:01,211 Handshaking version with /192.168.0.10
DEBUG 17:58:06,210 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:58:06,229 Cannot handshake version with /192.168.0.10
 INFO 17:58:06,243 Handshaking version with /192.168.0.10
DEBUG 17:58:11,240 Target max version is -2147483648; no version information 
yet, will retry
 INFO 17:58:11,257 Cannot handshake version with /192.168.0.10
DEBUG 17:58:11,265 attempting to connect to /192.168.0.10
DEBUG 17:58:11,249 Disseminating load info ...
 INFO 17:58:11,277 Handshaking version with /192.168.0.10
 INFO 17:58:12,918 JOINING: Starting to bootstrap...
DEBUG 17:58:12,922 Beginning bootstrap process
 INFO 17:58:13,065 Bootstrap completed! for the tokens [-6323000812485711377, 
7540920246740048508, 8343754522398236724, 8408024349763410671, 
2958176648006585896, -4558504792860463383, 6505045068820279515, 
-2723585437376250373, 6295277530571293136, -632036933490110017, 
7076829522639601545, -972040818133908807, -8032509273357338597, 
-8195415716479930448, 2815056297233670800, -8514945661303914275, 
-1404986336850055825, 1902287316263855857, 2271127848797136099, 
2253027225668615491, -4596682821656889301, -3829603337268068014, 
6732451001921723049, -7525322146388049675, -7520469144418445567, 
-42294142306824200, -3583505036108061780, 2037651260804506174, 
-8857382013269212764, -287803492046061484, -2387955156962752445, 
5851040736860755910, -2566990238894069943, -4862528385953509677, 
-6934815927114679513, 436339434870862426, -9024405707727859684, 
-5712896424965939691, -7306151990958768726, 1972562868127181045, 
432233230504092, 3274187527528688964, -170723646511099548, 
-5215516480259793274, -5433009735911985650, 1611629741105319295, 
-1003574501709202508, -342125947698355485, -6982367747787992083, 
-1265530805719316699, -3787322892048394796, 4335532059375005778, 
-4955726035129474058, -3371084287244267978, -1356714364316547864, 
2509890377680956235, -1688681099182070115, 4105757083923252042, 
6251650102550794764, 6814340446137923947, 2350550282350068760, 
-5827526901688128468, 6417310693620297152, -3072998771907077372, 
-1401160349313134159, 5689378233308186158, -4579053362657493044, 
-1974282572872555977, 6030416333994244776, -6459751443485456668, 

[jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

2013-07-17 Thread Brandon Williams (JIRA)

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

Brandon Williams commented on CASSANDRA-5704:
-

+1

 Truncate flushes to disk again in 1.2, even with durable_writes=false
 -

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Christian Spriegel
Priority: Minor
 Fix For: 1.2.7

 Attachments: 5704-v2.txt, CASSANDRA_5704_V1_1_2.patch, 
 CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files

2013-07-17 Thread Tyler Hobbs (JIRA)

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

Tyler Hobbs commented on CASSANDRA-:


Just waiting on a commit on CASSANDRA-5542 before I put in the last piece of 
the trunk patch.

 Allow sstableloader to handle a larger number of files
 --

 Key: CASSANDRA-
 URL: https://issues.apache.org/jira/browse/CASSANDRA-
 Project: Cassandra
  Issue Type: Improvement
  Components: Core, Tools
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
 Fix For: 1.2.7

 Attachments: -01.txt, -02.txt, -2.txt, 
 -fix-heap-and-streaming-1.2.patch, 
 -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, 
 CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt


 With the default heap size, sstableloader will OOM when there are roughly 25k 
 files in the directory to load.  It's easy to reach this number of files in a 
 single LCS column family.
 By avoiding creating all SSTableReaders up front in SSTableLoader, we should 
 be able to increase the number of files that sstableloader can handle 
 considerably.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol

2013-07-17 Thread Tyler Hobbs (JIRA)

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

Tyler Hobbs commented on CASSANDRA-5769:


Yes, I can reliably reproduce the issue (through the python driver) with those 
steps using ccm.

 Not all STATUS_CHANGE UP events reported via the native protocol
 

 Key: CASSANDRA-5769
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5, 1.2.6
 Environment: Uubuntu 12.04, x86, 64 bit
Reporter: Duncan Sands
Assignee: Tyler Hobbs
Priority: Minor

 Not all gossip UP events are pushed to native protocol users who have 
 registered for them.  This seems to be a native protocol issue because nodes 
 themselves get the UP event (as seen in their logs).  I can consistently 
 reproduce this issue as follows:
 1) connect a client to a cluster node (node1) using the native protocol, 
 register for TOPOLOGY_CHANGE and STATUS_CHANGE events.  (Probably you only 
 need to register for STATUS_CHANGE to see this, however my client registers 
 for both).
 2) on another node (node2), send SIGSTOP to the Cassandra process.
 3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event 
 for the stopped node.
 4) on node2, send SIGCONT to the the Cassandra process.
 5) wait forever to get a STATUS_CHANGE UP event.  This is failure: no event 
 is ever received.
 Observe that node1 does know that node2 is back up: in its system log I see 
 for example
   INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) 
 InetAddress /172.18.34.169 is now UP
 shortly after sending SIGCONT to the stopped process.
 To eliminate the possibility that my client is at fault, I performed the 
 following sanity check:
 2') on node2, stopped Cassandra nicely using: sudo service cassandra stop
 4') on node2, restarted Cassandra using: sudo service cassandra start
 In this case the client soon after gets a STATUS_CHANGE DOWN event followed 
 by a STATUS_CHANGE UP event for node2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (CASSANDRA-5772) Support streaming of SSTables created in older version's format

2013-07-17 Thread Yuki Morishita (JIRA)
Yuki Morishita created CASSANDRA-5772:
-

 Summary: Support streaming of SSTables created in older version's 
format
 Key: CASSANDRA-5772
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5772
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 2.0 beta 1
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
 Fix For: 2.0 beta 2


New streaming protocol is capable of sending and receiving older SSTables.
Implement the ability to stream older versions so that we can avoid error like 
the one described in CASSANDRA-5104.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5772) Support streaming of SSTables created in older version's format

2013-07-17 Thread Yuki Morishita (JIRA)

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

Yuki Morishita updated CASSANDRA-5772:
--

Attachment: 0001-support-streaming-sstable-of-older-versions.patch

Patch attached.

 Support streaming of SSTables created in older version's format
 ---

 Key: CASSANDRA-5772
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5772
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 2.0 beta 1
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
  Labels: streaming
 Fix For: 2.0 beta 2

 Attachments: 0001-support-streaming-sstable-of-older-versions.patch


 New streaming protocol is capable of sending and receiving older SSTables.
 Implement the ability to stream older versions so that we can avoid error 
 like the one described in CASSANDRA-5104.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (CASSANDRA-5769) Not all STATUS_CHANGE UP events reported via the native protocol

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis reassigned CASSANDRA-5769:
-

Assignee: Sylvain Lebresne  (was: Tyler Hobbs)

 Not all STATUS_CHANGE UP events reported via the native protocol
 

 Key: CASSANDRA-5769
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5769
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5, 1.2.6
 Environment: Uubuntu 12.04, x86, 64 bit
Reporter: Duncan Sands
Assignee: Sylvain Lebresne
Priority: Minor

 Not all gossip UP events are pushed to native protocol users who have 
 registered for them.  This seems to be a native protocol issue because nodes 
 themselves get the UP event (as seen in their logs).  I can consistently 
 reproduce this issue as follows:
 1) connect a client to a cluster node (node1) using the native protocol, 
 register for TOPOLOGY_CHANGE and STATUS_CHANGE events.  (Probably you only 
 need to register for STATUS_CHANGE to see this, however my client registers 
 for both).
 2) on another node (node2), send SIGSTOP to the Cassandra process.
 3) after about 30 seconds the client gets pushed a STATUS_CHANGE DOWN event 
 for the stopped node.
 4) on node2, send SIGCONT to the the Cassandra process.
 5) wait forever to get a STATUS_CHANGE UP event.  This is failure: no event 
 is ever received.
 Observe that node1 does know that node2 is back up: in its system log I see 
 for example
   INFO [GossipStage:1] 2013-07-17 14:27:41,238 Gossiper.java (line 771) 
 InetAddress /172.18.34.169 is now UP
 shortly after sending SIGCONT to the stopped process.
 To eliminate the possibility that my client is at fault, I performed the 
 following sanity check:
 2') on node2, stopped Cassandra nicely using: sudo service cassandra stop
 4') on node2, restarted Cassandra using: sudo service cassandra start
 In this case the client soon after gets a STATUS_CHANGE DOWN event followed 
 by a STATUS_CHANGE UP event for node2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[1/3] git commit: add cassandra.unsafetruncate property patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704

2013-07-17 Thread jbellis
Updated Branches:
  refs/heads/cassandra-1.2 3280fb087 - 0feb59a97
  refs/heads/trunk 57f1ad3a3 - 2ef78c689


add cassandra.unsafetruncate property
patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704


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

Branch: refs/heads/cassandra-1.2
Commit: 0feb59a97016a311989d6a7d1db0fc1ef46603fa
Parents: 3280fb0
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Jul 17 12:04:17 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Jul 17 12:04:17 2013 -0700

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00148a3..09f4c7b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2.7
+ * add cassandra.unsafetruncate property (CASSANDRA-5704)
  * (Hadoop) quote identifiers in CqlPagingRecordReader (CASSANDRA-5763)
  * Add replace_node functionality for vnodes (CASSANDRA-5337)
  * Add timeout events to query traces (CASSANDRA-5520)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java 
b/src/java/org/apache/cassandra/db/SystemTable.java
index 187aac5..1d9fd72 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -185,7 +185,8 @@ public class SystemTable
 {
 String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
WHERE key = '%s';
 processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, 
truncatedAt, position), LOCAL_KEY));
-forceBlockingFlush(LOCAL_CF);
+if (!Boolean.getBoolean(cassandra.unsafetruncate))
+forceBlockingFlush(LOCAL_CF);
 }
 
 /**



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

2013-07-17 Thread jbellis
Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 2ef78c689fc344f46fe7c6f12f21e490ca083da6
Parents: 57f1ad3 0feb59a
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Jul 17 12:05:02 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Jul 17 12:05:02 2013 -0700

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ef78c68/CHANGES.txt
--
diff --cc CHANGES.txt
index 09b5c25,09f4c7b..09472bc
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,89 -1,5 +1,90 @@@
 +2.0.0-beta2
 + * Allow nodetool with no args, and with help to run without a server 
(CASSANDRA-5734)
 + * Cleanup AbstractType/TypeSerializer classes (CASSANDRA-5744)
 + * Remove unimplemented cli option schema-mwt (CASSANDRA-5754)
 + * Support range tombstones in thrift (CASSANDRA-5435)
 + * Normalize table-manipulating CQL3 statements' class names (CASSANDRA-5759)
 + * cqlsh: add missing table options to DESCRIBE output (CASSANDRA-5749)
 +
 +2.0.0-beta1
 + * Removed on-heap row cache (CASSANDRA-5348)
 + * use nanotime consistently for node-local timeouts (CASSANDRA-5581)
 + * Avoid unnecessary second pass on name-based queries (CASSANDRA-5577)
 + * Experimental triggers (CASSANDRA-1311)
 + * JEMalloc support for off-heap allocation (CASSANDRA-3997)
 + * Single-pass compaction (CASSANDRA-4180)
 + * Removed token range bisection (CASSANDRA-5518)
 + * Removed compatibility with pre-1.2.5 sstables and network messages
 +   (CASSANDRA-5511)
 + * removed PBSPredictor (CASSANDRA-5455)
 + * CAS support (CASSANDRA-5062, 5441, 5442, 5443, 5619, 5667)
 + * Leveled compaction performs size-tiered compactions in L0 
 +   (CASSANDRA-5371, 5439)
 + * Add yaml network topology snitch for mixed ec2/other envs (CASSANDRA-5339)
 + * Log when a node is down longer than the hint window (CASSANDRA-4554)
 + * Optimize tombstone creation for ExpiringColumns (CASSANDRA-4917)
 + * Improve LeveledScanner work estimation (CASSANDRA-5250, 5407)
 + * Replace compaction lock with runWithCompactionsDisabled (CASSANDRA-3430)
 + * Change Message IDs to ints (CASSANDRA-5307)
 + * Move sstable level information into the Stats component, removing the
 +   need for a separate Manifest file (CASSANDRA-4872)
 + * avoid serializing to byte[] on commitlog append (CASSANDRA-5199)
 + * make index_interval configurable per columnfamily (CASSANDRA-3961, 
CASSANDRA-5650)
 + * add default_time_to_live (CASSANDRA-3974)
 + * add memtable_flush_period_in_ms (CASSANDRA-4237)
 + * replace supercolumns internally by composites (CASSANDRA-3237, 5123)
 + * upgrade thrift to 0.9.0 (CASSANDRA-3719)
 + * drop unnecessary keyspace parameter from user-defined compaction API 
 +   (CASSANDRA-5139)
 + * more robust solution to incomplete compactions + counters (CASSANDRA-5151)
 + * Change order of directory searching for c*.in.sh (CASSANDRA-3983)
 + * Add tool to reset SSTable compaction level for LCS (CASSANDRA-5271)
 + * Allow custom configuration loader (CASSANDRA-5045)
 + * Remove memory emergency pressure valve logic (CASSANDRA-3534)
 + * Reduce request latency with eager retry (CASSANDRA-4705)
 + * cqlsh: Remove ASSUME command (CASSANDRA-5331)
 + * Rebuild BF when loading sstables if bloom_filter_fp_chance
 +   has changed since compaction (CASSANDRA-5015)
 + * remove row-level bloom filters (CASSANDRA-4885)
 + * Change Kernel Page Cache skipping into row preheating (disabled by default)
 +   (CASSANDRA-4937)
 + * Improve repair by deciding on a gcBefore before sending
 +   out TreeRequests (CASSANDRA-4932)
 + * Add an official way to disable compactions (CASSANDRA-5074)
 + * Reenable ALTER TABLE DROP with new semantics (CASSANDRA-3919)
 + * Add binary protocol versioning (CASSANDRA-5436)
 + * Swap THshaServer for TThreadedSelectorServer (CASSANDRA-5530)
 + * Add alias support to SELECT statement (CASSANDRA-5075)
 + * Don't create empty RowMutations in CommitLogReplayer (CASSANDRA-5541)
 + * Use range tombstones when dropping cfs/columns from schema (CASSANDRA-5579)
 + * cqlsh: drop CQL2/CQL3-beta support (CASSANDRA-5585)
 + * Track max/min column names in sstables to be able to optimize slice
 +   queries (CASSANDRA-5514, CASSANDRA-5595, CASSANDRA-5600)
 + * Binary protocol: allow batching already prepared statements 
(CASSANDRA-4693)
 + * Allow preparing timestamp, ttl and limit in CQL3 queries (CASSANDRA-4450)
 + 

[2/3] git commit: add cassandra.unsafetruncate property patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704

2013-07-17 Thread jbellis
add cassandra.unsafetruncate property
patch by jbellis; reviewed by brandonwilliams for CASSANDRA-5704


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

Branch: refs/heads/trunk
Commit: 0feb59a97016a311989d6a7d1db0fc1ef46603fa
Parents: 3280fb0
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Jul 17 12:04:17 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Jul 17 12:04:17 2013 -0700

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00148a3..09f4c7b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 1.2.7
+ * add cassandra.unsafetruncate property (CASSANDRA-5704)
  * (Hadoop) quote identifiers in CqlPagingRecordReader (CASSANDRA-5763)
  * Add replace_node functionality for vnodes (CASSANDRA-5337)
  * Add timeout events to query traces (CASSANDRA-5520)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0feb59a9/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java 
b/src/java/org/apache/cassandra/db/SystemTable.java
index 187aac5..1d9fd72 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -185,7 +185,8 @@ public class SystemTable
 {
 String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
WHERE key = '%s';
 processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, 
truncatedAt, position), LOCAL_KEY));
-forceBlockingFlush(LOCAL_CF);
+if (!Boolean.getBoolean(cassandra.unsafetruncate))
+forceBlockingFlush(LOCAL_CF);
 }
 
 /**



[jira] [Updated] (CASSANDRA-5770) Minor bugs in the native protocol v2 on 2.0.0-beta1

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-5770:
--

Reviewer: iamaleksey

 Minor bugs in the native protocol v2 on 2.0.0-beta1
 ---

 Key: CASSANDRA-5770
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5770
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.0 beta 2

 Attachments: 5770.txt


 There is a few minor bugs in the new features of the native protocol. 
 Attaching patch to fix those.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (CASSANDRA-5773) print cluster name in describe cluster

2013-07-17 Thread Philip Crotwell (JIRA)
Philip Crotwell created CASSANDRA-5773:
--

 Summary: print cluster name in describe cluster
 Key: CASSANDRA-5773
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5773
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.6
Reporter: Philip Crotwell
Assignee: Philip Crotwell
Priority: Trivial



Would be nice to print the cluster name when doing 'describe cluster' in 
cassandra-cli.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5773) print cluster name in describe cluster

2013-07-17 Thread Philip Crotwell (JIRA)

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

Philip Crotwell updated CASSANDRA-5773:
---

Attachment: trunk-5773.txt

Patch

 print cluster name in describe cluster
 --

 Key: CASSANDRA-5773
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5773
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.6
Reporter: Philip Crotwell
Assignee: Philip Crotwell
Priority: Trivial
 Attachments: trunk-5773.txt


 Would be nice to print the cluster name when doing 'describe cluster' in 
 cassandra-cli.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Issue Comment Deleted] (CASSANDRA-5773) print cluster name in describe cluster

2013-07-17 Thread Philip Crotwell (JIRA)

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

Philip Crotwell updated CASSANDRA-5773:
---

Comment: was deleted

(was: Patch)

 print cluster name in describe cluster
 --

 Key: CASSANDRA-5773
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5773
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.6
Reporter: Philip Crotwell
Assignee: Philip Crotwell
Priority: Trivial
 Attachments: trunk-5773.txt


 Would be nice to print the cluster name when doing 'describe cluster' in 
 cassandra-cli.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (CASSANDRA-5774) Fix system.schema_triggers-related trigger/schema issues

2013-07-17 Thread Aleksey Yeschenko (JIRA)
Aleksey Yeschenko created CASSANDRA-5774:


 Summary: Fix system.schema_triggers-related trigger/schema issues
 Key: CASSANDRA-5774
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5774
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 2.0 beta 2
 Attachments: 5774.txt

Among other things, the patch does the following:
- adds missing schema_triggers to MigrationManager.resetLocalSchema()
- adds missing schema_triggers to SystemKeyspace.serializeSchema() - so that 
triggers would be part of schema version calculation
- adds missing schema_triggers to DefsTables.flushSchemaCFs()
- adds missing triggers to CFMetaData.toSchema(), so that CFs created via 
thrift with triggers from the beginning would serialize triggers
- removes triggers from CFMetaData.newIndexMetadata(), so that 2i CFs wouldn't 
inherit the triggers from the parent CF

There are other minor and not so minor changes, but these were the most 
critical ones. The patch also (unnecessarily) cleans up ColumnDefinition, but 
that was done to make it consistent with the new TriggerDefinition class.

The bulk of the patch is the updated thrift-gen files.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5774) Fix system.schema_triggers-related trigger/schema issues

2013-07-17 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-5774:
-

Attachment: 5774.txt

 Fix system.schema_triggers-related trigger/schema issues
 

 Key: CASSANDRA-5774
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5774
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Priority: Minor
  Labels: triggers
 Fix For: 2.0 beta 2

 Attachments: 5774.txt


 Among other things, the patch does the following:
 - adds missing schema_triggers to MigrationManager.resetLocalSchema()
 - adds missing schema_triggers to SystemKeyspace.serializeSchema() - so that 
 triggers would be part of schema version calculation
 - adds missing schema_triggers to DefsTables.flushSchemaCFs()
 - adds missing triggers to CFMetaData.toSchema(), so that CFs created via 
 thrift with triggers from the beginning would serialize triggers
 - removes triggers from CFMetaData.newIndexMetadata(), so that 2i CFs 
 wouldn't inherit the triggers from the parent CF
 There are other minor and not so minor changes, but these were the most 
 critical ones. The patch also (unnecessarily) cleans up ColumnDefinition, but 
 that was done to make it consistent with the new TriggerDefinition class.
 The bulk of the patch is the updated thrift-gen files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[1/3] git commit: Print cluster name in describe cluster. Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773

2013-07-17 Thread brandonwilliams
Updated Branches:
  refs/heads/cassandra-1.2 0feb59a97 - 9382c4b4c
  refs/heads/trunk 2ef78c689 - 09d3d2b83


Print cluster name in describe cluster.
Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773


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

Branch: refs/heads/cassandra-1.2
Commit: 9382c4b4c505f89ad23df0455ea0c7001317eb3c
Parents: 0feb59a
Author: Brandon Williams brandonwilli...@apache.org
Authored: Wed Jul 17 15:01:37 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Wed Jul 17 15:01:37 2013 -0500

--
 src/java/org/apache/cassandra/cli/CliClient.java | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9382c4b4/src/java/org/apache/cassandra/cli/CliClient.java
--
diff --git a/src/java/org/apache/cassandra/cli/CliClient.java 
b/src/java/org/apache/cassandra/cli/CliClient.java
index 9209b87..6857aea 100644
--- a/src/java/org/apache/cassandra/cli/CliClient.java
+++ b/src/java/org/apache/cassandra/cli/CliClient.java
@@ -2312,6 +2312,7 @@ public class CliClient
 sessionState.out.println(Cluster Information:);
 try
 {
+sessionState.out.println(   Name:  + 
thriftClient.describe_cluster_name());
 sessionState.out.println(   Snitch:  + 
thriftClient.describe_snitch());
 sessionState.out.println(   Partitioner:  + 
thriftClient.describe_partitioner());
 



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

2013-07-17 Thread brandonwilliams
Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 09d3d2b839172c37bd2a6605ff29bfbcb1d735bb
Parents: 2ef78c6 9382c4b
Author: Brandon Williams brandonwilli...@apache.org
Authored: Wed Jul 17 15:02:42 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Wed Jul 17 15:02:42 2013 -0500

--
 src/java/org/apache/cassandra/cli/CliClient.java | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/09d3d2b8/src/java/org/apache/cassandra/cli/CliClient.java
--



[2/3] git commit: Print cluster name in describe cluster. Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773

2013-07-17 Thread brandonwilliams
Print cluster name in describe cluster.
Patch by Philip Crotwell, reviewed by brandonwilliams for CASSANDRA-5773


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

Branch: refs/heads/trunk
Commit: 9382c4b4c505f89ad23df0455ea0c7001317eb3c
Parents: 0feb59a
Author: Brandon Williams brandonwilli...@apache.org
Authored: Wed Jul 17 15:01:37 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Wed Jul 17 15:01:37 2013 -0500

--
 src/java/org/apache/cassandra/cli/CliClient.java | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9382c4b4/src/java/org/apache/cassandra/cli/CliClient.java
--
diff --git a/src/java/org/apache/cassandra/cli/CliClient.java 
b/src/java/org/apache/cassandra/cli/CliClient.java
index 9209b87..6857aea 100644
--- a/src/java/org/apache/cassandra/cli/CliClient.java
+++ b/src/java/org/apache/cassandra/cli/CliClient.java
@@ -2312,6 +2312,7 @@ public class CliClient
 sessionState.out.println(Cluster Information:);
 try
 {
+sessionState.out.println(   Name:  + 
thriftClient.describe_cluster_name());
 sessionState.out.println(   Snitch:  + 
thriftClient.describe_snitch());
 sessionState.out.println(   Partitioner:  + 
thriftClient.describe_partitioner());
 



[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files

2013-07-17 Thread Alex Zarutin (JIRA)

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

Alex Zarutin commented on CASSANDRA-:
-

Is it going to trunk or cassandra-1.2?

 Allow sstableloader to handle a larger number of files
 --

 Key: CASSANDRA-
 URL: https://issues.apache.org/jira/browse/CASSANDRA-
 Project: Cassandra
  Issue Type: Improvement
  Components: Core, Tools
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
 Fix For: 1.2.7

 Attachments: -01.txt, -02.txt, -2.txt, 
 -fix-heap-and-streaming-1.2.patch, 
 -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, 
 CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt


 With the default heap size, sstableloader will OOM when there are roughly 25k 
 files in the directory to load.  It's easy to reach this number of files in a 
 single LCS column family.
 By avoiding creating all SSTableReaders up front in SSTableLoader, we should 
 be able to increase the number of files that sstableloader can handle 
 considerably.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5542) BulkLoader is broken in trunk

2013-07-17 Thread Yuki Morishita (JIRA)

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

Yuki Morishita updated CASSANDRA-5542:
--

Attachment: (was: 0001-change-streaming-procedure.patch)

 BulkLoader is broken in trunk
 -

 Key: CASSANDRA-5542
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5542
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Yuki Morishita
Assignee: Yuki Morishita
 Fix For: 2.0 beta 2

 Attachments: 0002-make-BulkLoader-work-with-SSTableReader.patch, 
 0003-update-for-post-CASSANDRA-5171.patch, 5542-fix-NPE.txt, 5542.txt


 After CASSANDRA-5015 and CASSANDRA-5521, we need CFMetaData to open 
 SSTable(Reader), especially to get bloom_filter_fp_chance and index_interval.
 When using bulkloader, CFMetaData is not available, so we cannot open SSTable 
 to be streamed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5542) BulkLoader is broken in trunk

2013-07-17 Thread Yuki Morishita (JIRA)

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

Yuki Morishita updated CASSANDRA-5542:
--

Attachment: 0001-change-streaming-procedure.patch

Thanks for the review.
Updated 0001 patch.

bq. Does separating initiated and receiving stream in StreamManager really buys 
us anything? (outside slightly complicating things)

We need to keep StreamResultFuture of the same plan ID when we are doing 
streaming on the same JVM. This happens when we bulk load via JMX method, or 
running StreamingTransferTest unit test.

bq. On failure (StreamSession.onError), we could (and probably should) send a 
message as long as the outgoing connection is opened (even if the incoming one 
is broken), so the current isConnected() is possibly a bit restrictive.

You are right. I changed to put null check on outgoing message handler before 
sending message instead.


 BulkLoader is broken in trunk
 -

 Key: CASSANDRA-5542
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5542
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Yuki Morishita
Assignee: Yuki Morishita
 Fix For: 2.0 beta 2

 Attachments: 0001-change-streaming-procedure.patch, 
 0002-make-BulkLoader-work-with-SSTableReader.patch, 
 0003-update-for-post-CASSANDRA-5171.patch, 5542-fix-NPE.txt, 5542.txt


 After CASSANDRA-5015 and CASSANDRA-5521, we need CFMetaData to open 
 SSTable(Reader), especially to get bloom_filter_fp_chance and index_interval.
 When using bulkloader, CFMetaData is not available, so we cannot open SSTable 
 to be streamed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5746) HHOM.countPendingHints is a trap for the unwary

2013-07-17 Thread Tyler Hobbs (JIRA)

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

Tyler Hobbs updated CASSANDRA-5746:
---

Attachment: 0002-Report-created-hint-count-by-endpoint.patch
0001-Remove-HHOM.countPendingHints.patch

0001 removes countPendingHints().

0002 adds a per-endpoint count through the new metrics system. I made 
HHOM.hintFor() non-static, as I couldn't see why the singleton couldn't be 
used.  Let me know if there was some motivation for that.

 HHOM.countPendingHints is a trap for the unwary
 ---

 Key: CASSANDRA-5746
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5746
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0 beta 2

 Attachments: 0001-Remove-HHOM.countPendingHints.patch, 
 0002-Report-created-hint-count-by-endpoint.patch


 countPendingHints can OOM the server fairly easily since it does a per-target 
 seq scan without paging.
 More generally, countPendingHints is far too slow to be useful for routine 
 monitoring.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5555) Allow sstableloader to handle a larger number of files

2013-07-17 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-:
---

Yes.

 Allow sstableloader to handle a larger number of files
 --

 Key: CASSANDRA-
 URL: https://issues.apache.org/jira/browse/CASSANDRA-
 Project: Cassandra
  Issue Type: Improvement
  Components: Core, Tools
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
 Fix For: 1.2.7

 Attachments: -01.txt, -02.txt, -2.txt, 
 -fix-heap-and-streaming-1.2.patch, 
 -fix-heap-and-streaming-1.2-v2.patch, cass__pic_8.png, 
 CASSANDRA-.txt, CASSANDRA-.txt, CASSANDRA-.txt


 With the default heap size, sstableloader will OOM when there are roughly 25k 
 files in the directory to load.  It's easy to reach this number of files in a 
 single LCS column family.
 By avoiding creating all SSTableReaders up front in SSTableLoader, we should 
 be able to increase the number of files that sstableloader can handle 
 considerably.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5752) Thrift tables are not supported from CqlPagingInputFormat

2013-07-17 Thread Alex Liu (JIRA)

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

Alex Liu updated CASSANDRA-5752:


Attachment: 5752-1-1.2-branch.txt

5752-1-1.2-branch.txt is attached. It doesn't use exception any more

 Thrift tables are not supported from CqlPagingInputFormat
 -

 Key: CASSANDRA-5752
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5752
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.6
Reporter: Jonathan Ellis
Assignee: Alex Liu
 Fix For: 1.2.7

 Attachments: 5752-1-1.2-branch.txt, 5752-1.2-branch.txt


 CqlPagingInputFormat inspects the system schema to generate the WHERE clauses 
 needed to page wide rows, but for a classic Thrift table there are no 
 entries for the default column names of key, column1, column2, ..., value 
 so CPIF breaks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

2013-07-17 Thread Christian Spriegel (JIRA)

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

Christian Spriegel commented on CASSANDRA-5704:
---

[~jbellis], [~brandon.williams]: I'm fine with a property. Thanks!

Is there any chance we can make it a cassandra.unsafesystem-property and 
apply the same behaviour to all system table operations? This would then also 
speed up schema changes, which are are also a pain for tests.

FWIW: I attached a patch which works nicely for me.


 Truncate flushes to disk again in 1.2, even with durable_writes=false
 -

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2.7, 2.0 beta 2

 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, 
 CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

2013-07-17 Thread Christian Spriegel (JIRA)

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

Christian Spriegel updated CASSANDRA-5704:
--

Attachment: 5704_unsafeSystem.txt

 Truncate flushes to disk again in 1.2, even with durable_writes=false
 -

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2.7, 2.0 beta 2

 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, 
 CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

2013-07-17 Thread Christian Spriegel (JIRA)

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

Christian Spriegel edited comment on CASSANDRA-5704 at 7/17/13 11:23 PM:
-

[~jbellis], [~brandon.williams]: I'm fine with a property. Thanks!

Is there any chance we can make it a cassandra.unsafesystem-property and 
apply the same behaviour to all system table operations? This would then also 
speed up schema changes, which are are also a pain for tests.

FWIW: I attached a patch which works nicely for me.

Update: Perhaps as a separate 2.0 ticket?


  was (Author: christianmovi):
[~jbellis], [~brandon.williams]: I'm fine with a property. Thanks!

Is there any chance we can make it a cassandra.unsafesystem-property and 
apply the same behaviour to all system table operations? This would then also 
speed up schema changes, which are are also a pain for tests.

FWIW: I attached a patch which works nicely for me.

  
 Truncate flushes to disk again in 1.2, even with durable_writes=false
 -

 Key: CASSANDRA-5704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.5
Reporter: Christian Spriegel
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 1.2.7, 2.0 beta 2

 Attachments: 5704_unsafeSystem.txt, 5704-v2.txt, 
 CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch


 I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my 
 JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
 With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
 My proposal is to make saveTruncationRecord() only flush when durableWrites 
 are enabled.
 My assumption is that if somebody turn off durable writes then he does not 
 mind if truncate is not guaranteed to be durable either.
 I successfully tested the following patch with my testsuite. Its as fast as 
 it was with 1.1 (maybe even faster!):
 {code}
 @@ -186,5 +186,8 @@ public class SystemTable
  String req = UPDATE system.%s SET truncated_at = truncated_at + %s 
 WHERE key = '%s';
  processInternal(String.format(req, LOCAL_CF, 
 truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
 -forceBlockingFlush(LOCAL_CF);
 +
 +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
 +if (ksm.durableWrites) // flush only when durable_writes are enabled
 +forceBlockingFlush(LOCAL_CF);
  }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


git commit: StorageService.getPartitioner is a static method

2013-07-17 Thread dbrosius
Updated Branches:
  refs/heads/trunk 09d3d2b83 - 2b53cf78f


StorageService.getPartitioner is a static method


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

Branch: refs/heads/trunk
Commit: 2b53cf78f53b333f90f0b3d55e209483d0434f75
Parents: 09d3d2b
Author: Dave Brosius dbros...@apache.org
Authored: Wed Jul 17 22:36:24 2013 -0400
Committer: Dave Brosius dbros...@apache.org
Committed: Wed Jul 17 22:36:24 2013 -0400

--
 src/java/org/apache/cassandra/cql3/functions/TokenFct.java | 2 +-
 src/java/org/apache/cassandra/service/StorageProxy.java| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b53cf78/src/java/org/apache/cassandra/cql3/functions/TokenFct.java
--
diff --git a/src/java/org/apache/cassandra/cql3/functions/TokenFct.java 
b/src/java/org/apache/cassandra/cql3/functions/TokenFct.java
index 21695ca..69e2bf4 100644
--- a/src/java/org/apache/cassandra/cql3/functions/TokenFct.java
+++ b/src/java/org/apache/cassandra/cql3/functions/TokenFct.java
@@ -32,7 +32,7 @@ import org.apache.cassandra.service.StorageService;
 public class TokenFct extends AbstractFunction
 {
 // The actual token function depends on the partitioner used
-private static final IPartitioner partitioner = 
StorageService.instance.getPartitioner();
+private static final IPartitioner partitioner = 
StorageService.getPartitioner();
 
 public static final Function.Factory factory = new Function.Factory()
 {

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b53cf78/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java 
b/src/java/org/apache/cassandra/service/StorageProxy.java
index ee1e29a..3b5b69e 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -1333,7 +1333,7 @@ public class StorageProxy implements StorageProxyMBean
 
 public static ListInetAddress getLiveSortedEndpoints(Keyspace keyspace, 
ByteBuffer key)
 {
-return getLiveSortedEndpoints(keyspace, 
StorageService.instance.getPartitioner().decorateKey(key));
+return getLiveSortedEndpoints(keyspace, 
StorageService.getPartitioner().decorateKey(key));
 }
 
 private static ListInetAddress getLiveSortedEndpoints(Keyspace keyspace, 
RingPosition pos)



[jira] [Commented] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1

2013-07-17 Thread Jason Brown (JIRA)

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

Jason Brown commented on CASSANDRA-5768:


lgtm. One (incredibly minor) optimization in Gossiper.checkSeedContact() would 
be to check the boolean before checking the map for the seed ep, like this:

{code}protected void checkSeedContact(InetAddress ep)
{
if (!seedContacted  seeds.contains(ep))
seedContacted = true;
}
{code}

It could be that the effort of me writing this comment is greater than the 
grand sum of all processing time saved by this optimization, but what the hell 
:).


 If a Seed can't be contacted, a new node comes up as a cluster of 1
 ---

 Key: CASSANDRA-5768
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Andy Cobley
Assignee: Brandon Williams
Priority: Minor
 Fix For: 2.0 beta 2

 Attachments: 5768.txt


 Setting up a new test cluster using  2.0.0-beta1 and I noticed the following 
 behaviour with vnodes turned on.  
 I bring up one node all well and good.  however if I bring up a second node, 
 that can't contact the first (the first being the seed for the second) after 
 a short period of time, the second goes ahead and assumes it's the only node 
 and bootstraps with all tokens.  
 NOTE also this email from Robert Coli 
 To: u...@cassandra.apache.org
 Obviously if you have defined a seed and cannot contact it, the node should 
 not start as a cluster of one. I have a to-do list item to file a JIRA on the 
 subject, but if you wanted to file and link us, that'd be super. :)
 Startup trace (from the can't contact the seed messages below).
 http://aep.appspot.com/display/ABcWltCES1srzPrj5CkS69-GB8o/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CASSANDRA-5768) If a Seed can't be contacted, a new node comes up as a cluster of 1

2013-07-17 Thread Jason Brown (JIRA)

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

Jason Brown commented on CASSANDRA-5768:


Also, is there any harm in adding this to 1.2? Seems rather innocuous, I think.

 If a Seed can't be contacted, a new node comes up as a cluster of 1
 ---

 Key: CASSANDRA-5768
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5768
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 2.0 beta 1
Reporter: Andy Cobley
Assignee: Brandon Williams
Priority: Minor
 Fix For: 2.0 beta 2

 Attachments: 5768.txt


 Setting up a new test cluster using  2.0.0-beta1 and I noticed the following 
 behaviour with vnodes turned on.  
 I bring up one node all well and good.  however if I bring up a second node, 
 that can't contact the first (the first being the seed for the second) after 
 a short period of time, the second goes ahead and assumes it's the only node 
 and bootstraps with all tokens.  
 NOTE also this email from Robert Coli 
 To: u...@cassandra.apache.org
 Obviously if you have defined a seed and cannot contact it, the node should 
 not start as a cluster of one. I have a to-do list item to file a JIRA on the 
 subject, but if you wanted to file and link us, that'd be super. :)
 Startup trace (from the can't contact the seed messages below).
 http://aep.appspot.com/display/ABcWltCES1srzPrj5CkS69-GB8o/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira