[jira] [Commented] (CASSANDRA-9116) Indexes lost on upgrading to 2.1.4

2015-04-03 Thread Mark Dewey (JIRA) 

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

Mark Dewey commented on CASSANDRA-9116:
---

In tests against a three-node cluster, when two nodes are on 2.1.4 and one node 
is on 2.0.12, the following exception shows up in the system.log:
{noformat}
ERROR [Thread-18] 2015-04-03 16:02:04,366 CassandraDaemon.java (line 199) 
Exception in thread Thread[Thread-18,5,main]
java.lang.NullPointerException
at 
org.apache.cassandra.db.RangeSliceCommandSerializer.deserialize(RangeSliceCommand.java:247)
at 
org.apache.cassandra.db.RangeSliceCommandSerializer.deserialize(RangeSliceCommand.java:156)
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
at 
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:149)
at 
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:131)
at 
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:74)
{noformat}

 Indexes lost on upgrading to 2.1.4
 --

 Key: CASSANDRA-9116
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9116
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Mark Dewey
Assignee: Sam Tunnicliffe
Priority: Blocker
 Fix For: 2.1.5


 How to reproduce:
 # Create a 2.0.12 cluster
 # Create the following keyspace/table (or something similar, it's primarily 
 the indexes that matter to this case afaict)
 {noformat}
 CREATE KEYSPACE tshirts WITH replication = {'class': 
 'NetworkTopologyStrategy', 'datacenter1': '1'}  AND durable_writes = true;
 CREATE TABLE tshirts.tshirtorders (
 store text,
 order_time timestamp,
 order_number uuid,
 color text,
 qty int,
 size text,
 PRIMARY KEY (store, order_time, order_number)
 ) WITH CLUSTERING ORDER BY (order_time ASC, order_number ASC)
 AND bloom_filter_fp_chance = 0.01
 AND caching = '{keys:ALL, rows_per_partition:NONE}'
 AND comment = ''
 AND compaction = {'min_threshold': '4', 'class': 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
 'max_threshold': '32'}
 AND compression = {'sstable_compression': 
 'org.apache.cassandra.io.compress.LZ4Compressor'}
 AND dclocal_read_repair_chance = 0.1
 AND default_time_to_live = 0
 AND gc_grace_seconds = 864000
 AND max_index_interval = 2048
 AND memtable_flush_period_in_ms = 0
 AND min_index_interval = 128
 AND read_repair_chance = 0.0
 AND speculative_retry = '99.0PERCENTILE';
 CREATE INDEX color ON tshirts.tshirtorders (color);
 CREATE INDEX size ON tshirts.tshirtorders (size);
 {noformat}
 # Load it with data
 # Stop the node (one node cluster is enough to replicate)
 # Upgrade the node to 2.1.4
 # Start the node
 # Optional: Run nodetool upgradesstables
 # Run the following queries:
 {noformat}
 SELECT * FROM tshirts.tshirtorders WHERE store = 'store 65';
 SELECT store, color, qty, size FROM tshirts.tshirtorders WHERE store = 'store 
 65' AND color = 'red';
 {noformat}
 No rows containing will appear in the indexed table.
 Sample output:
 {noformat}
 cqlsh SELECT * FROM tshirts.tshirtorders WHERE store = 'store 65';
  store| order_time   | order_number | 
 color  | qty  | size
 --+--+--++--+--
  store 65 | 2000-01-03 18:20:20+ | 457e60e6-da39-11e4-add3-42010af08298 | 
