from:"Tyler Patterson \(JIRA\)"

[jira] [Commented] (CASSANDRA-5142) ColumnFamily recreated on ALTER TABLE from CQL3

2013-01-15 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-5142:


I just tried it on osx 10.7.5 with java 1.6.0_37. The error did not happen:
{code}
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
19.35.0]
Use HELP for help.
cqlsh CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
cqlsh USE ks;
cqlsh:ks CREATE TABLE users (userid text, emails set text , firstname text, 
lastname text, locations list text , PRIMARY KEY (userid));
cqlsh:ks INSERT INTO users (userid, emails, firstname , lastname , locations ) 
VALUES ('bilbo', { 'a...@asdf.com', 'q...@qwer.com'}, 'bilbo', 'baggins', [ 
'the shire', 'rivendale', 'lonely mountain']) ;
cqlsh:ks INSERT INTO users (userid,  firstname , lastname , locations ) VALUES 
('frodo', 'Frodo', 'Baggins', [ 'the shire', 'rivendale', 'rohan', 'mordor']) ;
cqlsh:ks SELECT * FROM users ;

 userid | emails | firstname | lastname | locations
++---+--+-
  bilbo | {q...@qwer.com, a...@asdf.com} | bilbo |  baggins | [the shire, 
rivendale, lonely mountain]
  frodo |   null | Frodo |  Baggins |   [the shire, 
rivendale, rohan, mordor]

cqlsh:ks ALTER TABLE users ADD todo map timestamp, reminder_text;
Bad Request: line 1:43 no viable alternative at input 'reminder_text'
cqlsh:ks ALTER TABLE users ADD todo map timestamp, text;
cqlsh:ks UPDATE users SET todo = { '2012-9-24' : 'enter mordor', '2012-10-2 
12:00' : 'throw ring into mount doom' } WHERE userid='frodo';
cqlsh:ks SELECT * FROM users ;

 userid | emails | firstname | lastname | locations 
  | todo
++---+--+-+
  bilbo | {q...@qwer.com, a...@asdf.com} | bilbo |  baggins | [the shire, 
rivendale, lonely mountain] |   
null
  frodo |   null | Frodo |  Baggins |   [the shire, 
rivendale, rohan, mordor] | {2012-09-24 00:00:00-0600: enter mordor, 2012-10-02 
12:00:00-0600: throw ring into mount doom}

{code}

 ColumnFamily recreated on ALTER TABLE from CQL3
 ---

 Key: CASSANDRA-5142
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5142
 Project: Cassandra
  Issue Type: Bug
 Environment: MacOSX 10.8.2, Java 7u10, Cassandra 1.2.0 from brew
Reporter: Andrew Garman
Assignee: Tyler Patterson

 CQL session:
 ===
 cqlsh:demodb SELECT * FROM users 
  userid | emails | firstname | lastname | 
 locations
 ++---+--+-
   bilbo |   {bilbo10i...@wankdb.com} | bilbo |  baggins | [the 
 shire, rivendell, lonely mountain]
   frodo | {bagg...@gmail.com, f...@baggins.com} | Frodo |  Baggins |   
 [the shire, rivendell, rohan, mordor]
 cqlsh:demodb ALTER TABLE users ADD todo map timestamp, reminder_text;
 Bad Request: Failed parsing statement: [ALTER TABLE users ADD todo map 
 timestamp, reminder_text;] reason: NullPointerException null
 cqlsh:demodb ALTER TABLE users ADD todo map timestamp, text;
 cqlsh:demodb UPDATE users 
   ... SET todo = { '2012-9-24' : 'enter mordor',
   ... '2012-10-2 12:00' : 'throw ring into mount doom' }
   ... WHERE userid = 'frodo';
 cqlsh:demodb SELECT * FROM users 
   ... ;
  userid | emails | firstname | lastname | locations | todo
 ++---+--+---+
   frodo |   null |  null | null |  null | {2012-09-24 
 00:00:00-0400: enter mordor, 2012-10-02 12:00:00-0400: throw ring into mount 
 doom}
 ==
 So at this point, where's my data?

--
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-4446) nodetool drain sometimes doesn't mark commitlog fully flushed

2013-01-04 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4446:


It always replays 3 mutations when I follow these steps:
{code}
bin/cassandra
tools/bin/cassandra-stress --operation=INSERT --num-keys=10
bin/nodetool drain
bin/cassandra
{code}

This is on trunk, commit acf30622

 nodetool drain sometimes doesn't mark commitlog fully flushed
 -

 Key: CASSANDRA-4446
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4446
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.10
 Environment: ubuntu 10.04 64bit
 Linux HOSTNAME 2.6.32-345-ec2 #48-Ubuntu SMP Wed May 2 19:29:55 UTC 2012 
 x86_64 GNU/Linux
 sun JVM
 cassandra 1.0.10 installed from apache deb
Reporter: Robert Coli
Assignee: Tyler Patterson
 Attachments: 
 cassandra.1.0.10.replaying.log.after.exception.during.drain.txt


 I recently wiped a customer's QA cluster. I drained each node and verified 
 that they were drained. When I restarted the nodes, I saw the commitlog 
 replay create a memtable and then flush it. I have attached a sanitized log 
 snippet from a representative node at the time. 
 It appears to show the following :
 1) Drain begins
 2) Drain triggers flush
 3) Flush triggers compaction
 4) StorageService logs DRAINED message
 5) compaction thread excepts
 6) on restart, same CF creates a memtable
 7) and then flushes it [1]
 The columnfamily involved in the replay in 7) is the CF for which the 
 compaction thread excepted in 5). This seems to suggest a timing issue 
 whereby the exception in 5) prevents the flush in 3) from marking all the 
 segments flushed, causing them to replay after restart.
 In case it might be relevant, I did an online change of compaction strategy 
 from Leveled to SizeTiered during the uptime period preceding this drain.
 [1] Isn't commitlog replay not supposed to automatically trigger a flush in 
 modern cassandra?

--
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-5096) Transient schema disagreement error while under high concurrency

2013-01-01 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-5096:
--

 Summary: Transient schema disagreement error while under high 
concurrency
 Key: CASSANDRA-5096
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5096
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.8
 Environment: ccm, dtest, ubuntu, C*1.1 (commit 8a3b291)
Reporter: Tyler Patterson


To duplicate:
 - Create a 4-node cluster
 - Create 4 threads, then create keyspaces or columnfamilies as fast as 
possible from each thread
 - You will usually get an error Schema versions disagree, (try again later)
 - Here is example code to duplicate the issue: 
https://github.com/tpatterson/cassandra-dtest/commit/f1fee7ef4296de5cb9e346568ba39123104b5f87

Notes: 
 - Hamilton originally found this error while testing solr: 
https://datastax.jira.com/browse/DSP-1323
 - No errors were observed in the log of any of the nodes
 - The schemas do not disagree after the failure

Exception:
{code}
==
ERROR: apply changes to many nodes concurrently.
--
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/nose/case.py, line 197, in 
runTest
self.test(*self.arg)
  File /home/automaton/cassandra-dtest/tools.py, line 206, in wrapped
f(obj)
  File /home/automaton/cassandra-dtest/concurrent_schema_changes_test.py, 
line 398, in inner_func
self.create_ks(cursor, ks_name, node_num)
  File /home/automaton/cassandra-dtest/dtest.py, line 191, in create_ks
cursor.execute(query % (name, 'SimpleStrategy', 
'strategy_options:replication_factor=%d' % rf))
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 80, in 
execute
response = self.get_response(prepared_q, cl)
  File /usr/local/lib/python2.7/dist-packages/cql/thrifteries.py, line 80, in 
get_response
return self.handle_cql_execution_errors(doquery, compressed_q, compress)
  File /usr/local/lib/python2.7/dist-packages/cql/thrifteries.py, line 100, 
in handle_cql_execution_errors
raise cql.IntegrityError(Schema versions disagree, (try again later).)
IntegrityError: Schema versions disagree, (try again later).
{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-5096) Transient schema disagreement error while under high concurrency

2013-01-01 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-5096:
---

Description: 
To duplicate:
 - Create a 4-node cluster
 - Create 4 threads, then create keyspaces or columnfamilies as fast as 
possible from each thread
 - You will usually get an error Schema versions disagree, (try again later)
 - Here is example code to duplicate the issue: 
https://github.com/tpatterson/cassandra-dtest/commit/f1fee7ef4296de5cb9e346568ba39123104b5f87

