[jira] [Commented] (CASSANDRA-5762) Lost row marker after TTL expires

2014-01-15 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-5762:
-

Actually, CASSANDRA-6588 is probably a better idea than my "disable ttl option" 
above.

> Lost row marker after TTL expires
> -
>
> Key: CASSANDRA-5762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5762
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: Ubuntu 12.04
>Reporter: Taner Catakli
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: 0001-Always-do-slice-queries-for-CQL3-tables.txt
>
>
> I have the following table
> cqlsh:loginproject> DESCRIBE TABLE gameservers;
>  
> CREATE TABLE gameservers (
>   address inet PRIMARY KEY,
>   last_update timestamp,
>   regions blob,
>   server_status boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'SnappyCompressor'};
> after inserting a row and executing the following command:
> UPDATE gameservers USING TTL 10 SET server_status = true WHERE address = 
> '192.168.0.100'
> after waiting for the ttl to expire, the row will lose its rowmarker making 
> "select address from gameservers" returning 0 results although there are some.
> in cassandra-cli the table looks like this:
> [default@loginproject] list gameservers;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 192.168.0.100
> => (name=last_update, value=0017, timestamp=1373884433543000)
> => (name=regions, value=, timestamp=1373883701652000)
> 1 Row Returned.
> Elapsed time: 345 msec(s).
> [default@loginproject]



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (CASSANDRA-5762) Lost row marker after TTL expires

2014-01-11 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-5762:
-

bq. Could we keep a "something in here has a TTL" flag and do the optimized way 
unless it is set?

I don't see how we could maintain such flag. We'd need to know no TTL is 
involved whatsoever at the coordinator level (so before we're reached the 
replicas), which I don't think is possible to do reliably. What we could 
probably do is add a per-table "disable ttl" option that would make inserts 
with TTL rejected. And we could optimize when this option is set. That being 
said, if you want to store both small and large values in the same row and 
strongly rely on only being able to query only the small ones often, you might 
be better off using 2 tables, one for the small values, one for the large ones.

> Lost row marker after TTL expires
> -
>
> Key: CASSANDRA-5762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5762
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: Ubuntu 12.04
>Reporter: Taner Catakli
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: 0001-Always-do-slice-queries-for-CQL3-tables.txt
>
>
> I have the following table
> cqlsh:loginproject> DESCRIBE TABLE gameservers;
>  
> CREATE TABLE gameservers (
>   address inet PRIMARY KEY,
>   last_update timestamp,
>   regions blob,
>   server_status boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'SnappyCompressor'};
> after inserting a row and executing the following command:
> UPDATE gameservers USING TTL 10 SET server_status = true WHERE address = 
> '192.168.0.100'
> after waiting for the ttl to expire, the row will lose its rowmarker making 
> "select address from gameservers" returning 0 results although there are some.
> in cassandra-cli the table looks like this:
> [default@loginproject] list gameservers;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 192.168.0.100
> => (name=last_update, value=0017, timestamp=1373884433543000)
> => (name=regions, value=, timestamp=1373883701652000)
> 1 Row Returned.
> Elapsed time: 345 msec(s).
> [default@loginproject]



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (CASSANDRA-5762) Lost row marker after TTL expires

2014-01-10 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan commented on CASSANDRA-5762:


Could we keep a "something in here has a TTL" flag and do the optimized way 
unless it is set?  I think we even already keep that kind of data to do the 
sstable tombstone compaction?  That way if you don't use TTL's, and you have 
big columns, you don't get the heap penalty (CASSANDRA-6569).