red | 1295 |M
  store 65 | 2000-01-04 01:29:21+ | 45947304-da39-11e4-add3-42010af08298 | 
   grey | 2805 |M
  store 65 | 2000-01-04 19:55:51+ | 45d69220-da39-11e4-add3-42010af08298 | 
  brown | 3380 | XXXL
  store 65 | 2000-01-04 22:45:07+ | 45e16894-da39-11e4-add3-42010af08298 | 
 yellow | 7000 |  XXL
  store 65 | 2000-01-05 17:09:56+ | 46083bd6-da39-11e4-add3-42010af08298 | 
 purple | 2440 |S
  store 65 | 2000-01-05 19:16:48+ | 460cadd8-da39-11e4-add3-42010af08298 | 
  green | 5690 |L
  store 65 | 2000-01-06 00:26:06+ | 461ccdbc-da39-11e4-add3-42010af08298 | 
  brown | 9890 |P
  store 65 | 2000-01-06 11:35:11+ | 4633aa00-da39-11e4-add3-42010af08298 | 
  black | 9350 |P
  store 65 | 2000-01-07 06:07:20+ | 4658e0ea-da39-11e4-add3-42010af08298 | 
  black | 1300 |S
  store 65 | 2000-01-07 06:47:40+ | 465be93e-da39-11e4-add3-42010af08298 | 
 purple | 9630 |   XL
  store 65 | 2000-01-09 12:42:38+ | 46bafdd4-da39-11e4-add3-42010af08298 | 
 purple | 1470 |M
  store 65 | 2000-01-09 19:07:35+ | 46c43e08-da39-11e4-add3-42010af08298 | 
   pink | 6005 |S
  store 65 | 2000-01-10 04:47:56+ | 46d4b170-da39-11e4-add3-42010af08298 | 
red |  345 |   XL

[jira] [Created] (CASSANDRA-9116) Indexes lost on upgrading to 2.1.4

2015-04-03 Thread Mark Dewey (JIRA) 
Mark Dewey created CASSANDRA-9116:
-

 Summary: Indexes lost on upgrading to 2.1.4
 Key: CASSANDRA-9116
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9116
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Mark Dewey
Priority: Blocker
 Fix For: 2.1.5


How to reproduce:
# Create a 2.0.12 cluster
# Create the following keyspace/table (or something similar, it's primarily the 
indexes that matter to this case afaict)
{noformat}
CREATE KEYSPACE tshirts WITH replication = {'class': 'NetworkTopologyStrategy', 
'datacenter1': '1'}  AND durable_writes = true;