Notes: 
 - Hamilton originally found this error while testing solr.
 - No errors were observed in the log of any of the nodes
 - The schemas do not disagree after the failure

Exception:
{code}
==
ERROR: apply changes to many nodes concurrently.
--
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/nose/case.py, line 197, in 
runTest
self.test(*self.arg)
  File /home/automaton/cassandra-dtest/tools.py, line 206, in wrapped
f(obj)
  File /home/automaton/cassandra-dtest/concurrent_schema_changes_test.py, 
line 398, in inner_func
self.create_ks(cursor, ks_name, node_num)
  File /home/automaton/cassandra-dtest/dtest.py, line 191, in create_ks
cursor.execute(query % (name, 'SimpleStrategy', 
'strategy_options:replication_factor=%d' % rf))
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 80, in 
execute
response = self.get_response(prepared_q, cl)
  File /usr/local/lib/python2.7/dist-packages/cql/thrifteries.py, line 80, in 
get_response
return self.handle_cql_execution_errors(doquery, compressed_q, compress)
  File /usr/local/lib/python2.7/dist-packages/cql/thrifteries.py, line 100, 
in handle_cql_execution_errors
raise cql.IntegrityError(Schema versions disagree, (try again later).)
IntegrityError: Schema versions disagree, (try again later).
{code}

  was:
To duplicate:
 - Create a 4-node cluster
 - Create 4 threads, then create keyspaces or columnfamilies as fast as 
possible from each thread
 - You will usually get an error Schema versions disagree, (try again later)
 - Here is example code to duplicate the issue: 
https://github.com/tpatterson/cassandra-dtest/commit/f1fee7ef4296de5cb9e346568ba39123104b5f87

Notes: 
 - Hamilton originally found this error while testing solr: 
https://datastax.jira.com/browse/DSP-1323
 - No errors were observed in the log of any of the nodes
 - The schemas do not disagree after the failure

Exception:
{code}
==
ERROR: apply changes to many nodes concurrently.
--
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/nose/case.py, line 197, in 
runTest
self.test(*self.arg)
  File /home/automaton/cassandra-dtest/tools.py, line 206, in wrapped
f(obj)
  File /home/automaton/cassandra-dtest/concurrent_schema_changes_test.py, 
line 398, in inner_func
self.create_ks(cursor, ks_name, node_num)
  File /home/automaton/cassandra-dtest/dtest.py, line 191, in create_ks
cursor.execute(query % (name, 'SimpleStrategy', 
'strategy_options:replication_factor=%d' % rf))
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 80, in 
execute
response = self.get_response(prepared_q, cl)
  File /usr/local/lib/python2.7/dist-packages/cql/thrifteries.py, line 80, in 
get_response
return self.handle_cql_execution_errors(doquery, compressed_q, compress)
  File /usr/local/lib/python2.7/dist-packages/cql/thrifteries.py, line 100, 
in handle_cql_execution_errors
raise cql.IntegrityError(Schema versions disagree, (try again later).)
IntegrityError: Schema versions disagree, (try again later).
{code}


 Transient schema disagreement error while under high concurrency
 

 Key: CASSANDRA-5096
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5096
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.8
 Environment: ccm, dtest, ubuntu, C*1.1 (commit 8a3b291)
Reporter: Tyler Patterson

 To duplicate:
  - Create a 4-node cluster
  - Create 4 threads, then create keyspaces or columnfamilies as fast as 
 possible from each thread
  - You will usually get an error Schema versions disagree, (try again later)
  - Here is example code to duplicate the issue: 
 https://github.com/tpatterson/cassandra-dtest/commit/f1fee7ef4296de5cb9e346568ba39123104b5f87
 Notes: 
  - Hamilton originally found this error while testing solr.
  - No errors were observed in the log of any of the nodes
  - The schemas do not disagree after the failure
 Exception:
 {code}

[jira] [Commented] (CASSANDRA-4919) StorageProxy.getRangeSlice sometimes returns incorrect number of columns

2012-11-27 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4919:


Just added wide_slice_test to putget_test.py in the dtests.

 StorageProxy.getRangeSlice sometimes returns incorrect number of columns
 

 Key: CASSANDRA-4919
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4919
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.6
Reporter: Piotr Kołaczkowski
Assignee: Piotr Kołaczkowski
 Fix For: 1.1.7, 1.2.0 rc1

 Attachments: 
 0001-Fix-getRangeSlice-paging-reset-predicate-after-fetch.patch


 When deployed on a single node, number of columns is correct.
 When deployed on a cluster, total number of returned columns is slightly 
 lower than desired. 

--
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-4981) Error when starting a node with vnodes while counter-add operations underway

2012-11-21 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4981:
--

 Summary: Error when starting a node with vnodes while counter-add 
operations underway
 Key: CASSANDRA-4981
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4981
 Project: Cassandra
  Issue Type: Bug
 Environment: 2-node cluster on ec2, ubuntu, cassandra-1.2.0 commit 
a32eb9f7d2f2868e8154d178e96e045859e1d855
Reporter: Tyler Patterson


Start both nodes, start stress on one node like this: cassandra-stress 
--replication-factor=2 --operation=COUNTER_ADD

While that is running: On the other node, kill cassandra, wait for nodetool 
status to show the node as down, and restart cassandra. I sometimes have to 
kill and restart cassandra several times to get the problem to happen.

{code}
ERROR 15:39:33,198 Exception in thread Thread[MutationStage:16,5,main]
java.lang.AssertionError
at 
org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:748)
at 
org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:762)
at 
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:95)
at 
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:2426)
at 
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:396)
at 
org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:755)
at 
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:53)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
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)
{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-4981) Error when starting a node with vnodes while counter-add operations underway

2012-11-21 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4981:
---

Description: 
Start both nodes, start stress on one node like this: cassandra-stress 
--replication-factor=2 --operation=COUNTER_ADD

While that is running: On the other node, kill cassandra, wait for nodetool 
status to show the node as down, and restart cassandra. I sometimes have to 
kill and restart cassandra several times to get the problem to happen.

I get this error several times in the log:

{code}
ERROR 15:39:33,198 Exception in thread Thread[MutationStage:16,5,main]
java.lang.AssertionError
at 
org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:748)
at 
org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:762)
at 
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:95)
at 
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:2426)
at 
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:396)
at 
org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:755)
at 
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:53)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
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)
{code}

  was:
Start both nodes, start stress on one node like this: cassandra-stress 
--replication-factor=2 --operation=COUNTER_ADD

While that is running: On the other node, kill cassandra, wait for nodetool 
status to show the node as down, and restart cassandra. I sometimes have to 
kill and restart cassandra several times to get the problem to happen.

{code}
ERROR 15:39:33,198 Exception in thread Thread[MutationStage:16,5,main]
java.lang.AssertionError
at 
org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:748)
at 
org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:762)
at 
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:95)
at 
org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:2426)
at 
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:396)
at 
org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:755)
at 
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:53)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
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)
{code}


 Error when starting a node with vnodes while counter-add operations underway
 

 Key: CASSANDRA-4981
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4981
 Project: Cassandra
  Issue Type: Bug
 Environment: 2-node cluster on ec2, ubuntu, cassandra-1.2.0 commit 
 a32eb9f7d2f2868e8154d178e96e045859e1d855
Reporter: Tyler Patterson

 Start both nodes, start stress on one node like this: cassandra-stress 
 --replication-factor=2 --operation=COUNTER_ADD
 While that is running: On the other node, kill cassandra, wait for nodetool 
 status to show the node as down, and restart cassandra. I sometimes have to 
 kill and restart cassandra several times to get the problem to happen.
 I get this error several times in the log:
 {code}
 ERROR 15:39:33,198 Exception in thread Thread[MutationStage:16,5,main]
 java.lang.AssertionError
   at 
 org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:748)
   at 
 org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:762)
   at 
 org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:95)
   at 
 org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:2426)
   at 
 org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:396)
   at 
 org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:755)
   at 
 org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:53)
   at

[jira] [Updated] (CASSANDRA-4981) Error when starting a node with vnodes while counter-add operations underway

2012-11-21 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4981:
---

Attachment: system.log

 Error when starting a node with vnodes while counter-add operations underway
 

 Key: CASSANDRA-4981
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4981
 Project: Cassandra
  Issue Type: Bug
 Environment: 2-node cluster on ec2, ubuntu, cassandra-1.2.0 commit 
 a32eb9f7d2f2868e8154d178e96e045859e1d855
