[jira] [Commented] (CASSANDRA-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686728#comment-13686728 ] Sylvain Lebresne commented on CASSANDRA-5149: - bq. In IDiskAtomFilter.collectReducedColumns() timestamp and gcbefore are sometimes unrelated Right, forgot about that. Last version lgtm, +1. A few optional minor nits for the commit: * In CounterColumn.reconcile (and CounterMutation and ... in fact), we don't support expiring columns in counter tables so it's ok to just use say Long.MIN_VALUE (which a comment why). * the comment inside DeletedColumn.isMarkedForDelete is obsolete (it's more confusing that helpful now :)). Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686732#comment-13686732 ] Aleksey Yeschenko commented on CASSANDRA-5149: -- Thanks! bq. In CounterColumn.reconcile (and CounterMutation and ... in fact), we don't support expiring columns in counter tables so it's ok to just use say Long.MIN_VALUE (which a comment why) I know. Same with Column.getString() - it's overloaded by ExpiringColumn anyway. I was debating with myself what to use - Long.MIN_VALUE, 0, or just System.currentTimeMillis() where it doesn't matter, and went with System.currentTimeMillis(). Will change to 0 with a comment in both places. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685616#comment-13685616 ] Aleksey Yeschenko commented on CASSANDRA-5149: -- Pushed the fourth commit to the same branch. - Removed Column.isMarkedForDelete/0 and most similar methods (including QueryFilter getXFilter helper methods) - RowIteratorFactory/System.currentTimeMillis() - done. - CFS.filterColumnFamily() was the only place where I could get rid of passing gcBefore explicitly - thanks for catching that. In IDiskAtomFilter.collectReducedColumns() timestamp and gcbefore are sometimes unrelated (with Integer.MIN_VALUE passed as gcBefore, intentionally). Same goes for CFS.collateOnDiskAtom(). Usually it's either because of either compaction or the row cache. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683332#comment-13683332 ] Sylvain Lebresne commented on CASSANDRA-5149: - The overall approach looks good to me, though: * I'd feel a bit better if we were just removing the isMarkedForDelete() (without arguments) call in Column, so that every caller knows he has to deal with it. It's otherwise hard to make sure we never call the no-argument version by accident. There's probably a few other places too (Row for instance) where I'd prefer avoiding having a shortcut calling System.currentTimeMillis(). * In RowIteratorFactory, I think it would make sense to use the filter timestamp rather than relying on System.currentTimeMillis() for gcBefore. * There is possibly a few places where a function takes 'gcBefore' and 'now', either directly (collectReducedColumns), or because they have a filter and gcBefore (CFS.filterColumnFamily()). Maybe we could drop the gcBefore and just rely on the timestamp. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679581#comment-13679581 ] Sylvain Lebresne commented on CASSANDRA-5149: - bq. But I'm afraid it's not enough I'm not sure I understand the case you are talking about. Whether or not ExpiringColumn.create() decides to return a deleted column or not, it still returns a column, so this should have no impact whatsoever on anything timestamp related. I.e. the code will treat an ExpiringColumn that is expired exactly as a deleted column, so it should always be safe to not transform an expired column to a DeletedColumn, even if it's only in parts of the code. But it could be I just don't understand your example. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679598#comment-13679598 ] Aleksey Yeschenko commented on CASSANDRA-5149: -- I wasn't clear enough. I'm talking about read request timestamps, not column timestamps. And I'm saying that to transfrom is not always correct, in the context of 5149. But *not to* transfrom is perfectly all right. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679642#comment-13679642 ] Sylvain Lebresne commented on CASSANDRA-5149: - I still don't see where the problem is. Can you illustrate with a concrete example what is the problem we can run into if we just have Expiring.create() that doesn't transform in the case of the row cache but do transform based on the read request timestamp in all other cases? Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679220#comment-13679220 ] Aleksey Yeschenko commented on CASSANDRA-5149: -- There is another method that is affected - ExpiringColumn.create() that returns either a DeletedColumn or an ExpiringColumn instance, called by ColumnSerializer.deserializeColumnBody(). Now, we already do pass expireBefore to it as a parameter (in a limited way) and it's not (was not) difficult to make it be derived from read requests' timestamp. Except in one case - row cache deserialization. The required modifications go beyond the need for Cache API change and I haven't found a good way to deal with it. Is there any change we actually will get rid of row cache in 2.0? Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679232#comment-13679232 ] Sylvain Lebresne commented on CASSANDRA-5149: - Can't we create a version of ExpiringColumn.create() that never transform a DeletedColumn to an ExpiringColumn and use that for cache deserialization (or say do that when expireBefore is negative and pass -1 for expireBefore in the row cache code). Because that behavior of ExpiringColumn.create() is really just an optimization. It would be ok to never transform expired columns to deleted ones from a correction point of view. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679259#comment-13679259 ] Aleksey Yeschenko commented on CASSANDRA-5149: -- bq. Can't we create a version of ExpiringColumn.create() that never transform a DeletedColumn to an ExpiringColumn and use that for cache deserialization (or say do that when expireBefore is negative and pass -1 for expireBefore in the row cache code). That is easy, actually, since you only have to special-case starting at SerializingCacheProvider.deserialize() method. But I'm afraid it's not enough. That is, special-casing it just for the row cache is not enough, must do the same for sstable deserialization (or remove the optimization entirely), or else a row serialized into the cache as a result of request (a) with timestamp Y might not be the right row for request (b) with timestamp X ( Y) coming out of order if a column expires between X and Y. Making ExpiringColumn.create() to never return DeletedColumn instances would be the easiest way to deal with it, but what would impact compaction (and repair), so I suggest making NO expring-deleted optimization the default behavior, and only enabling it for compaction (incl. validation compaction) (and SSTableExport), or, in other words, special-case it for SSTII only. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668222#comment-13668222 ] Sylvain Lebresne commented on CASSANDRA-5149: - Actually, now that I think about it, I think CASSANDRA-4415 is why I'd really rather have this in 2.0. Currently, because of this, when you page a slice query, you cannot trust a given page to return strictly results than you've asked only if paging is done, because you could have result expiring mid-request and thus you pretty much can never know if the paging is really done or if some columns expired on you. CASSANDRA-5099 solves this by waiting until basically a query return an empty page. However: # this is really correct. In theory, you could have *all* of the columns fetch by the current patch that have expired mid-request, while there's still some live columns that match what your are trying to page. Granted, with a large enough page size it's very unlikely but still. # this means you'll *always* do one more query (and that's StorageProxy level queries, it's not cheap than would be needed if this ticket was fixed. And while having paged get_count being slow don't really make me shed tears, it bugs me quite a bit more in the context of CASSANDRA-4415. # this complicate reasoning about the logic for CASSANDRA-4415 imo. It's much easier not to have to care about oh, what if a column expires mid-request, is that ok?. Besides, I don't think fixing this is very complicated in practice. All we need is ship a 'queryServerTimestamp' with the read commands, and carry that down to the Column.isMarkedForDelete() method so it uses that instead of System.currentTimeMillis(). This might end up being a few lines of code to pass this timestamp down as parameter, but it's pretty trivial changes. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13649842#comment-13649842 ] Jeremiah Jordan commented on CASSANDRA-5149: Does CASSANDRA-4415 make this a non-issue (as long as it deals with this)? To me, this might as well just be won't fix, and you have to make the extra query and see if you only get one column back. I guess there is an edge case where you could just get one column, and there really are more, but its been this way since 0.7, so meh. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.1 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13649852#comment-13649852 ] Sylvain Lebresne commented on CASSANDRA-5149: - bq. Does CASSANDRA-4415 make this a non-issue I don't know. I think we'll only ever going to return less than asked columns if there is less than asked columns seems a reasonably semantic to have, and we fail that here with TTL. And even if CASSANDRA-4415 ends up hiding the problem, it's still a performance issue, because if you can't rely on the semantic above, you'll almost always have to do one more query than would be enough just to be sure (which is what getCount() does for thrift today). So, without saying this is a big or pressing issue, I'm -1 on wont fixing it in the long run. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.1 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587006#comment-13587006 ] Sylvain Lebresne commented on CASSANDRA-5149: - bq. I have trouble coming up with a use case for it. You mean, for querying the expiration time of a column? My own experience with TTL leads me to believe that anyone using expiring columns will want to query the expiration time at one point or another. I personally had a case where if some TTLed columns were read, we were extending the TTL and how long it was extended depended on the current expiration time. Or, on the other end of the spectrum, wanting to update a column value without extending the TTL. I had also a number of case where not all columns had the same TTL, if any, and just knowing if the column was an expiring one was necessary (including but not limited to checking during development that the code was doing what it was supposed to do in terms of setting TTLs). Also, if we were to transform expiring column to standard column on read, even ignoring the fact that we wouldn't be able to return the expiration time to clients, you'd have to be careful about read-repair cancelling your TTLs. Besides, as said above, especially if it's fix-for 2.0 (and so things like this may require a protocol change become largely irrelevant), I think normalizing all code on having expiration be based on a time fixed at well know places (like we do for gcBefore really) is the right long term solution. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13585937#comment-13585937 ] Sylvain Lebresne commented on CASSANDRA-5149: - Actually, this is not as free of a lunch as it sound. We cannot really force non-expired ExpiringColumn to Column, because we need to return the expiring time to the client. So in practice, we would need to either add a dontExpire flag for ExpiringColumn or a special Column+TTL column type for just that purpose. Any of those will have impact on the inter-node protocol (and at the column serialization, where we don't yet handle versions well (because we never really had to)). And if that's not significantly simpler, I think I prefer the expireBefore solution because that feels less hacky to me in that it fixes the issue of having column expire at uncontrolled times more generally (this is also how we deal with it in LazilyCompactedRow). Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586148#comment-13586148 ] Jonathan Ellis commented on CASSANDRA-5149: --- If it's fix-for 2.0, can we just omit returning expiration time? Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586181#comment-13586181 ] Sylvain Lebresne commented on CASSANDRA-5149: - I don't understand. Why would not returning the expiration time be more ok for 2.0 than 1.2? That is, even in CQL3 it's possible to query the expiration time of a column. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586229#comment-13586229 ] Jonathan Ellis commented on CASSANDRA-5149: --- I have trouble coming up with a use case for it. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13577457#comment-13577457 ] Sylvain Lebresne commented on CASSANDRA-5149: - That's a good idea, I think that would work (at least I don't see why it wouldn't right away). Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13576892#comment-13576892 ] Jonathan Ellis commented on CASSANDRA-5149: --- What if we forced ExpiringColumn to either Column or DeletedColumn on the reply? Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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-5149) Respect slice count even if column expire mid-request
[ https://issues.apache.org/jira/browse/CASSANDRA-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551181#comment-13551181 ] Sylvain Lebresne commented on CASSANDRA-5149: - As said on CASSANDRA-5099, the only good way to fix this that I can see right now would be to have the coordinator determine an expireBefore value (the current time at the beginning of the request) and use that exclusively during the query to decide whether a query is expired or not (similar to what we do for LazilyCompactedRow but at the scale of the query). Unfortunately, this means shipping that expireBefore value to replicas with the query and that implies a inter-node protocol change, which make this only viable for 2.0 now. Hence the 'fix version'. Of course if we can find a solution that don't require protocol change, then great. Respect slice count even if column expire mid-request - Key: CASSANDRA-5149 URL: https://issues.apache.org/jira/browse/CASSANDRA-5149 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Fix For: 2.0 This is a follow-up of CASSANDRA-5099. If a column expire just while a slice query is performed, it is possible for replicas to count said column as live but to have the coordinator seeing it as dead when building the final result. The effect that the query might return strictly less columns that the requested slice count even though there is some live columns matching the slice predicate but not returned in the result. -- 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