CREATE TABLE tshirts.tshirtorders (
store text,
order_time timestamp,
order_number uuid,
color text,
qty int,
size text,
PRIMARY KEY (store, order_time, order_number)
) WITH CLUSTERING ORDER BY (order_time ASC, order_number ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = '{keys:ALL, rows_per_partition:NONE}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32'}
AND compression = {'sstable_compression': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
CREATE INDEX color ON tshirts.tshirtorders (color);
CREATE INDEX size ON tshirts.tshirtorders (size);
{noformat}
# Load it with data
# Stop the node (one node cluster is enough to replicate)
# Upgrade the node to 2.1.4
# Start the node
# Optional: Run nodetool upgradesstables
# Run the following queries:
{noformat}
SELECT * FROM tshirts.tshirtorders WHERE store = 'store 65';
SELECT store, color, qty, size FROM tshirts.tshirtorders WHERE store = 'store 
65' AND color = 'red';
{noformat}

No rows containing will appear in the indexed table.

Sample output:
{noformat}
cqlsh SELECT * FROM tshirts.tshirtorders WHERE store = 'store 65';

 store| order_time   | order_number | 
color  | qty  | size
--+--+--++--+--
 store 65 | 2000-01-03 18:20:20+ | 457e60e6-da39-11e4-add3-42010af08298 |   
 red | 1295 |M
 store 65 | 2000-01-04 01:29:21+ | 45947304-da39-11e4-add3-42010af08298 |   
grey | 2805 |M
 store 65 | 2000-01-04 19:55:51+ | 45d69220-da39-11e4-add3-42010af08298 |  
brown | 3380 | XXXL
 store 65 | 2000-01-04 22:45:07+ | 45e16894-da39-11e4-add3-42010af08298 | 
yellow | 7000 |  XXL
 store 65 | 2000-01-05 17:09:56+ | 46083bd6-da39-11e4-add3-42010af08298 | 
purple | 2440 |S
 store 65 | 2000-01-05 19:16:48+ | 460cadd8-da39-11e4-add3-42010af08298 |  
green | 5690 |L
 store 65 | 2000-01-06 00:26:06+ | 461ccdbc-da39-11e4-add3-42010af08298 |  
brown | 9890 |P
 store 65 | 2000-01-06 11:35:11+ | 4633aa00-da39-11e4-add3-42010af08298 |  
black | 9350 |P
 store 65 | 2000-01-07 06:07:20+ | 4658e0ea-da39-11e4-add3-42010af08298 |  
black | 1300 |S
 store 65 | 2000-01-07 06:47:40+ | 465be93e-da39-11e4-add3-42010af08298 | 
purple | 9630 |   XL
 store 65 | 2000-01-09 12:42:38+ | 46bafdd4-da39-11e4-add3-42010af08298 | 
purple | 1470 |M
 store 65 | 2000-01-09 19:07:35+ | 46c43e08-da39-11e4-add3-42010af08298 |   
pink | 6005 |S
 store 65 | 2000-01-10 04:47:56+ | 46d4b170-da39-11e4-add3-42010af08298 |   
 red |  345 |   XL
 store 65 | 2000-01-10 20:25:44+ | 46ef7d52-da39-11e4-add3-42010af08298 |   
pink |  420 |  XXL
 store 65 | 2000-01-11 00:55:27+ | 46f7a84c-da39-11e4-add3-42010af08298 | 
purple | 9045 |S
 store 65 | 2000-01-11 17:54:25+ | 4724ea00-da39-11e4-add3-42010af08298 |  
green | 5030 |  XXL
 store 65 | 2000-01-12 08:21:15+ | 473c0370-da39-11e4-add3-42010af08298 |  
white | 2860 |   XL
 store 65 | 2000-01-12 17:09:19+ | 47497d2a-da39-11e4-add3-42010af08298 |   
 red | 6425 |L
 store 65 | 2000-01-14 07:27:37+ | 478662a8-da39-11e4-add3-42010af08298 |   
pink |  330 | XXXL
 store 65 | 2000-01-14 11:31:38+ | 478b43cc-da39-11e4-add3-42010af08298 |   
pink | 3335 |  XXL
 store 65 | 2000-01-14 18:55:59+ | 47955a24-da39-11e4-add3-42010af08298 | 
yellow |  500 |P
 store 65 | 2000-01-15 01:59:52+ | 479f0c5e-da39-11e4-add3-42010af08298 |   
 red | 8415 |   XL
 store 65 | 2000-01-15 02:26:13+ | 47a00c08-da39-11e4-add3-42010af08298 |  
green | 2265 |P
 store 65 | 2000-01-15 14:31:50+ | 47b28c34-da39-11e4-add3-42010af08298 |  
green | 8165 |M
 store 65 | 2000-01-16 20:39:31+ | 47de6908-da39-11e4-add3-42010af08298 | 
purple | 1330 |  XXL
 store 65 | 2000-01-17

[jira] [Commented] (CASSANDRA-9116) Indexes lost on upgrading to 2.1.4

2015-04-03 Thread Mark Dewey (JIRA) 

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

Mark Dewey commented on CASSANDRA-9116:
---

Reach out to me to get the generator I used to fill data into the table if you 
need to use my exact tables.

 Indexes lost on upgrading to 2.1.4
 --

 Key: CASSANDRA-9116
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9116
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Mark Dewey
Priority: Blocker
 Fix For: 2.1.5


 How to reproduce:
 # Create a 2.0.12 cluster
 # Create the following keyspace/table (or something similar, it's primarily 
 the indexes that matter to this case afaict)
 {noformat}
 CREATE KEYSPACE tshirts WITH replication = {'class': 
 'NetworkTopologyStrategy', 'datacenter1': '1'}  AND durable_writes = true;
 CREATE TABLE tshirts.tshirtorders (
 store text,
 order_time timestamp,
 order_number uuid,
 color text,
 qty int,
 size text,
 PRIMARY KEY (store, order_time, order_number)
 ) WITH CLUSTERING ORDER BY (order_time ASC, order_number ASC)
 AND bloom_filter_fp_chance = 0.01
 AND caching = '{keys:ALL, rows_per_partition:NONE}'
 AND comment = ''
 AND compaction = {'min_threshold': '4', 'class': 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
 'max_threshold': '32'}
 AND compression = {'sstable_compression': 
 'org.apache.cassandra.io.compress.LZ4Compressor'}
 AND dclocal_read_repair_chance = 0.1
 AND default_time_to_live = 0
 AND gc_grace_seconds = 864000
 AND max_index_interval = 2048
 AND memtable_flush_period_in_ms = 0
 AND min_index_interval = 128
 AND read_repair_chance = 0.0
 AND speculative_retry = '99.0PERCENTILE';
 CREATE INDEX color ON tshirts.tshirtorders (color);
 CREATE INDEX size ON tshirts.tshirtorders (size);
 {noformat}
 # Load it with data
 # Stop the node (one node cluster is enough to replicate)
 # Upgrade the node to 2.1.4
 # Start the node
 # Optional: Run nodetool upgradesstables
 # Run the following queries:
 {noformat}
 SELECT * FROM tshirts.tshirtorders WHERE store = 'store 65';
 SELECT store, color, qty, size FROM tshirts.tshirtorders WHERE store = 'store 
 65' AND color = 'red';
 {noformat}
 No rows containing will appear in the indexed table.
 Sample output:
 {noformat}
 cqlsh SELECT * FROM tshirts.tshirtorders WHERE store = 'store 65';
  store| order_time   | order_number | 
 color  | qty  | size
 --+--+--++--+--
  store 65 | 2000-01-03 18:20:20+ | 457e60e6-da39-11e4-add3-42010af08298 | 