Reporter: Tyler Patterson
 Attachments: system.log


 Start both nodes, start stress on one node like this: cassandra-stress 
 --replication-factor=2 --operation=COUNTER_ADD
 While that is running: On the other node, kill cassandra, wait for nodetool 
 status to show the node as down, and restart cassandra. I sometimes have to 
 kill and restart cassandra several times to get the problem to happen.
 I get this error several times in the log:
 {code}
 ERROR 15:39:33,198 Exception in thread Thread[MutationStage:16,5,main]
 java.lang.AssertionError
   at 
 org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:748)
   at 
 org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:762)
   at 
 org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:95)
   at 
 org.apache.cassandra.service.StorageService.getNaturalEndpoints(StorageService.java:2426)
   at 
 org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:396)
   at 
 org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:755)
   at 
 org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:53)
   at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
   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)
 {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] [Created] (CASSANDRA-4857) FileNotFoundException after create-drop-create keyspace

2012-10-24 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4857:
--

 Summary: FileNotFoundException after create-drop-create keyspace
 Key: CASSANDRA-4857
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4857
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra trunk (565c576)
Reporter: Tyler Patterson


{code}
 INFO [CompactionExecutor:28] 2012-10-24 14:32:22,756 CompactionTask.java (line 
116) Compacting 
[SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-1-Data.db'),
 
SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-6-Data.db'),
 
SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-4-Data.db'),
 
SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-3-Data.db'),
 
SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-2-Data.db')]
ERROR [CompactionExecutor:28] 2012-10-24 14:32:22,758 CassandraDaemon.java 
(line 132) Exception in thread Thread[CompactionExecutor:28,1,main]
java.lang.RuntimeException: java.io.FileNotFoundException: 
/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-1-Data.db (No such 
file or directory)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:51)
at 
org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1094)
at 
org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:51)
at 
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:937)
at 
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:949)
at 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:127)
at 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:133)
at 
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:128)
at 
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at 
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:69)
at 
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:179)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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:680)
Caused by: java.io.FileNotFoundException: 
/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-1-Data.db (No such 
file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
at 
org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:64)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:70)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:47)
... 17 more
{code}

This error has been happening consistently using a modified version of the 
twissandra project. We have a script that loads in a bunch of tweet data. The 
error happens when I drop the keyspace, then recreate it and the 
columnfamilies, and rerun the script to load the data again.

--
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-4857) FileNotFoundException after create-drop-create keyspace

2012-10-24 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4857:
---

Attachment: system.log

My full system.log 

 FileNotFoundException after create-drop-create keyspace
 ---

 Key: CASSANDRA-4857
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4857
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra trunk (565c576)
Reporter: Tyler Patterson
 Attachments: system.log


 {code}
  INFO [CompactionExecutor:28] 2012-10-24 14:32:22,756 CompactionTask.java 
 (line 116) Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-1-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-6-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-4-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-3-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-2-Data.db')]
 ERROR [CompactionExecutor:28] 2012-10-24 14:32:22,758 CassandraDaemon.java 
 (line 132) Exception in thread Thread[CompactionExecutor:28,1,main]
 java.lang.RuntimeException: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-1-Data.db (No 
 such file or directory)
   at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:51)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1094)
   at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:51)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:937)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:949)
   at 
 org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:127)
   at 
 org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:133)
   at 
 org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:128)
   at 
 org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
   at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
   at 
 org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:69)
   at 
 org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:179)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   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:680)
 Caused by: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/Twissandra/Tweet/Twissandra-Tweet-ia-1-Data.db (No 
 such file or directory)
   at java.io.RandomAccessFile.open(Native Method)
   at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
   at 
 org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:64)
   at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:70)
   at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:47)
   ... 17 more
 {code}
 This error has been happening consistently using a modified version of the 
 twissandra project. We have a script that loads in a bunch of tweet data. The 
 error happens when I drop the keyspace, then recreate it and the 
 columnfamilies, and rerun the script to load the data again.

--
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-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-10-11 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4698:


Verified that the issue is fixed for 1.1.6-tentative

 Keyspace disappears when upgrading node from cassandra-1.1.1 to 
 cassandra-1.1.5
 ---

 Key: CASSANDRA-4698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4698
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
 Environment: ubuntu. JNA not installed.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.6

 Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log, 
 start_1.1.5_system.log


 Here is how I got the problem to happen:
 1. Get this zipped data directory (about 33Mb):
   scp cass@50.57.69.32:/home/cass/cassandra.zip ./ (password cass)
 2. Unzip it in /var/lib/
 3. clone the cassandra git repo
 4. git checkout cassandra-1.1.1; ant jar;
 5. bin/cassandra 
 6. Run cqlsh -3, then DESC COLUMNFAMILIES; Note the presence of Keyspace 
 performance_tests
 7. pkill -f cassandra; git checkout cassandra-1.1.5; ant realclean; ant jar;
 8. bin/cassandra
 9. Run cqlsh -3, then DESC COLUMNFAMILIES; Note that there is no 
 performance_tests keyspace

--
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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)

2012-09-27 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4687:


I just spent a day trying to reproduce this error, to no avail. Here is what I 
tried for reference:
I wrote a python stress script, then ran it in 50 threads from 3 different 
EC2 instances, all stressing one EC2 node running cassandra-1.1.5. The 
processor load on the cassandra node was pegged at 100% (or very close to) the 
entire time each test was running.

The first version of the python stress script created text keys varying in 
length up to 1 chars. It inserted and read one key at a time, where keys 
were randomly chosen from a pool of 10,000,000 keys. Cassandra had a key_cache 
size of 10mb. This test used cql, and inserted and read one key and column at a 
time.

The second version of the stress script worked the same as the first, but used 
pycassa.

Version 3 also used pycassa, but did batch_insert and multiget, each with 1000 
keys at a time. It also deleted a random key after every batch_insert and 
multiget. For this test I also ran cassandra-stress --operation=COUNTER_ADD 
and cassandra-stress --operation-COUNTER_GET

version 4 was the similar to version 3, but used int32 keys instead of text.

I played with some other settings like key_cache and compaction_strategy_class 
during some of the tests. I never was able to get the error to happen.

 Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
 ---

 Key: CASSANDRA-4687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
 Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single 
 node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
 Fix For: 1.1.6

 Attachments: 4687-debugging.txt


 Under heavy write load sometimes cassandra fails with assertion error.
 git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
 works fine if global key/row caches disabled in code.
 {quote}
 java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in 
 /var/lib/cassandra/data/...-he-1-Data.db
   at 
 org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
   at 
 org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
   at 
 org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
   at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
   at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
   at org.apache.cassandra.db.Table.getRow(Table.java:378)
   at 
 org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
   at 
 org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
   at 
 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
   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)
 {quote}

--
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-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-26 Thread Tyler Patterson (JIRA)

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

Tyler Patterson commented on CASSANDRA-4698:

[~xedin] I ran this test:

I set up a 1-node 1.1.1 cluster with that broken keyspace mentioned at the
beginning of this test, then I bootstrapped another 1.1.1 node and verified
that the keyspace was visible to the second node. The timestamps were 16 digits
long on both nodes.

Then I took down node 2, upgraded it to 1.1.5, and started it back up. The
keyspace was not visible. In cassandra-cli I did was not able to see the
timestamps on node 2, here is what the output looked like:
{code}
[default@system] list schema_columns;
Using default limit of 100
Using default column limit of 100
---
RowKey: performance_tests

1 Row Returned.
Elapsed time: 2 msec(s).
{code}
I got the same results for list schema_keyspaces and list schema_columnfamilies.

On node1 (which was still on 1.1.1) the timestamps were still 16-digits long. I
don't know how to get the now-incorrect remote schema (on node2) to overwrite
the local correct schema (on node1).

Keyspace disappears when upgrading node from cassandra-1.1.1 to
cassandra-1.1.5
---

Key: CASSANDRA-4698
URL: https://issues.apache.org/jira/browse/CASSANDRA-4698
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: ubuntu. JNA not installed.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6

Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log,
start_1.1.5_system.log

Here is how I got the problem to happen:
1. Get this zipped data directory (about 33Mb):
scp cass@50.57.69.32:/home/cass/cassandra.zip ./ (password cass)
2. Unzip it in /var/lib/
3. clone the cassandra git repo
4. git checkout cassandra-1.1.1; ant jar;
5. bin/cassandra
6. Run cqlsh -3, then DESC COLUMNFAMILIES; Note the presence of Keyspace
performance_tests
7. pkill -f cassandra; git checkout cassandra-1.1.5; ant realclean; ant jar;
8. bin/cassandra
9. Run cqlsh -3, then DESC COLUMNFAMILIES; Note that there is no
performance_tests keyspace