> Lost row marker after TTL expires
> -
>
> Key: CASSANDRA-5762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5762
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: Ubuntu 12.04
>Reporter: Taner Catakli
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: 0001-Always-do-slice-queries-for-CQL3-tables.txt
>
>
> I have the following table
> cqlsh:loginproject> DESCRIBE TABLE gameservers;
>  
> CREATE TABLE gameservers (
>   address inet PRIMARY KEY,
>   last_update timestamp,
>   regions blob,
>   server_status boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'SnappyCompressor'};
> after inserting a row and executing the following command:
> UPDATE gameservers USING TTL 10 SET server_status = true WHERE address = 
> '192.168.0.100'
> after waiting for the ttl to expire, the row will lose its rowmarker making 
> "select address from gameservers" returning 0 results although there are some.
> in cassandra-cli the table looks like this:
> [default@loginproject] list gameservers;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 192.168.0.100
> => (name=last_update, value=0017, timestamp=1373884433543000)
> => (name=regions, value=, timestamp=1373883701652000)
> 1 Row Returned.
> Elapsed time: 345 msec(s).
> [default@loginproject]



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (CASSANDRA-5762) Lost row marker after TTL expires

2013-07-18 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-5762:
--

+1

> Lost row marker after TTL expires
> -
>
> Key: CASSANDRA-5762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5762
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: Ubuntu 12.04
>Reporter: Taner Catakli
>Assignee: Sylvain Lebresne
>Priority: Critical
> Attachments: 0001-Always-do-slice-queries-for-CQL3-tables.txt
>
>
> I have the following table
> cqlsh:loginproject> DESCRIBE TABLE gameservers;
>  
> CREATE TABLE gameservers (
>   address inet PRIMARY KEY,
>   last_update timestamp,
>   regions blob,
>   server_status boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'SnappyCompressor'};
> after inserting a row and executing the following command:
> UPDATE gameservers USING TTL 10 SET server_status = true WHERE address = 
> '192.168.0.100'
> after waiting for the ttl to expire, the row will lose its rowmarker making 
> "select address from gameservers" returning 0 results although there are some.
> in cassandra-cli the table looks like this:
> [default@loginproject] list gameservers;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 192.168.0.100
> => (name=last_update, value=0017, timestamp=1373884433543000)
> => (name=regions, value=, timestamp=1373883701652000)
> 1 Row Returned.
> Elapsed time: 345 msec(s).
> [default@loginproject]

--
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-5762) Lost row marker after TTL expires

2013-07-15 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-5762:
-

This is a rather annoying problem. To sum it up, if you TTL one column, the row 
marker is ttled too, because we have no way to know that this is not the last 
live column in that CQL3 row, but then if there was other non-ttled columns, 
they will survive the death of the row marker which breaks the invariant that a 
live row always has a row marker.

Tbh, I have a hard time coming with a way to fix this. And so the only 
workaround that comes to mind would be disallow setting a TTL on an individual 
columns. That is, you'd have to update all columns of the row to be able to use 
a TTL, which I hate because 1) it'll look random syntax wise and 2) I'm 
convinced that being able to TTL individual columns in a row is useful.

> Lost row marker after TTL expires
> -
>
> Key: CASSANDRA-5762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5762
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.2.6
> Environment: Ubuntu 12.04
>Reporter: Taner Catakli
>Assignee: Sylvain Lebresne
>Priority: Critical
>
> I have the following table
> cqlsh:loginproject> DESCRIBE TABLE gameservers;
>  
> CREATE TABLE gameservers (
>   address inet PRIMARY KEY,
>   last_update timestamp,
>   regions blob,
>   server_status boolean
> ) WITH
>   bloom_filter_fp_chance=0.01 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'SnappyCompressor'};
> after inserting a row and executing the following command:
> UPDATE gameservers USING TTL 10 SET server_status = true WHERE address = 
> '192.168.0.100'
> after waiting for the ttl to expire, the row will lose its rowmarker making 
> "select address from gameservers" returning 0 results although there are some.
> in cassandra-cli the table looks like this:
> [default@loginproject] list gameservers;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 192.168.0.100
> => (name=last_update, value=0017, timestamp=1373884433543000)
> => (name=regions, value=, timestamp=1373883701652000)
> 1 Row Returned.
> Elapsed time: 345 msec(s).
> [default@loginproject]

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