red | 1295 |M
  store 65 | 2000-01-04 01:29:21+ | 45947304-da39-11e4-add3-42010af08298 | 
   grey | 2805 |M
  store 65 | 2000-01-04 19:55:51+ | 45d69220-da39-11e4-add3-42010af08298 | 
  brown | 3380 | XXXL
  store 65 | 2000-01-04 22:45:07+ | 45e16894-da39-11e4-add3-42010af08298 | 
 yellow | 7000 |  XXL
  store 65 | 2000-01-05 17:09:56+ | 46083bd6-da39-11e4-add3-42010af08298 | 
 purple | 2440 |S
  store 65 | 2000-01-05 19:16:48+ | 460cadd8-da39-11e4-add3-42010af08298 | 
  green | 5690 |L
  store 65 | 2000-01-06 00:26:06+ | 461ccdbc-da39-11e4-add3-42010af08298 | 
  brown | 9890 |P
  store 65 | 2000-01-06 11:35:11+ | 4633aa00-da39-11e4-add3-42010af08298 | 
  black | 9350 |P
  store 65 | 2000-01-07 06:07:20+ | 4658e0ea-da39-11e4-add3-42010af08298 | 
  black | 1300 |S
  store 65 | 2000-01-07 06:47:40+ | 465be93e-da39-11e4-add3-42010af08298 | 
 purple | 9630 |   XL
  store 65 | 2000-01-09 12:42:38+ | 46bafdd4-da39-11e4-add3-42010af08298 | 
 purple | 1470 |M
  store 65 | 2000-01-09 19:07:35+ | 46c43e08-da39-11e4-add3-42010af08298 | 
   pink | 6005 |S
  store 65 | 2000-01-10 04:47:56+ | 46d4b170-da39-11e4-add3-42010af08298 | 
red |  345 |   XL
  store 65 | 2000-01-10 20:25:44+ | 46ef7d52-da39-11e4-add3-42010af08298 | 
   pink |  420 |  XXL
  store 65 | 2000-01-11 00:55:27+ | 46f7a84c-da39-11e4-add3-42010af08298 | 
 purple | 9045 |S
  store 65 | 2000-01-11 17:54:25+ | 4724ea00-da39-11e4-add3-42010af08298 | 
  green | 5030 |  XXL
  store 65 | 2000-01-12 08:21:15+ | 473c0370-da39-11e4-add3-42010af08298 | 
  white | 2860 |   XL
  store 65 | 2000-01-12 17:09:19+ | 47497d2a-da39-11e4-add3-42010af08298 | 