--
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-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-26 Thread Tyler Patterson (JIRA)

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

Tyler Patterson commented on CASSANDRA-4698:

I hadn't applied the patch, but I just tried it again with the patch. With the
patch the keyspace disappearing bug didn't happen. The timestamps all were
16-digits long on both nodes after upgrading one node.

Keyspace disappears when upgrading node from cassandra-1.1.1 to
cassandra-1.1.5
---

Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log,
start_1.1.5_system.log

[jira] [Commented] (CASSANDRA-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-26 Thread Tyler Patterson (JIRA)

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

Tyler Patterson commented on CASSANDRA-4698:

I re-ran the test like the one described earlier today, but after node2 was
upgraded to 1.1.5 (with the patch), I followed Pavel's instructions:
start first and second, stop second, run resetschema on first, stop first,
start second, start first

Both nodes then showed 16-digit timestamps with 3 zeros at the end.

Keyspace disappears when upgrading node from cassandra-1.1.1 to
cassandra-1.1.5
---

Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log,
start_1.1.5_system.log

[jira] [Commented] (CASSANDRA-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-26 Thread Tyler Patterson (JIRA)

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

Tyler Patterson commented on CASSANDRA-4698:

Per Pavel's request I ran the test again. Everything checked out, here are the
steps followed:

1: get that data onto both nodes in a 1.1.1 cluster
2: upgrade and start node2 on 1.1.5+patch
3: stop both nodes
4: start node1 (1.1.1) and verify that timestamps are fixed (zero last 3
digits)
5: stop node1
6: start node2 (1.1.5+patch), verify that timestamps are fixed (3 zeros)
7: nodetool resetlocalschema on node2
8: Verify that the troublesome keyspace is *not* present on node2
9: stop node2
10: start node1
11: start node2
12: verify that the troublesome keyspace appears on node2 and timestamps are
fixed (3 zeros)

Keyspace disappears when upgrading node from cassandra-1.1.1 to
cassandra-1.1.5
---

Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log,
start_1.1.5_system.log

[jira] [Commented] (CASSANDRA-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-25 Thread Tyler Patterson (JIRA)

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

Tyler Patterson commented on CASSANDRA-4698:

{quote}Tyler, can you please test the scenario when local correct schema data
are getting overriden by incorrect remote (as seen at CASSANDRA-4561)?{quote}
[~xedin] Could you explain what you mean by local and remote schemas, and how I
can go about testing this? Thanks

Keyspace disappears when upgrading node from cassandra-1.1.1 to
cassandra-1.1.5
---

Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log,
start_1.1.5_system.log

[jira] [Commented] (CASSANDRA-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-24 Thread Tyler Patterson (JIRA)

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

Tyler Patterson commented on CASSANDRA-4698:

{quote}It sounds like this reproduces on a single node? No schema disagreement
should be necessary/possible.{quote}
yes, this happened on a single node.

{quote} Can you try this test out and let me know if the keyspace reappears?
...{quote}
Yes. I did those steps on one of the columnfamilies in the keyspace and the
data did indeed come back.

Keyspace disappears when upgrading node from cassandra-1.1.1 to
cassandra-1.1.5
---

Attachments: start_1.1.1_system.log, start_1.1.5_system.log

[jira] [Created] (CASSANDRA-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-21 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4698:
--

 Summary: Keyspace disappears when upgrading node from 
cassandra-1.1.1 to cassandra-1.1.5
 Key: CASSANDRA-4698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4698
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu. JNA not installed.
Reporter: Tyler Patterson


Here is how I got the problem to happen:

1. Get this zipped data directory (about 33Mb):
  scp cass@50.57.69.32:/home/cass/cassandra.zip ./ (password cass)
2. Unzip it in /var/lib/
3. clone the cassandra git repo
4. git checkout cassandra-1.1.1; ant jar;
5. bin/cassandra 
6. Run cqlsh -3, then DESC COLUMNFAMILIES; Note the presence of Keyspace 
performance_tests
7. pkill -f cassandra; git checkout cassandra-1.1.5; ant realclean; ant jar;
8. bin/cassandra
9. Run cqlsh -3, then DESC COLUMNFAMILIES; Note that there is no 
performance_tests keyspace

--
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-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5

2012-09-21 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4698:
---

Attachment: start_1.1.5_system.log
start_1.1.1_system.log

These are the log files after starting 1.1.1 and 1.1.5 respectively

 Keyspace disappears when upgrading node from cassandra-1.1.1 to 
 cassandra-1.1.5
 ---

 Key: CASSANDRA-4698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4698
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.5
 Environment: ubuntu. JNA not installed.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.6

 Attachments: start_1.1.1_system.log, start_1.1.5_system.log


 Here is how I got the problem to happen:
 1. Get this zipped data directory (about 33Mb):
   scp cass@50.57.69.32:/home/cass/cassandra.zip ./ (password cass)
 2. Unzip it in /var/lib/
 3. clone the cassandra git repo
 4. git checkout cassandra-1.1.1; ant jar;
 5. bin/cassandra 
 6. Run cqlsh -3, then DESC COLUMNFAMILIES; Note the presence of Keyspace 
 performance_tests
 7. pkill -f cassandra; git checkout cassandra-1.1.5; ant realclean; ant jar;
 8. bin/cassandra
 9. Run cqlsh -3, then DESC COLUMNFAMILIES; Note that there is no 
 performance_tests keyspace

--
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-4689) Log error when using IN together with ORDER BY

2012-09-19 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4689:
--

 Summary: Log error when using IN together with ORDER BY
 Key: CASSANDRA-4689
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
 Project: Cassandra
  Issue Type: Bug
 Environment: built from source on cassandra-1.1 
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich


{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY 
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}

The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line 
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select 
clause.
at 
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at 
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at 
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at 
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at 
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
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)
{code}

NOTE: This issue appears similar to 
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user perspective, 
even though 4612 was verified as fixed.

--
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] [Resolved] (CASSANDRA-4036) cqlsh: EOF during multiline statement

2012-09-07 Thread Tyler Patterson (JIRA)


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

Tyler Patterson resolved CASSANDRA-4036.


Resolution: Cannot Reproduce

I couldn't reproduce it either this time.

 cqlsh: EOF during multiline statement
 -

 Key: CASSANDRA-4036
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4036
 Project: Cassandra
  Issue Type: Bug
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Trivial
  Labels: cql, cqlsh

 press CTRL-d while at the beginning of a line in a multi-line statement. 
 It should exit cqlsh or the multiline statement, but instead it only prints 
 another.... 

--
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-4612) cql error with ORDER BY when using IN

2012-09-04 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4612:
--

 Summary: cql error with ORDER BY when using IN
 Key: CASSANDRA-4612
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu, cassandra trunk (commit 
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich


{code}
CREATE TABLE test(
my_id varchar, 
col1 int, 
value varchar, 
PRIMARY KEY (my_id, col1)
);

INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}

The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line 
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at 
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at 
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at 
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at 
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at 
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at 
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at 
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at 
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
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)
{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] [Created] (CASSANDRA-4614) CREATE KEYSPACE error with cqlsh -3 on trunk

2012-09-04 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4614:
--

 Summary: CREATE KEYSPACE error with cqlsh -3 on trunk
 Key: CASSANDRA-4614
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4614
 Project: Cassandra
  Issue Type: Bug
 Environment: current trunk 769fe895a36868c47101f681f5fdd721bee1ad62
Reporter: Tyler Patterson
Assignee: paul cannon



{code}
cqlsh create KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND 
strategy_options:replication_factor = 1;
Bad Request: line 1:80 mismatched input ':' expecting '='
{code}
There is no error in the cassandra log.

--
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-4592) CQL COPY TO command doesn't work with python cassandra-dbapi2

2012-08-30 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4592:
--

 Summary: CQL COPY TO command doesn't work with python 
cassandra-dbapi2
 Key: CASSANDRA-4592
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4592
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu, dtest, ccm cluster, cassandra 1.1.4
Reporter: Tyler Patterson


Running the COPY TO command produces the below error, though running the same 
COPY TO command in cqlsh in the exact same cluster works fine:
{code}
==
ERROR: copyto_test.TestCopyTo.copy_to_test
--
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/nose/case.py, line 197, in 
runTest
self.test(*self.arg)
  File /home/tahooie/datastax/cassandra-dtest/tools.py, line 132, in wrapped
f(obj)
  File /home/tahooie/datastax/cassandra-dtest/copyto_test.py, line 33, in 
copy_to_test
cursor_v2.execute(copy_from_cql)
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 117, in 
execute
response = self.handle_cql_execution_errors(doquery, prepared_q, compress)
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 134, in 
handle_cql_execution_errors
raise cql.ProgrammingError(Bad Request: %s % ire.why)
ProgrammingError: Bad Request: line 1:0 no viable alternative at input 'COPY'

--
Ran 1 test in 8.239s
{code}

Here is an example of the COPY TO command: 
{code}
COPY airplanes TO '/tmp/tmpOCdbFt';
{code}

This is the dtest used to produce the error:
{code}
import os
import tempfile

from dtest import Tester, debug
from tools import *

class TestCopyTo(Tester):

@since('1.1')
def copy_to_test(self):
self.num_rows = 0
cluster = self.cluster

cluster.populate(2).start()
time.sleep(1)
node1 = cluster.nodelist()[0]

cursor_v2 = self.cql_connection(node1).cursor()
self.create_ks(cursor_v2, 'ks', 2)
cursor_v2.execute(
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
)
cursor_v2.execute(INSERT INTO airplanes (name, manufacturer, year, 
mach) VALUES ('P38-Lightning', 'Lockheed', 1937, '.7'))

fn = tempfile.NamedTemporaryFile().name

copy_from_cql = COPY airplanes TO '%s' % fn
cursor_v2.execute(copy_from_cql)
{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-4592) CQL COPY TO command doesn't work with python cassandra-dbapi2

2012-08-30 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4592:


doh!

 CQL COPY TO command doesn't work with python cassandra-dbapi2
 -

 Key: CASSANDRA-4592
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4592
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu, dtest, ccm cluster, cassandra 1.1.4
Reporter: Tyler Patterson

 Running the COPY TO command produces the below error, though running the same 
 COPY TO command in cqlsh in the exact same cluster works fine:
 {code}
 ==
 ERROR: copyto_test.TestCopyTo.copy_to_test
 --
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/dist-packages/nose/case.py, line 197, in 
 runTest
 self.test(*self.arg)
   File /home/tahooie/datastax/cassandra-dtest/tools.py, line 132, in wrapped
 f(obj)
   File /home/tahooie/datastax/cassandra-dtest/copyto_test.py, line 33, in 
 copy_to_test
 cursor_v2.execute(copy_from_cql)
   File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 117, in 
 execute
 response = self.handle_cql_execution_errors(doquery, prepared_q, compress)
   File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 134, in 
 handle_cql_execution_errors
 raise cql.ProgrammingError(Bad Request: %s % ire.why)
 ProgrammingError: Bad Request: line 1:0 no viable alternative at input 'COPY'
 --
 Ran 1 test in 8.239s
 {code}
 Here is an example of the COPY TO command: 
 {code}
 COPY airplanes TO '/tmp/tmpOCdbFt';
 {code}
 This is the dtest used to produce the error:
 {code}
 import os
 import tempfile
 from dtest import Tester, debug
 from tools import *
 class TestCopyTo(Tester):
 
 @since('1.1')
 def copy_to_test(self):
 self.num_rows = 0
 cluster = self.cluster
 cluster.populate(2).start()
 time.sleep(1)
 node1 = cluster.nodelist()[0]
 cursor_v2 = self.cql_connection(node1).cursor()
 self.create_ks(cursor_v2, 'ks', 2)
 cursor_v2.execute(
 CREATE TABLE airplanes (
 name text PRIMARY KEY,
 manufacturer ascii,
 year int,
 mach float
 );
 )
 cursor_v2.execute(INSERT INTO airplanes (name, manufacturer, year, 
 mach) VALUES ('P38-Lightning', 'Lockheed', 1937, '.7'))
 fn = tempfile.NamedTemporaryFile().name
 copy_from_cql = COPY airplanes TO '%s' % fn
 cursor_v2.execute(copy_from_cql)
 {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] [Created] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns

2012-08-30 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4594:
--

 Summary: COPY TO and COPY FROM don't default to consistent 
ordering of columns
 Key: CASSANDRA-4594
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
 Project: Cassandra
  Issue Type: Bug
 Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: Brandon Williams
Priority: Minor


Here is the input:
{code} 
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND 
strategy_options:replication_factor = 1;
USE test;   

CREATE TABLE airplanes (
name text PRIMARY KEY,  
manufacturer ascii, 
year int,   
mach float  
);  

INSERT INTO airplanes (name, manufacturer, year, mach) VALUES ('P38-Lightning', 
'Lockheed', 1937, '.7');

COPY airplanes TO 'temp.cfg' WITH HEADER=true;  

TRUNCATE airplanes; 
   

   
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;

   
SELECT * FROM airplanes;
{code}

Here is what happens when executed. Note how it tried to import the float into 
the int column:
{code}
cqlsh:test DROP KEYSPACE test; 
   
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND 
strategy_options:replication_factor = 1;
cqlsh:test USE test;   

cqlsh:test 
   
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,  
... manufacturer ascii, 
... year int,   
... mach float  
... );  
cqlsh:test 
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES 
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test 
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;  
1 rows exported in 0.003 seconds.   
cqlsh:test TRUNCATE airplanes; 
cqlsh:test 
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'  
Aborting import at record #0 (line 1). Previously-inserted values still present.
0 rows imported in 0.002 seconds.
{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-4567) Error in log related to Murmer3Partitioner

2012-08-23 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4567:


Would it be feasible to provide a more helpful error message for people that 
didn't read NEWS.txt?

 Error in log related to Murmer3Partitioner
 --

 Key: CASSANDRA-4567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
 Environment: Using ccm on ubuntu
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.2.0


 Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to 
 trunk, start it back up. The following error shows up in the log:
 {code}
 ...
  INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling 
 row cache save to each 0 seconds (going to save all keys).
  INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line 
 164) Opening 
 /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
  (148 bytes)
  INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line 
 164) Opening 
 /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
  (226 bytes)
  INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line 
 164) Opening 
 /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
  (89 bytes)
 ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line 
 131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
 java.lang.RuntimeException: Cannot open 
 /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
  because partitioner does not match 
 org.apache.cassandra.dht.Murmur3Partitioner
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
 at 
 org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 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)
 ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line 
 131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
 java.lang.RuntimeException: Cannot open 
 /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
  because partitioner does not match 
 org.apache.cassandra.dht.Murmur3Partitioner
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
 at 
 org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 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)
 ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line 
 131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
 java.lang.RuntimeException: Cannot open 
 /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
  because partitioner does not match 
 org.apache.cassandra.dht.Murmur3Partitioner
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
 at 
 org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 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)
  INFO [main] 2012-08-22

[jira] [Created] (CASSANDRA-4567) Error in log related to Murmer3Partitioner

2012-08-22 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4567:
--

 Summary: Error in log related to Murmer3Partitioner
 Key: CASSANDRA-4567
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
 Project: Cassandra
  Issue Type: Bug
 Environment: Using ccm on ubuntu
Reporter: Tyler Patterson


Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to 
trunk, start it back up. The following error shows up in the log:
{code}
...
 INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling 
row cache save to each 0 seconds (going to save all keys).
 INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line 
164) Opening 
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2 
(148 bytes)
 INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line 
164) Opening 
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1 
(226 bytes)
 INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line 
164) Opening 
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3 
(89 bytes)
ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line 
131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
java.lang.RuntimeException: Cannot open 
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3 
because partitioner does not match org.apache.cassandra.dht.Murmur3Partitioner
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at 
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)
ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line 
131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
java.lang.RuntimeException: Cannot open 
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1 
because partitioner does not match org.apache.cassandra.dht.Murmur3Partitioner
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at 
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)
ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line 
131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
java.lang.RuntimeException: Cannot open 
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2 
because partitioner does not match org.apache.cassandra.dht.Murmur3Partitioner
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at 
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)
 INFO [main] 2012-08-22 10:44:40,486 DatabaseDescriptor.java (line 522) 
Couldn't detect any schema definitions in local storage.
 INFO [main] 2012-08-22 10:44:40,487 DatabaseDescriptor.java (line 525) Found 
table data in data directories. Consider using the CLI to define your schema.
...
{code}