red | 6425 |L
  store 65 | 2000-01-14 07:27:37+ | 478662a8-da39-11e4-add3-42010af08298 | 
   pink |  330 | XXXL
  store 65 | 2000-01-14 11:31:38+ | 478b43cc-da39-11e4-add3-42010af08298 | 
   pink | 3335 |  XXL
  store 65 | 2000-01-14 18:55:59+ | 47955a24-da39-11e4-add3-42010af08298 | 
 yellow |  500 |P
  store 65 |

[jira] [Created] (CASSANDRA-6155) Big cluster upgrade test

2013-10-07 Thread Mark Dewey (JIRA) 
Mark Dewey created CASSANDRA-6155:
-

 Summary: Big cluster upgrade test
 Key: CASSANDRA-6155
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6155
 Project: Cassandra
  Issue Type: Test
  Components: Tests
Reporter: Mark Dewey


I am planning on writing a test that would:
 # Launch a 20 node cluster
 # Put 100 gigs of data on it using cassandra-stress
 # Perform a rolling upgrade of the cluster
 # Read the data using cassandra-stress



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (CASSANDRA-6155) Big cluster upgrade test

2013-10-07 Thread Mark Dewey (JIRA) 

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

Mark Dewey commented on CASSANDRA-6155:
---

[~jbellis], [~dmeyer] please chime in with any suggestions, like # of columns, 
width of columns, etc.

Is there interest in having this upgrade test happen while reads and/or writes 
are happening on the cluster?

 Big cluster upgrade test
 

 Key: CASSANDRA-6155
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6155
 Project: Cassandra
  Issue Type: Test
  Components: Tests
Reporter: Mark Dewey

 I am planning on writing a test that would:
  # Launch a 20 node cluster
  # Put 100 gigs of data on it using cassandra-stress
  # Perform a rolling upgrade of the cluster
  # Read the data using cassandra-stress



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (CASSANDRA-6155) Big cluster upgrade test

2013-10-07 Thread Mark Dewey (JIRA) 

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

Mark Dewey updated CASSANDRA-6155:
--

Description: 
I am planning on writing a test that would:
 # Launch a 20 node cluster
 # Put 100 gigs of data on it (per node) using cassandra-stress
 # Perform a rolling upgrade of the cluster
 # Read the data using cassandra-stress

  was:
I am planning on writing a test that would:
 # Launch a 20 node cluster
 # Put 100 gigs of data on it using cassandra-stress
 # Perform a rolling upgrade of the cluster
 # Read the data using cassandra-stress


 Big cluster upgrade test
 

 Key: CASSANDRA-6155
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6155
 Project: Cassandra
  Issue Type: Test
  Components: Tests
Reporter: Mark Dewey

 I am planning on writing a test that would:
  # Launch a 20 node cluster
  # Put 100 gigs of data on it (per node) using cassandra-stress
  # Perform a rolling upgrade of the cluster
  # Read the data using cassandra-stress



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (CASSANDRA-5192) cql2 batch mode ignores keyspace qualification

2013-01-28 Thread Mark Dewey (JIRA) 
Mark Dewey created CASSANDRA-5192:
-

 Summary: cql2 batch mode ignores keyspace qualification
 Key: CASSANDRA-5192
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5192
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.9
Reporter: Mark Dewey


How to reproduce: {noformat}
cqlsh
CREATE KEYSPACE demo WITH
strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = '1';
USE demo;
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password) VALUES ('jsmith', '000');

CREATE KEYSPACE demo2 WITH
strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = '1';
USE demo2;
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password) VALUES ('jsmith', '000');

use demo;
begin batch 
insert into demo.users (KEY, password) VALUES ('jsmith', '111') 
insert into demo2.users (KEY, password) VALUES ('jsmith', '222') 
apply batch;
select * from demo.users;
select * from demo2.users;
{noformat}

Error:
The entry in demo.users will be what we tried to set demo2.users to be. The 
entry in demo2.users will be its original value.

--
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