Note that the error does not happen when upgrading from cassandra-1.0 to 
cassandra-1.1, or when upgrading from trunk to trunk.

This is the exact dtest I used:
{code}
from dtest import Tester, debug

FROM_VERSION = 'git:cassandra-1.1'
TO_VERSION =

[jira] [Commented] (CASSANDRA-3560) incorrect description for nodetool scrub/upgradesstables and invalidaterow/keycache

2012-06-29 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-3560:


the line for invalidaterowcache says Invalidate the key..., should be 
Invalidate the row...

The line for upgradesstables is an exact copy of the line for scrub. It seems 
like it could point out why one would use it, maybe something like this: 
Updates sstables from a previous cassandra version

 incorrect description for nodetool scrub/upgradesstables and 
 invalidaterow/keycache
 ---

 Key: CASSANDRA-3560
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3560
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.5
Reporter: Ramesh Natarajan
Priority: Trivial

 Description for the following commands needs to be corrected
   scrub [keyspace] [cfnames] - Scrub (rebuild sstables for) one or more 
 column family
   upgradesstables [keyspace] [cfnames] - Scrub (rebuild sstables for) one or 
 more column family
   invalidatekeycache [keyspace] [cfnames] - Invalidate the key cache of one 
 or more column family
   invalidaterowcache [keyspace] [cfnames] - Invalidate the key cache of one 
 or more column family

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3560) incorrect description for nodetool scrub/upgradesstables and invalidaterow/keycache

2012-06-29 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-3560:
---

Comment: was deleted

(was: the line for invalidaterowcache says Invalidate the key..., should be 
Invalidate the row...

The line for upgradesstables is an exact copy of the line for scrub. It seems 
like it could point out why one would use it, maybe something like this: 
Updates sstables from a previous cassandra version)

 incorrect description for nodetool scrub/upgradesstables and 
 invalidaterow/keycache
 ---

 Key: CASSANDRA-3560
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3560
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.0.5
Reporter: Ramesh Natarajan
Priority: Trivial

 Description for the following commands needs to be corrected
   scrub [keyspace] [cfnames] - Scrub (rebuild sstables for) one or more 
 column family
   upgradesstables [keyspace] [cfnames] - Scrub (rebuild sstables for) one or 
 more column family
   invalidatekeycache [keyspace] [cfnames] - Invalidate the key cache of one 
 or more column family
   invalidaterowcache [keyspace] [cfnames] - Invalidate the key cache of one 
 or more column family

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4333) cqlsh: cannot USE keyspace with uppercase characters

2012-06-12 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4333:
--

 Summary: cqlsh: cannot USE keyspace with uppercase characters
 Key: CASSANDRA-4333
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4333
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu, git:cassandra-1.1
Reporter: Tyler Patterson
Assignee: paul cannon


create a keyspace with an uppercase character in cqlsh2. Go to cqlsh3 and try 
to USE the keyspace. An error says the keyspace does not exist.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4334) cqlsh tab completion error in CREATE KEYSPACE

2012-06-12 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4334:
--

 Summary: cqlsh tab completion error in CREATE KEYSPACE
 Key: CASSANDRA-4334
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4334
 Project: Cassandra
  Issue Type: Bug
 Environment: ubuntu, git:cassandra-1.1. I see the error in cqlsh with 
cql2 and cql3.
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor


The following:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'STAB
{code}
will tab complete like this:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy '
{code}
Note the extra space after SimpleStrategy. Not a big deal to remove, but it 
could be misleading to people.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4298) Exception in system.test_thrift_server.TestMut.test_bad_call

2012-05-30 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4298:
--

 Summary: Exception in 
system.test_thrift_server.TestMut.test_bad_call
 Key: CASSANDRA-4298
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4298
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cassandra-1.1, ubuntu
Reporter: Tyler Patterson


Running it like this (cassandra-1.1, ubuntu)

{code}
PYTHONPATH=test nosetests -vx --nocapture --process-timeout=20 
--tests=system.test_thrift_server:TestMutations.test_bad_calls
{code}

I get this error:
{code}
==
ERROR: system.test_thrift_server.TestMutations.test_bad_calls
--
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/nose/case.py, line 197, in 
runTest
self.test(*self.arg)
  File /home/tahooie/datastax/cassandra/test/system/test_thrift_server.py, 
line 685, in test_bad_calls
_expect_exception(lambda: client.insert(None, None, None, None), 
TApplicationException)
  File /home/tahooie/datastax/cassandra/test/system/test_thrift_server.py, 
line 207, in _expect_exception
r = fn()
  File /home/tahooie/datastax/cassandra/test/system/test_thrift_server.py, 
line 685, in lambda
_expect_exception(lambda: client.insert(None, None, None, None), 
TApplicationException)
  File 
/home/tahooie/datastax/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py,
 line 832, in insert
self.recv_insert()
  File 
/home/tahooie/datastax/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py,
 line 848, in recv_insert
x = TApplicationException()
NameError: global name 'TApplicationException' is not defined

--

{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4298) Exception in system.test_thrift_server.TestMut.test_bad_call

2012-05-30 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4298:


I didn't initially use the ant command, but I did compile the thrift bindings. 
Tried it again with ant command and got the same error.

 Exception in system.test_thrift_server.TestMut.test_bad_call
 

 Key: CASSANDRA-4298
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4298
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cassandra-1.1, ubuntu
Reporter: Tyler Patterson

 Running it like this (cassandra-1.1, ubuntu)
 {code}
 PYTHONPATH=test nosetests -vx --nocapture --process-timeout=20 
 --tests=system.test_thrift_server:TestMutations.test_bad_calls
 {code}
 I get this error:
 {code}
 ==
 ERROR: system.test_thrift_server.TestMutations.test_bad_calls
 --
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/dist-packages/nose/case.py, line 197, in 
 runTest
 self.test(*self.arg)
   File /home/tahooie/datastax/cassandra/test/system/test_thrift_server.py, 
 line 685, in test_bad_calls
 _expect_exception(lambda: client.insert(None, None, None, None), 
 TApplicationException)
   File /home/tahooie/datastax/cassandra/test/system/test_thrift_server.py, 
 line 207, in _expect_exception
 r = fn()
   File /home/tahooie/datastax/cassandra/test/system/test_thrift_server.py, 
 line 685, in lambda
 _expect_exception(lambda: client.insert(None, None, None, None), 
 TApplicationException)
   File 
 /home/tahooie/datastax/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py,
  line 832, in insert
 self.recv_insert()
   File 
 /home/tahooie/datastax/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py,
  line 848, in recv_insert
 x = TApplicationException()
 NameError: global name 'TApplicationException' is not defined
 --
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4270) long-test broken due to incorrect config option

2012-05-21 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4270:
--

 Summary: long-test broken due to incorrect config option
 Key: CASSANDRA-4270
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4270
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Tyler Patterson
Assignee: Tyler Patterson
Priority: Minor


the long-test fails:
{code}
BUILD FAILED
/home/tahooie/datastax/cassandra/build.xml:1125: Problem: failed to create task 
or type jvmarg
Cause: The name is undefined.
{code}
The problem is that the build.xml file has the jvmarg outside the testmacro 
tag instead of inside it. A patch is forthcoming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4270) long-test broken due to incorrect config option

2012-05-21 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4270:
---

Attachment: CASSANDRA-4270.patch

 long-test broken due to incorrect config option
 ---

 Key: CASSANDRA-4270
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4270
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Tyler Patterson
Assignee: Tyler Patterson
Priority: Minor
  Labels: test
 Attachments: CASSANDRA-4270.patch


 the long-test fails:
 {code}
 BUILD FAILED
 /home/tahooie/datastax/cassandra/build.xml:1125: Problem: failed to create 
 task or type jvmarg
 Cause: The name is undefined.
 {code}
 The problem is that the build.xml file has the jvmarg outside the testmacro 
 tag instead of inside it. A patch is forthcoming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-18 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4221:
---

Attachment: (was: system_log.zip)

 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221-logging.patch, CASSANDRA-4221.patch


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 Caused by: java.io.IOError: java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
   at

[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-18 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4221:
---

Attachment: system.log

So after some experimentation, the problem is only happening when log_level is 
set at info, NOT debug. Gotta love these ones! I modified the logging patch to 
do logging.info() rather then logging.debug(), and the problem still happens, 
so at least you can see those debug messages. I hope this is enough to go on.

 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221-logging.patch, CASSANDRA-4221.patch, 
 system.log


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 Caused by: java.io.IOError: java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at

[jira] [Comment Edited] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-18 Thread Tyler Patterson (JIRA)


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

Tyler Patterson edited comment on CASSANDRA-4221 at 5/18/12 4:53 PM:
-

So after some experimentation, the problem is only happening when the log level 
is set to INFO, but it doesn't happen at DEBUG. Gotta love these ones! I 
modified the logging patch to do logging.info() rather then logging.debug(), 
and the problem still happens, so at least you can see those debug messages. I 
hope this is enough to go on.

  was (Author: tpatterson):
So after some experimentation, the problem is only happening when log_level 
is set at info, NOT debug. Gotta love these ones! I modified the logging patch 
to do logging.info() rather then logging.debug(), and the problem still 
happens, so at least you can see those debug messages. I hope this is enough to 
go on.
  
 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221-logging.patch, CASSANDRA-4221.patch, 
 system.log


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at

[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-17 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4221:
---

Attachment: system.log

This was after applying both patches to the cassandra-1.1 branch, and setting 
logging to DEBUG.

 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221-logging.patch, CASSANDRA-4221.patch, 
 system.log


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 Caused by: java.io.IOError: java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
   at

[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-17 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4221:
---

Attachment: (was: system.log)

 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221-logging.patch, CASSANDRA-4221.patch


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 Caused by: java.io.IOError: java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
   at 
 org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:142)

[jira] [Commented] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-17 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4221:


Somehow that server.log did not have the debug info. Looking into it now.

 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221-logging.patch, CASSANDRA-4221.patch


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 Caused by: java.io.IOError: java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
   at

[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-17 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4221:
---

Attachment: system_log.zip

Debug is enabled now; It looks like CCM overwrites the log level. Only the 
logging patch was applied in this run. 

 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221-logging.patch, CASSANDRA-4221.patch, 
 system_log.zip


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 Caused by: java.io.IOError: java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
   at

[jira] [Commented] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-16 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4221:


Yes, the error just happened again for me. I did a fresh pull on branch branch 
cassandra-1.1.

 Error while deleting a columnfamily that is being compacted.
 

 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
 cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.1

 Attachments: CASSANDRA-4221.patch


 The following dtest command produces an error:
 {code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
 --nologcapture 
 concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
 Here is the error:
 {code}
 Error occured during compaction
 java.util.concurrent.ExecutionException: java.io.IOError: 
 java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
   at java.util.concurrent.FutureTask.get(FutureTask.java:111)
   at 
 org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
   at 
 org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 Caused by: java.io.IOError: java.io.FileNotFoundException: 
 /tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
  (No such file or directory)
   at 
 org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
   at 
 org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
   at

[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-08 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4221:
---

Description: 
The following dtest command produces an error:
{code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
--nologcapture 
concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}

Here is the error:
{code}
Error occured during compaction
java.util.concurrent.ExecutionException: java.io.IOError: 
java.io.FileNotFoundException: 
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
 (No such file or directory)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at 
org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
at 
org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
at 
org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
at 
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.io.IOError: java.io.FileNotFoundException: 
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
 (No such file or directory)
at 
org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
at 
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
at 
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
at 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:142)
at 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:148)
at 
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:121)
at 
org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:264)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
...

[jira] [Created] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.

2012-05-04 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4221:
--

 Summary: Error while deleting a columnfamily that is being 
compacted.
 Key: CASSANDRA-4221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: ccm, dtest, cassandra-1.1. The error does not happen in 
cassandra-1.0.
Reporter: Tyler Patterson


The following dtest command produces an error:
{code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture 
--nologcapture 
concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}

Here is the error:
{code}
Error occured during compaction
java.util.concurrent.ExecutionException: java.io.IOError: 
java.io.FileNotFoundException: 
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
 (No such file or directory)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at 
org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
at 
org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
at 
org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
at 
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.io.IOError: java.io.FileNotFoundException: 
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
 (No such file or directory)
at 
org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
at 
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
at 
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
at 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:142)
at 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:148)
at 
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:121)
at 
org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:264)
at

[jira] [Updated] (CASSANDRA-4188) stress tool return a non-zero value when it fails

2012-05-02 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4188:
---

Reviewer: xedin
Assignee: Tyler Patterson  (was: Pavel Yaskevich)

 stress tool return a non-zero value when it fails
 -

 Key: CASSANDRA-4188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Tyler Patterson
Assignee: Tyler Patterson
Priority: Minor
  Labels: stress
 Fix For: 1.0.10


 I'm using of stress in the dtests, and it would be great if I could tell 
 based on the return code if stress succeeded or failed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4188) stress tool return a non-zero value when it fails

2012-05-02 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4188:
---

Attachment: trunk-4188.txt

Consider it a failure if the producer or any of the consumers fail.

 stress tool return a non-zero value when it fails
 -

 Key: CASSANDRA-4188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Tyler Patterson
Assignee: Tyler Patterson
Priority: Minor
  Labels: stress
 Fix For: 1.0.10

 Attachments: trunk-4188.txt


 I'm using of stress in the dtests, and it would be great if I could tell 
 based on the return code if stress succeeded or failed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4207) Bad link in HowToContribute documentation page

2012-05-01 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4207:
--

 Summary: Bad link in HowToContribute documentation page
 Key: CASSANDRA-4207
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4207
 Project: Cassandra
  Issue Type: Bug
  Components: Documentation  website
Reporter: Tyler Patterson
Priority: Minor


item 2 in the Overview section 
http://wiki.apache.org/cassandra/HowToContribute has a link to a video that 
cannot be found: 
http://www.channels.com/episodes/show/11765800/Getting-to-know-the-Cassandra-Codebase
 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4207) Bad link in HowToContribute documentation page

2012-05-01 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4207:


cool. I updated the video link.

 Bad link in HowToContribute documentation page
 --

 Key: CASSANDRA-4207
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4207
 Project: Cassandra
  Issue Type: Bug
  Components: Documentation  website
Reporter: Tyler Patterson
Priority: Minor
  Labels: doc

 item 2 in the Overview section 
 http://wiki.apache.org/cassandra/HowToContribute has a link to a video that 
 cannot be found: 
 http://www.channels.com/episodes/show/11765800/Getting-to-know-the-Cassandra-Codebase
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4195) error in log when upgrading multi-node cluster to 1.1

2012-04-30 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4195:
--

 Summary: error in log when upgrading multi-node cluster to 1.1
 Key: CASSANDRA-4195
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4195
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest. Ubuntu
Reporter: Tyler Patterson


I upgraded a cluster from 1.0.9 to 1.1.0. The following message shows up in the 
logs for all but the first node.
{code}
ERROR [GossipStage:1] 2012-04-30 07:37:06,986 AbstractCassandraDaemon.java 
(line 139) Fatal exception in thread Thread[GossipStage:1,5,main]
java.lang.UnsupportedOperationException: Not a time-based UUID  
at java.util.UUID.timestamp(UUID.java:331)  
at 
org.apache.cassandra.service.MigrationManager.updateHighestKnown(MigrationManager.java:121)
at 
org.apache.cassandra.service.MigrationManager.rectify(MigrationManager.java:99)
at 
org.apache.cassandra.service.MigrationManager.onAlive(MigrationManager.java:83)
at org.apache.cassandra.gms.Gossiper.markAlive(Gossiper.java:806)   
at 
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:849)
at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:908)   
at 
org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:62)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
{code}

I used this dtest, which I will add to the repository:
{code}
from dtest import Tester, debug 
from tools import * 
 
class TestUpgradeTo1_1(Tester): 
 
def upgrade_test(self): 
self.num_rows = 0 
cluster = self.cluster 
 
# Forcing cluster version on purpose 
cluster.set_cassandra_dir(cassandra_version='1.0.9') 
 
cluster.populate(3).start() 
time.sleep(1) 
 
for node in cluster.nodelist(): 
node.flush() 
time.sleep(.5) 
node.stop(wait_other_notice=True) 
node.set_cassandra_dir(cassandra_version='1.1.0') 
node.start(wait_other_notice=True) 
time.sleep(.5)
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4195) error in log when upgrading multi-node cluster to 1.1

2012-04-30 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4195:
---

Description: 
I upgraded a cluster from 1.0.9 to 1.1.0. The following message shows up in the 
logs for all but the first node.
{code}
ERROR [GossipStage:1] 2012-04-30 07:37:06,986 AbstractCassandraDaemon.java 
(line 139) Fatal exception in thread Thread[GossipStage:1,5,main]
java.lang.UnsupportedOperationException: Not a time-based UUID  
at java.util.UUID.timestamp(UUID.java:331)  
at 
org.apache.cassandra.service.MigrationManager.updateHighestKnown(MigrationManager.java:121)
at 
org.apache.cassandra.service.MigrationManager.rectify(MigrationManager.java:99)
at 
org.apache.cassandra.service.MigrationManager.onAlive(MigrationManager.java:83)
at org.apache.cassandra.gms.Gossiper.markAlive(Gossiper.java:806)   
at 
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:849)
at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:908)   
at 
org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:62)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
{code}

this dtest demonstrates the issue. It was added to the cassandra-dtest 
repository as upgrade_to_11_test:
{code}
from dtest import Tester, debug 
from tools import * 
 
class TestUpgradeTo1_1(Tester): 
 
def upgrade_test(self): 
self.num_rows = 0 
cluster = self.cluster 
 
# Forcing cluster version on purpose 
cluster.set_cassandra_dir(cassandra_version='1.0.9') 
 
cluster.populate(3).start() 
time.sleep(1) 
 
for node in cluster.nodelist(): 
node.flush() 
time.sleep(.5) 
node.stop(wait_other_notice=True) 
node.set_cassandra_dir(cassandra_version='1.1.0') 
node.start(wait_other_notice=True) 
time.sleep(.5)
{code}

  was:
I upgraded a cluster from 1.0.9 to 1.1.0. The following message shows up in the 
logs for all but the first node.
{code}
ERROR [GossipStage:1] 2012-04-30 07:37:06,986 AbstractCassandraDaemon.java 
(line 139) Fatal exception in thread Thread[GossipStage:1,5,main]
java.lang.UnsupportedOperationException: Not a time-based UUID  
at java.util.UUID.timestamp(UUID.java:331)  
at 
org.apache.cassandra.service.MigrationManager.updateHighestKnown(MigrationManager.java:121)
at 
org.apache.cassandra.service.MigrationManager.rectify(MigrationManager.java:99)
at 
org.apache.cassandra.service.MigrationManager.onAlive(MigrationManager.java:83)
at org.apache.cassandra.gms.Gossiper.markAlive(Gossiper.java:806)   
at 
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:849)
at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:908)   
at 
org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:62)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
{code}

I used this dtest, which I will add to the repository:
{code}
from dtest import Tester, debug 
from tools import * 
 
class TestUpgradeTo1_1(Tester): 
 
def upgrade_test(self): 
self.num_rows = 0 
cluster = self.cluster 
 
# Forcing cluster version on purpose 
cluster.set_cassandra_dir(cassandra_version='1.0.9') 
 
cluster.populate(3).start() 
time.sleep(1) 
 
for node in cluster.nodelist(): 
node.flush() 
time.sleep(.5) 
node.stop(wait_other_notice=True) 
node.set_cassandra_dir(cassandra_version='1.1.0') 
node.start(wait_other_notice=True) 
time.sleep(.5)
{code}


 error in log when upgrading multi-node cluster to 1.1
 -

 Key: CASSANDRA-4195
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4195
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ccm, dtest. Ubuntu
Reporter: Tyler Patterson

 I upgraded a cluster from 1.0.9 to 1.1.0. The following message shows up in 
 the logs for all but the first node.
 {code}
 ERROR

[jira] [Created] (CASSANDRA-4188) stress tool return a non-zero value when it fails

2012-04-25 Thread Tyler Patterson (JIRA)

Tyler Patterson created CASSANDRA-4188:
--

 Summary: stress tool return a non-zero value when it fails
 Key: CASSANDRA-4188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Tyler Patterson
Priority: Minor


I'm scripting the use of stress in the dtests, and it would be great if I could 
tell based on the return code if it succeeded or failed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4188) stress tool return a non-zero value when it fails

2012-04-25 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-4188:
---

Description: I'm using of stress in the dtests, and it would be great if I 
could tell based on the return code if stress succeeded or failed.  (was: I'm 
scripting the use of stress in the dtests, and it would be great if I could 
tell based on the return code if it succeeded or failed.)

 stress tool return a non-zero value when it fails
 -

 Key: CASSANDRA-4188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Tyler Patterson
Priority: Minor
  Labels: stress

 I'm using of stress in the dtests, and it would be great if I could tell 
 based on the return code if stress succeeded or failed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4188) stress tool return a non-zero value when it fails

2012-04-25 Thread Tyler Patterson (JIRA)


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

Tyler Patterson commented on CASSANDRA-4188:


{quote}What is succeeded for stress? Is timing out once a failure? Or taking 
longer than X minutes?{quote}
I was thinking of capturing obvious failures, like when it hits the max number 
of retries. Pretty much any time that it used to hang indefinitely.

 stress tool return a non-zero value when it fails
 -

 Key: CASSANDRA-4188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4188
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Priority: Minor
  Labels: stress
 Fix For: 1.0.10


 I'm using of stress in the dtests, and it would be great if I could tell 
 based on the return code if stress succeeded or failed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3804) upgrade problems from 1.0 to trunk

2012-04-24 Thread Tyler Patterson (JIRA)


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

Tyler Patterson updated CASSANDRA-3804:
---

Description: 
A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only one 
node is taken down, upgraded to trunk, and started again. An rpc timeout 
exception happens if counter-add operations are done. It usually takes between 
1 and 500 add operations before the failure occurs. The failure seems to happen 
sooner if the coordinator node is NOT the one that was upgraded. Here is the 
error: 

{code}

==
ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
--
Traceback (most recent call last):
  File /usr/lib/pymodules/python2.7/nose/case.py, line 187, in runTest
self.test(*self.arg)
  File /home/tahooie/cassandra-dtest/counter_upgrade_test.py, line 50, in 
counter_upgrade_test
cursor.execute(UPDATE counters SET row = row+1 where key='a')
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 96, in 
execute
raise cql.OperationalError(Request did not complete within rpc_timeout.)
OperationalError: Request did not complete within rpc_timeout.

{code}



  was:
A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only one 
node is taken down, upgraded to trunk, and started again. An rpc timeout 
exception happens if counter-add operations are done. It usually takes between 
1 and 500 add operations before the failure occurs. The failure seems to happen 
sooner if the coordinator node is NOT the one that was upgraded. Here is the 
error: 

{code}

==
ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
--
Traceback (most recent call last):
  File /usr/lib/pymodules/python2.7/nose/case.py, line 187, in runTest
self.test(*self.arg)
  File /home/tahooie/cassandra-dtest/counter_upgrade_test.py, line 50, in 
counter_upgrade_test
cursor.execute(UPDATE counters SET row = row+1 where key='a')
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 96, in 
execute
raise cql.OperationalError(Request did not complete within rpc_timeout.)
OperationalError: Request did not complete within rpc_timeout.

{code}

A script has been added to cassandra-dtest (counter_upgrade_test.py) to 
demonstrate the failure. The newest version of CCM is required to run the test. 
It is available here if it hasn't yet been pulled: 
g...@github.com:tpatterson/ccm.git


I removed the dtest because it always fails, and will always fail in a properly 
running cluster.

 upgrade problems from 1.0 to trunk
 --

 Key: CASSANDRA-3804
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
 Environment: ubuntu, cluster set up with ccm.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
 Fix For: 1.1.0

 Attachments: CASSANDRA-3804-1.1-v2.patch, CASSANDRA-3804-1.1.patch, 
 CASSANDRA-3804.patch, node1.log, node2.log


 A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only 
 one node is taken down, upgraded to trunk, and started again. An rpc timeout 
 exception happens if counter-add operations are done. It usually takes 
 between 1 and 500 add operations before the failure occurs. The failure seems 
 to happen sooner if the coordinator node is NOT the one that was upgraded. 
 Here is the error: 
 {code}
 ==
 ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
 --
 Traceback (most recent call last):
   File /usr/lib/pymodules/python2.7/nose/case.py, line 187, in runTest
 self.test(*self.arg)
   File /home/tahooie/cassandra-dtest/counter_upgrade_test.py, line 50, in 
 counter_upgrade_test
 cursor.execute(UPDATE counters SET row = row+1 where key='a')
   File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 96, in 
 execute
 raise cql.OperationalError(Request did not complete within rpc_timeout.)
 OperationalError: Request did not complete within rpc_timeout.
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

57 matches

Mail list logo