[jira] [Commented] (CASSANDRA-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278616#comment-13278616
]
Kirk True commented on CASSANDRA-3974:
--
In my test case, it does go through {{RowIteratorFactory}}, but it *doesn't* go
through line 111. In {{getReduced}} {{cached}} is always {{null}} so it calls
the {{filter.collateColumns}} path.
So I made this naive change:
{noformat}
if (cached == null)
{
// not cached: collate
filter.collateColumns(returnCF, colIters, gcBefore);
returnCF = ColumnFamilyStore.removeDeleted(returnCF, gcBefore);
}
else
{
QueryFilter keyFilter = new QueryFilter(key, filter.path, filter.filter);
returnCF = cfs.filterColumnFamily(cached, keyFilter, gcBefore);
}
{noformat}
Be "manually" calling {{removeDeleted}} I was able to get my columns filtered
out as expected.
I'm pretty sure this is incomplete or just plain wrong, but I wanted to get
your thoughts.
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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-4256) Include stress tool in debian packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278536#comment-13278536 ] paul cannon commented on CASSANDRA-4256: +1. > Include stress tool in debian packaging > --- > > Key: CASSANDRA-4256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4256 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Assignee: Nick Bailey >Priority: Minor > Fix For: 1.1.1 > > Attachments: 0001-Include-stress-in-debian-package.patch > > > The stress tool isn't included in the debian packaging. We need to update > that to grab the stress shell script as well as put the stress.jar file in > lib. > Also the stress shell script needs to be updated to include looking in > /usr/share/cassandra... when searching for the stress jar so it will run in > packaged installations. -- 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-3636) cassandra 1.0.x breakes APT on debian OpenVZ
[
https://issues.apache.org/jira/browse/CASSANDRA-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-3636:
---
Attachment: 3636.patch.txt
This change should allow the deb install to succeed. Patrik, Tio, Zenek,
Saulius, or someone else with this problem, could you try applying the patch
and installing the deb?
Change also available on the 3636 branch on my github:
https://github.com/thepaul/cassandra/tree/3636
> cassandra 1.0.x breakes APT on debian OpenVZ
>
>
> Key: CASSANDRA-3636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 1.0.0
> Environment: Debian Linux (stable), OpenVZ container
>Reporter: Zenek Kraweznik
>Assignee: paul cannon
>Priority: Minor
> Fix For: 1.0.11, 1.1.1
>
> Attachments: 3636.patch.txt
>
>
> During upgrade from 1.0.6
> {code}Setting up cassandra (1.0.6) ...
> *error: permission denied on key 'vm.max_map_count'*
> dpkg: error processing cassandra (--configure):
> subprocess installed post-installation script returned error exit status 255
> Errors were encountered while processing:
> cassandra
> {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-4198) cqlsh: update recognized syntax for cql3
[ https://issues.apache.org/jira/browse/CASSANDRA-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4198: -- Reviewer: brandon.williams > cqlsh: update recognized syntax for cql3 > > > Key: CASSANDRA-4198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4198 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Affects Versions: 1.1.0 >Reporter: paul cannon >Assignee: paul cannon >Priority: Minor > Labels: cql3, cqlsh > Fix For: 1.1.1 > > Attachments: 4198.patch.txt > > > cqlsh should recognize cql3 syntax when in cql3 mode; this includes tab > completing proper syntax and properly quoting any terms in single- or > double-quotes (current version only knows how to use single quotes). > also, prefer using the term "TABLE" over "COLUMNFAMILY" wherever one of those > is generated from cqlsh (like in DESCRIBE output). > and if it's not too bad, it would help to have the online help strings > reflect cql3 syntax (maybe with a nod to cql2 restrictions where appropriate). -- 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] [Comment Edited] (CASSANDRA-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278489#comment-13278489
]
Jonathan Ellis edited comment on CASSANDRA-3974 at 5/18/12 1:43 AM:
RSVH still goes through removeDeleted. It can either go through the index
AbstractScanIterator which calls getCF at line 195 in KeysSearcher, or the seq
scan iterator via CFS.filterColumnFamily (RowIteratorFactory line 111).
Remember that these only remove *expired* tombstones; non-expired ones need to
be returned to the coordinator for read repair.
was (Author: jbellis):
RSVH still goes through getColumnFamily. It can either go through the
index AbstractScanIterator which calls getCF at line 195 in KeysSearcher, or
the seq scan iterator via CFS.filterColumnFamily (RowIteratorFactory line 111).
Remember that these only remove *expired* tombstones; non-expired ones need to
be returned to the coordinator for read repair.
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278489#comment-13278489
]
Jonathan Ellis commented on CASSANDRA-3974:
---
RSVH still goes through getColumnFamily. It can either go through the index
AbstractScanIterator which calls getCF at line 195 in KeysSearcher, or the seq
scan iterator via CFS.filterColumnFamily (RowIteratorFactory line 111).
Remember that these only remove *expired* tombstones; non-expired ones need to
be returned to the coordinator for read repair.
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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-4198) cqlsh: update recognized syntax for cql3
[ https://issues.apache.org/jira/browse/CASSANDRA-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4198: --- Attachment: 4198.patch.txt This fairly hefty patch does some refactoring in cqlsh to allow everything to use the right sort of quoting in the right places, and to handle parsing in both modes with good modular separation. Defines cql3 syntax so that it can be properly recognized and completed. It might be worth holding off on a review for just a bit until I can finish the test suite in CASSANDRA-3920, so that the reviewer doesn't need to take in all the changes at once. These changes are also split into much smaller, more individually understandable commits in the 4198 branch in my github: https://github.com/thepaul/cassandra/tree/4198 Current version tagged pending/4198. > cqlsh: update recognized syntax for cql3 > > > Key: CASSANDRA-4198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4198 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Affects Versions: 1.1.0 >Reporter: paul cannon >Assignee: paul cannon >Priority: Minor > Labels: cql3, cqlsh > Fix For: 1.1.1 > > Attachments: 4198.patch.txt > > > cqlsh should recognize cql3 syntax when in cql3 mode; this includes tab > completing proper syntax and properly quoting any terms in single- or > double-quotes (current version only knows how to use single quotes). > also, prefer using the term "TABLE" over "COLUMNFAMILY" wherever one of those > is generated from cqlsh (like in DESCRIBE output). > and if it's not too bad, it would help to have the online help strings > reflect cql3 syntax (maybe with a nod to cql2 restrictions where appropriate). -- 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-3687) Local range scans are not run on the read stage
[
https://issues.apache.org/jira/browse/CASSANDRA-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278463#comment-13278463
]
Vijay commented on CASSANDRA-3687:
--
+10, one thing which i noticed was will it be better to remove (coz the
localnode might not be in position 0).
{code}
if (handler.endpoints.size() == 1 &&
handler.endpoints.get(0).equals(FBUtilities.getBroadcastAddress())
{code}
and add it to
{code}
for (InetAddress endpoint : handler.endpoints)
{
if (endpoint.equals(FBUtilities.getBroadcastAddress())
{
logger.debug("reading data locally");
StageManager.getStage(Stage.READ).execute(new
LocalRangeSliceRunnable(nodeCmd, handler));
}
{code}
similar to fetchRows?
> Local range scans are not run on the read stage
> ---
>
> Key: CASSANDRA-3687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3687
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
>Priority: Minor
> Fix For: 1.2
>
>
> Running directly on the client request/StorageProxy thread means we're now
> allowing one range scan per thrift thread instead of one per read stage
> thread [which may be more, or less, depending on thrift server mode], and it
> bypasses the "drop hopeless requests" overcapacity protection built in there.
--
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-4201) Preserve commitlog size cap when recycling segments at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278449#comment-13278449
]
Vijay commented on CASSANDRA-4201:
--
+1
> Preserve commitlog size cap when recycling segments at startup
> --
>
> Key: CASSANDRA-4201
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4201
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: Windows 7 x64, 4Gb, JRE 1.6.0_31 (x86)
>Reporter: Pierre Chalamet
>Assignee: Jonathan Ellis
>Priority: Minor
> Labels: commitlog
> Fix For: 1.1.1
>
> Attachments: 4201.txt, cassandra.yaml, log.txt
>
>
> 1. Create a single node cluster, use default configuration, use cassandra.bat
> to start the server:
> 2. run the following commands in cli:
> {code}
> create keyspace toto;
> use toto;
> create column family titi;
> truncate titi;
> {code}
> 3. the node dies with this error:
> {code}
> ERROR 23:23:02,118 Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
> java.io.IOError: java.io.IOException: Map failed
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.(CommitLogSegment.java:127)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:202)
> at
> org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:159)
> at
> org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.io.IOException: Map failed
> at sun.nio.ch.FileChannelImpl.map(Unknown Source)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.(CommitLogSegment.java:119)
> ... 5 more
> Caused by: java.lang.OutOfMemoryError: Map failed
> at sun.nio.ch.FileChannelImpl.map0(Native Method)
> ... 7 more
> INFO 23:23:02,122 Stop listening to thrift clients
> INFO 23:23:02,123 Waiting for messaging service to quiesce
> INFO 23:23:02,125 MessagingService shutting down server thread.
> {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] [Comment Edited] (CASSANDRA-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278414#comment-13278414
]
Kirk True edited comment on CASSANDRA-3974 at 5/17/12 11:52 PM:
In my case (inserting data and then calling {{list my_cf}} from the CLI), it
goes through the {{RangeSliceCommand}} path which doesn't end up calling
{{ColumnFamilyStorage.getColumnFamily}}. As such, the
expired-and-thus-should-be-ignored columns are still showing up.
was (Author: kirktrue):
In my case (inserting data and then calling {{list my_cf}} from the CLI),
it goes through the {{RangeSliceCommand}} path which doesn't end up calling
{{ColumnFamilyStorage.getColumnFamily}}. As such, the
expired-and-thus-should-be-ignored rows are still showing up.
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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] [Comment Edited] (CASSANDRA-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278414#comment-13278414
]
Kirk True edited comment on CASSANDRA-3974 at 5/17/12 11:52 PM:
In my case (inserting data and then calling {{list my_cf}} from the CLI), it
goes through the {{RangeSliceCommand}} path which doesn't end up calling
{{ColumnFamilyStorage.getColumnFamily}}. As such, the
expired-and-thus-should-be-ignored rows are still showing up.
was (Author: kirktrue):
In my case (inserting data and then calling {{list my_cf}} from the CLI}}),
it goes through the {{RangeSliceCommand}} path which doesn't end up calling
{{ColumnFamilyStorage.getColumnFamily}}. As such, the
expired-and-thus-should-be-ignored rows are still showing up.
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278414#comment-13278414
]
Kirk True commented on CASSANDRA-3974:
--
In my case (inserting data and then calling {{list my_cf}} from the CLI}}), it
goes through the {{RangeSliceCommand}} path which doesn't end up calling
{{ColumnFamilyStorage.getColumnFamily}}. As such, the
expired-and-thus-should-be-ignored rows are still showing up.
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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-4252) Set operation mode to MOVING earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4252: -- Attachment: 4252.txt Patch attached. > Set operation mode to MOVING earlier > > > Key: CASSANDRA-4252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4252 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Priority: Minor > Attachments: 4252.txt > > > Right now when moving a node we set the OperationMode only once we've > calculated the necessary ranges to transfer and if there actually are ranges > to transfer. Due to the sleep for ring settling this means there are 30 > seconds where the node is moving but the operation mode isn't set > accordingly. Additionally if it turns out no data needs to be transferred > then the move will complete without ever switching the OperationMode to > moving. -- 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-4252) Set operation mode to MOVING earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278362#comment-13278362 ] Nick Bailey commented on CASSANDRA-4252: Ah you are right. I was under the impression we did the RING_DELAY sleep no matter what, but apparently not. Regarding the 'fetching new ranges...' log message, we can call setMode multiple times (a pattern we use for other modes). So we can just call setMode earlier on with a more accurate log message in addition to the later call. > Set operation mode to MOVING earlier > > > Key: CASSANDRA-4252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4252 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Priority: Minor > > Right now when moving a node we set the OperationMode only once we've > calculated the necessary ranges to transfer and if there actually are ranges > to transfer. Due to the sleep for ring settling this means there are 30 > seconds where the node is moving but the operation mode isn't set > accordingly. Additionally if it turns out no data needs to be transferred > then the move will complete without ever switching the OperationMode to > moving. -- 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-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278360#comment-13278360
]
Jonathan Ellis commented on CASSANDRA-3974:
---
CFS.removeDeleted is the one that's called during column reads. E.g.,
SliceByNamesReadCommand.getRow -> Table.getRow -> CFS.getColumnFamily ->
CFS.removeDeleted
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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-3497) BloomFilter FP ratio should be configurable or size-restricted some other way
[ https://issues.apache.org/jira/browse/CASSANDRA-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278356#comment-13278356 ] Brandon Williams commented on CASSANDRA-3497: - Note for others trying to disable their BF: despite earlier discussion on this ticket, zero is NOT disabled, but instead sets it back to the default, since 0 false positives is invalid. You actually want to set it to 1 to have the smallest possible filter. > BloomFilter FP ratio should be configurable or size-restricted some other way > - > > Key: CASSANDRA-3497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3497 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Yuki Morishita >Priority: Minor > Fix For: 1.0.7 > > Attachments: 0001-Add-bloom_filter_fp_chance-to-cli.patch, > 0001-give-default-val-to-fp_chance.patch, 3497-v3.txt, 3497-v4.txt, > CASSANDRA-1.0-3497.txt > > > When you have a live dc and purely analytical dc, in many situations you can > have less nodes on the analytical side, but end up getting restricted by > having the BloomFilters in-memory, even though you have absolutely no use for > them. It would be nice if you could reduce this memory requirement by tuning > the desired FP ratio, or even just disabling them altogether. -- 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-4252) Set operation mode to MOVING earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278357#comment-13278357 ] Jonathan Ellis commented on CASSANDRA-4252: --- bq. just nicer to set the mode immediately so that when a move is initiated the operation mode of the node changes immediately rather than waiting 30ish seconds Fair enough. bq. in the admittedly uncommon case of no data being transferred the operation mode gets set to moving at all I think it's inside that check to avoid logging "fetching new ranges and streaming old ranges" when there's nothing to stream, which is also misleading. Since we don't "push" modes I don't think there's any difference between not setting it at all, and setting it only to set back to NORMAL a nanosecond later. > Set operation mode to MOVING earlier > > > Key: CASSANDRA-4252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4252 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Priority: Minor > > Right now when moving a node we set the OperationMode only once we've > calculated the necessary ranges to transfer and if there actually are ranges > to transfer. Due to the sleep for ring settling this means there are 30 > seconds where the node is moving but the operation mode isn't set > accordingly. Additionally if it turns out no data needs to be transferred > then the move will complete without ever switching the OperationMode to > moving. -- 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-3974) Per-CF TTL
[
https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278344#comment-13278344
]
Kirk True commented on CASSANDRA-3974:
--
On IRC Jonathan suggested to look at {{ColumnFamilyStore.removeDeleted}} and
{{PrecompactedRow.removeDeletedAndOldShards}}. However, at doesn't _appear_
that either of these are called during column reads so I can't rely on those to
filter out results sent back to the client.
The logic that I see for filtering out results sent to the client is in places
such as {{CassandraServer.thriftifyColumns}} via the
{{IColumn.isMarkedForDelete}} call. However, as stated previously, since an
{{IColumn}} doesn't internally store a {{CFMetaData}} object, we'd have to pass
one in. {{isMarkedForDelete}} is used in a lot of places, so it has a ripple
effect that causes a lot of changes.
Please advise.
> Per-CF TTL
> --
>
> Key: CASSANDRA-3974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3974
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: Kirk True
>Priority: Minor
> Fix For: 1.2
>
> Attachments: trunk-3974.txt
>
>
> Per-CF TTL would allow compaction optimizations ("drop an entire sstable's
> worth of expired data") that we can't do with per-column.
--
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-4252) Set operation mode to MOVING earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278343#comment-13278343 ] Nick Bailey commented on CASSANDRA-4252: >From a monitoring application perspective its just nicer to set the mode >immediately so that when a move is initiated the operation mode of the node >changes immediately rather than waiting 30ish seconds. Also so in the >admittedly uncommon case of no data being transferred the operation mode gets >set to moving at all, which it currently won't. > Set operation mode to MOVING earlier > > > Key: CASSANDRA-4252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4252 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Priority: Minor > > Right now when moving a node we set the OperationMode only once we've > calculated the necessary ranges to transfer and if there actually are ranges > to transfer. Due to the sleep for ring settling this means there are 30 > seconds where the node is moving but the operation mode isn't set > accordingly. Additionally if it turns out no data needs to be transferred > then the move will complete without ever switching the OperationMode to > moving. -- 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-4252) Set operation mode to MOVING earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278320#comment-13278320 ] Jonathan Ellis commented on CASSANDRA-4252: --- What difference does it make as long as we set MOVING before streamRanges / requestRanges? > Set operation mode to MOVING earlier > > > Key: CASSANDRA-4252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4252 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Priority: Minor > > Right now when moving a node we set the OperationMode only once we've > calculated the necessary ranges to transfer and if there actually are ranges > to transfer. Due to the sleep for ring settling this means there are 30 > seconds where the node is moving but the operation mode isn't set > accordingly. Additionally if it turns out no data needs to be transferred > then the move will complete without ever switching the OperationMode to > moving. -- 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-3708) Support "composite prefix" tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278308#comment-13278308
]
Yuki Morishita commented on CASSANDRA-3708:
---
I checked out Sylvain's latest branch and overall it looked good to me. New on
disk format works fine with compaction and streaming, as well as RowMutations
among nodes.
One thing that doesn't work though is the following:
I created table as in dtest for 3708,
{code:sql}
CREATE TABLE test1 (
k int,
c1 int,
c2 int,
v1 int,
v2 int,
PRIMARY KEY (k, c1, c2)
);
{code}
and insert several rows.
Deleting using following statement works as expected in dtest:
{code:sql}
DELETE FROM test1 WHERE k = 0 AND c1 = 0;
{code}
But following delete statement doesn't work.
{code:sql}
DELETE FROM test1 WHERE k = 0 AND c1 = 0 AND c2 = 0;
{code}
Although specifying which columns to delete does work.
{code:sql}
DELETE v1, v2 FROM test1 WHERE k = 0 AND c1 = 0 AND c2 = 0;
{code}
>From the log, I did't see any DeletionInfo in RowMutation for the first (not
>working) statement.
{code}
DEBUG [Thrift:4] 2012-05-17 16:27:46,515 StorageProxy.java (line 174)
Mutations/ConsistencyLevel are [RowMutation(keyspace='Keyspace1',
key='', modifications=[ColumnFamily(test1 [])])]/ONE
{code}
I think this is just the matter of DeleteStatement. Other than that, LGTM.
> Support "composite prefix" tombstones
> -
>
> Key: CASSANDRA-3708
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3708
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 1.2
>
>
--
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-4255) concurrent modif ex when repair is run on LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4255:
--
Priority: Minor (was: Major)
Looks like this only affects getEstimatedTasks, not actually repair.
> concurrent modif ex when repair is run on LCS
> -
>
> Key: CASSANDRA-4255
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4255
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jackson Chung
>Assignee: Jonathan Ellis
>Priority: Minor
> Labels: compaction
> Fix For: 1.0.11, 1.1.1
>
> Attachments: 4255.txt
>
>
> came across this, will try to figure a way to systematically reprod this. But
> the problem is the sstable list in the manifest is changing as the repair is
> triggered:
> {panel}
> Exception in thread "main" java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
> at java.util.AbstractList$Itr.next(Unknown Source)
> at org.apache.cassandra.io.sstable.SSTable.getTotalBytes(SSTable.java:250)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.getEstimatedTasks(LeveledManifest.java:435)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getEstimatedRemainingTasks(LeveledCompactionStrategy.java:128)
> at
> org.apache.cassandra.db.compaction.CompactionManager.getPendingTasks(CompactionManager.java:1063)
> at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)
> at com.sun.jmx.mbeanserver.PerInterface.getAttribute(Unknown Source)
> at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(Unknown Source)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(Unknown
> Source)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown
> Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown
> Source)
> at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> at sun.rmi.transport.Transport$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {panel}
> maybe we could change the list to a copyOnArrayList? just a suggestion,
> haven't investigated much yet:
> {code:title=LeveledManifest.java}
> generations[i] = new ArrayList();
> {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-4221) Error while deleting a columnfamily that is being compacted.
[
https://issues.apache.org/jira/browse/CASSANDRA-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278219#comment-13278219
]
Pavel Yaskevich commented on CASSANDRA-4221:
I see debug information I added right now, but there is no IOError in that log
described in this task...
> 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.(SSTableScanner.java:61)
> at
> org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SS
[jira] [Comment Edited] (CASSANDRA-4233) overlapping sstables in leveled compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278204#comment-13278204 ] Jonathan Ellis edited comment on CASSANDRA-4233 at 5/17/12 8:22 PM: I think the status quo (and v1, which perpetuates it) are too fragile... Exhibit A being this bug, and exhibit B being my reading of the code leading me to believe that there was no way to disable LCS. Rather than try to prevent setting max inappropriately, much more clear to have LCS ignore min/max entirely, except via isCompactionDisabled. This is closer to how it "should" be w/ min + max being STCS-specific options. v4 rearranges background/maximal methods to continue allowing maximal to kick off a compaction when autocompaction is disabled. was (Author: jbellis): I think the status quo (and v1, which perpetuates it) are too complex... Exhibit A being my reading of the code leading me to believe that there was no way to disable LCS. Much more clear to have LCS make clear that it doesn't deal with min/max at all, except via isCompactionDisabled. v4 rearranges background/maximal methods to continue allowing maximal to kick off a compaction when autocompaction is disabled. > overlapping sstables in leveled compaction strategy > --- > > Key: CASSANDRA-4233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4233 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Fix For: 1.1.1 > > Attachments: > 0001-Make-sure-Leveled-compaction-always-use-the-right-min-.txt, > 4233-assert.txt, 4233-v2.txt, 4233-v3.txt, 4233-v4.txt, system.log.bz2 > > > CASSANDRA-4142 introduces test failures, that are caused by overlapping > tables within a level, which Shouldn't Happen. -- 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.
[
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.(SSTableScanner.java:61)
> at
> org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.jav
[jira] [Updated] (CASSANDRA-4233) overlapping sstables in leveled compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4233: -- Attachment: 4233-v4.txt I think the status quo (and v1, which perpetuates it) are too complex... Exhibit A being my reading of the code leading me to believe that there was no way to disable LCS. Much more clear to have LCS make clear that it doesn't deal with min/max at all, except via isCompactionDisabled. v4 rearranges background/maximal methods to continue allowing maximal to kick off a compaction when autocompaction is disabled. > overlapping sstables in leveled compaction strategy > --- > > Key: CASSANDRA-4233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4233 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Fix For: 1.1.1 > > Attachments: > 0001-Make-sure-Leveled-compaction-always-use-the-right-min-.txt, > 4233-assert.txt, 4233-v2.txt, 4233-v3.txt, 4233-v4.txt, system.log.bz2 > > > CASSANDRA-4142 introduces test failures, that are caused by overlapping > tables within a level, which Shouldn't Happen. -- 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-3794) Avoid ID conflicts from concurrent schema changes
[ https://issues.apache.org/jira/browse/CASSANDRA-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3794: -- Summary: Avoid ID conflicts from concurrent schema changes (was: Change ColumnFamily identifiers to be UUIDs instead of sequential Integers.) > Avoid ID conflicts from concurrent schema changes > - > > Key: CASSANDRA-3794 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3794 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich > Fix For: 1.1.1 > > > Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. > Would be useful in the situation when nodes simultaneously trying to create > ColumnFamilies. -- 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-4256) Include stress tool in debian packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278158#comment-13278158 ] Nick Bailey commented on CASSANDRA-4256: Also I'll note it would be cool to get a 1.1.0-2 debian package out if we can. I guess this can't completely be considered solely a packaging change since the stress script itself changed, but I guess I'll leave that up to the committers. > Include stress tool in debian packaging > --- > > Key: CASSANDRA-4256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4256 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Assignee: Nick Bailey >Priority: Minor > Fix For: 1.1.1 > > Attachments: 0001-Include-stress-in-debian-package.patch > > > The stress tool isn't included in the debian packaging. We need to update > that to grab the stress shell script as well as put the stress.jar file in > lib. > Also the stress shell script needs to be updated to include looking in > /usr/share/cassandra... when searching for the stress jar so it will run in > packaged installations. -- 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-4256) Include stress tool in debian packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey updated CASSANDRA-4256: --- Attachment: 0001-Include-stress-in-debian-package.patch Includes stress stuff in debian package. Also slightly reorganizes the stress script so it will work better in packaged installs. > Include stress tool in debian packaging > --- > > Key: CASSANDRA-4256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4256 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Assignee: Nick Bailey >Priority: Minor > Fix For: 1.1.1 > > Attachments: 0001-Include-stress-in-debian-package.patch > > > The stress tool isn't included in the debian packaging. We need to update > that to grab the stress shell script as well as put the stress.jar file in > lib. > Also the stress shell script needs to be updated to include looking in > /usr/share/cassandra... when searching for the stress jar so it will run in > packaged installations. -- 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-4256) Include stress tool in debian packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey updated CASSANDRA-4256: --- Reviewer: thepaul > Include stress tool in debian packaging > --- > > Key: CASSANDRA-4256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4256 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Assignee: Nick Bailey >Priority: Minor > Fix For: 1.1.1 > > Attachments: 0001-Include-stress-in-debian-package.patch > > > The stress tool isn't included in the debian packaging. We need to update > that to grab the stress shell script as well as put the stress.jar file in > lib. > Also the stress shell script needs to be updated to include looking in > /usr/share/cassandra... when searching for the stress jar so it will run in > packaged installations. -- 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-4255) concurrent modif ex when repair is run on LCS
[
https://issues.apache.org/jira/browse/CASSANDRA-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4255:
--
Attachment: 4255.txt
patch attached to synchronize getEstimatedTasks. copyOnWriteArrayList would
probably work too, but we already synchronize other accesses (to prevent
cross-level races) so that's simplest here.
> concurrent modif ex when repair is run on LCS
> -
>
> Key: CASSANDRA-4255
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4255
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jackson Chung
> Attachments: 4255.txt
>
>
> came across this, will try to figure a way to systematically reprod this. But
> the problem is the sstable list in the manifest is changing as the repair is
> triggered:
> {panel}
> Exception in thread "main" java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
> at java.util.AbstractList$Itr.next(Unknown Source)
> at org.apache.cassandra.io.sstable.SSTable.getTotalBytes(SSTable.java:250)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.getEstimatedTasks(LeveledManifest.java:435)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getEstimatedRemainingTasks(LeveledCompactionStrategy.java:128)
> at
> org.apache.cassandra.db.compaction.CompactionManager.getPendingTasks(CompactionManager.java:1063)
> at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)
> at com.sun.jmx.mbeanserver.PerInterface.getAttribute(Unknown Source)
> at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(Unknown Source)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(Unknown
> Source)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown
> Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown
> Source)
> at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> at sun.rmi.transport.Transport$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {panel}
> maybe we could change the list to a copyOnArrayList? just a suggestion,
> haven't investigated much yet:
> {code:title=LeveledManifest.java}
> generations[i] = new ArrayList();
> {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] [Assigned] (CASSANDRA-4257) CQL3 range query with secondary index fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4257:
-
Assignee: Sylvain Lebresne
> CQL3 range query with secondary index fails
> ---
>
> Key: CASSANDRA-4257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4257
> Project: Cassandra
> Issue Type: Bug
> Components: API
>Affects Versions: 1.1.0
> Environment: Cassandra 1.1.0 and git cassandra-1.1 branch, as of
> commit fd92c09d95a53d582cb8c4b0e77ac47fdd884935
>Reporter: Sean Billig
>Assignee: Sylvain Lebresne
>Priority: Minor
> Labels: cql3, index
>
> This query fails:
> select * from indextest where setid = 0 and row < 1;
> when there's a secondary index on 'setid'; row isn't the primary key.
> {code:title=CQL3}
> bin$ ./cqlsh --cql3
> Connected to Git at localhost:9160.
> [cqlsh 2.2.0 | Cassandra 1.1.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
> 19.31.0]
> Use HELP for help.
> cqlsh> use warehouse1;
> cqlsh:warehouse1> create table indextest (id int primary key, row int, setid
> int);
> cqlsh:warehouse1> create index indextest_setid_idx on indextest (setid);
> cqlsh:warehouse1> insert into indextest (id, row, setid) values (0, 0, 0);
> cqlsh:warehouse1> insert into indextest (id, row, setid) values (1, 1, 0);
> cqlsh:warehouse1> insert into indextest (id, row, setid) values (2, 2, 0);
> cqlsh:warehouse1> select * from indextest where setid = 0;
> id | row | setid
> +-+---
> 0 | 0 | 0
> 1 | 1 | 0
> 2 | 2 | 0
> cqlsh:warehouse1> select * from indextest where setid = 0 and row = 1;
> id | row | setid
> +-+---
> 1 | 1 | 0
> cqlsh:warehouse1> select * from indextest where setid = 0 and row < 1;
> TSocket read 0 bytes
> {code}
> {code:title=Error message}
> ERROR 13:36:23,544 Error occurred during processing of message.
> java.lang.NullPointerException
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getIndexExpressions(SelectStatement.java:546)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.multiRangeSlice(SelectStatement.java:253)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:132)
> 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:1237)
> 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:680)
> {code}
> Works fine in CQL2:
> {code:title=CQL2}
> bin$ ./cqlsh_uuid --cql2
> Connected to Git at localhost:9160.
> [cqlsh 2.2.0 | Cassandra 1.1.0-SNAPSHOT | CQL spec 2.0.0 | Thrift protocol
> 19.31.0]
> Use HELP for help.
> cqlsh> use warehouse1;
> cqlsh:warehouse1> select * from indextest where setid = 0 and row < 1;
> id | row | setid
> +-+---
> 0 | 0 | 0
> cqlsh:warehouse1> select * from indextest where setid = 0 and row < 2;
> id | row | setid
> +-+---
> 0 | 0 | 0
> 1 | 1 | 0
> {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-4257) CQL3 range query with secondary index fails
Sean Billig created CASSANDRA-4257:
--
Summary: CQL3 range query with secondary index fails
Key: CASSANDRA-4257
URL: https://issues.apache.org/jira/browse/CASSANDRA-4257
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.1.0
Environment: Cassandra 1.1.0 and git cassandra-1.1 branch, as of
commit fd92c09d95a53d582cb8c4b0e77ac47fdd884935
Reporter: Sean Billig
Priority: Minor
This query fails:
select * from indextest where setid = 0 and row < 1;
when there's a secondary index on 'setid'; row isn't the primary key.
{code:title=CQL3}
bin$ ./cqlsh --cql3
Connected to Git at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.31.0]
Use HELP for help.
cqlsh> use warehouse1;
cqlsh:warehouse1> create table indextest (id int primary key, row int, setid
int);
cqlsh:warehouse1> create index indextest_setid_idx on indextest (setid);
cqlsh:warehouse1> insert into indextest (id, row, setid) values (0, 0, 0);
cqlsh:warehouse1> insert into indextest (id, row, setid) values (1, 1, 0);
cqlsh:warehouse1> insert into indextest (id, row, setid) values (2, 2, 0);
cqlsh:warehouse1> select * from indextest where setid = 0;
id | row | setid
+-+---
0 | 0 | 0
1 | 1 | 0
2 | 2 | 0
cqlsh:warehouse1> select * from indextest where setid = 0 and row = 1;
id | row | setid
+-+---
1 | 1 | 0
cqlsh:warehouse1> select * from indextest where setid = 0 and row < 1;
TSocket read 0 bytes
{code}
{code:title=Error message}
ERROR 13:36:23,544 Error occurred during processing of message.
java.lang.NullPointerException
at
org.apache.cassandra.cql3.statements.SelectStatement.getIndexExpressions(SelectStatement.java:546)
at
org.apache.cassandra.cql3.statements.SelectStatement.multiRangeSlice(SelectStatement.java:253)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:132)
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:1237)
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:680)
{code}
Works fine in CQL2:
{code:title=CQL2}
bin$ ./cqlsh_uuid --cql2
Connected to Git at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.0-SNAPSHOT | CQL spec 2.0.0 | Thrift protocol
19.31.0]
Use HELP for help.
cqlsh> use warehouse1;
cqlsh:warehouse1> select * from indextest where setid = 0 and row < 1;
id | row | setid
+-+---
0 | 0 | 0
cqlsh:warehouse1> select * from indextest where setid = 0 and row < 2;
id | row | setid
+-+---
0 | 0 | 0
1 | 1 | 0
{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] [Assigned] (CASSANDRA-4256) Include stress tool in debian packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey reassigned CASSANDRA-4256: -- Assignee: Nick Bailey > Include stress tool in debian packaging > --- > > Key: CASSANDRA-4256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4256 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.1.0 >Reporter: Nick Bailey >Assignee: Nick Bailey >Priority: Minor > Fix For: 1.1.1 > > > The stress tool isn't included in the debian packaging. We need to update > that to grab the stress shell script as well as put the stress.jar file in > lib. > Also the stress shell script needs to be updated to include looking in > /usr/share/cassandra... when searching for the stress jar so it will run in > packaged installations. -- 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-4256) Include stress tool in debian packaging
Nick Bailey created CASSANDRA-4256: -- Summary: Include stress tool in debian packaging Key: CASSANDRA-4256 URL: https://issues.apache.org/jira/browse/CASSANDRA-4256 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: Nick Bailey Priority: Minor Fix For: 1.1.1 The stress tool isn't included in the debian packaging. We need to update that to grab the stress shell script as well as put the stress.jar file in lib. Also the stress shell script needs to be updated to include looking in /usr/share/cassandra... when searching for the stress jar so it will run in packaged installations. -- 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-4255) concurrent modif ex when repair is run on LCS
Jackson Chung created CASSANDRA-4255:
Summary: concurrent modif ex when repair is run on LCS
Key: CASSANDRA-4255
URL: https://issues.apache.org/jira/browse/CASSANDRA-4255
Project: Cassandra
Issue Type: Bug
Reporter: Jackson Chung
came across this, will try to figure a way to systematically reprod this. But
the problem is the sstable list in the manifest is changing as the repair is
triggered:
{panel}
Exception in thread "main" java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at org.apache.cassandra.io.sstable.SSTable.getTotalBytes(SSTable.java:250)
at
org.apache.cassandra.db.compaction.LeveledManifest.getEstimatedTasks(LeveledManifest.java:435)
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getEstimatedRemainingTasks(LeveledCompactionStrategy.java:128)
at
org.apache.cassandra.db.compaction.CompactionManager.getPendingTasks(CompactionManager.java:1063)
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)
at com.sun.jmx.mbeanserver.PerInterface.getAttribute(Unknown Source)
at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(Unknown Source)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(Unknown
Source)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown
Source)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown
Source)
at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(Unknown Source)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{panel}
maybe we could change the list to a copyOnArrayList? just a suggestion, haven't
investigated much yet:
{code:title=LeveledManifest.java}
generations[i] = new ArrayList();
{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-4221) Error while deleting a columnfamily that is being compacted.
[
https://issues.apache.org/jira/browse/CASSANDRA-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.(SSTableScanner.java:61)
> at
> org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
> at
> org.apache.cass
[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.
[
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.(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.cassandr
[jira] [Updated] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.
[
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.(SSTableScanner.java:61)
> at
> org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
> at
> org.ap
git commit: Correctly validate order by queries
Updated Branches:
refs/heads/cassandra-1.1 a0e0e2c13 -> fd92c09d9
Correctly validate order by queries
patch by slebresne; reviewed by jbellis for CASSANDRA-4246
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fd92c09d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fd92c09d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fd92c09d
Branch: refs/heads/cassandra-1.1
Commit: fd92c09d95a53d582cb8c4b0e77ac47fdd884935
Parents: a0e0e2c
Author: Sylvain Lebresne
Authored: Thu May 17 14:37:49 2012 +0200
Committer: Sylvain Lebresne
Committed: Thu May 17 19:37:12 2012 +0200
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java | 16 +++---
2 files changed, 9 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fd92c09d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 70d9bbe..46646bf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -48,6 +48,7 @@
* fix SecondaryIndex LelevedManifest save upon snapshot (CASSANDRA-4230)
* fix missing arrayOffset in FBUtilities.hash (CASSANDRA-4250)
* (cql3) Add name of parameters in CqlResultSet (CASSANDRA-4242)
+ * (cql3) Correctly validat order by queries (CASSANDRA-4246)
Merged from 1.0:
* Fix super columns bug where cache is not updated (CASSANDRA-4190)
* fix maxTimestamp to include row tombstones (CASSANDRA-4116)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fd92c09d/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index d3fb50a..35cb943 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -757,7 +757,8 @@ public class SelectStatement implements CQLStatement
cqlRows.add(new CqlRow(row.key.key, thriftColumns));
}
}
-// We don't allow reversed on range scan, but we do on multiget (IN
(...)), so let's reverse the rows there too.
+
+// Internal calls always return columns in the comparator order, even
when reverse was set
if (isReversed)
Collections.reverse(cqlRows);
@@ -1013,14 +1014,13 @@ public class SelectStatement implements CQLStatement
}
assert isReversed != null;
stmt.isReversed = isReversed;
-}
-// Only allow reversed if the row key restriction is an equality,
-// since we don't know how to reverse otherwise
-if (stmt.isReversed)
-{
-if (stmt.keyRestriction == null ||
!stmt.keyRestriction.isEquality())
-throw new InvalidRequestException("Descending order is
only supported is the first part of the PRIMARY KEY is restricted by an Equal
or a IN");
+// Only allow ordering if the row key restriction is an
equality,
+// since otherwise the order will be primarily on the row key.
+// TODO: we could allow ordering for IN queries, as we can do
the
+// sorting post-query easily, but we will have to add it
+if (stmt.keyRestriction == null ||
!stmt.keyRestriction.isEquality() || stmt.keyRestriction.eqValues.size() != 1)
+throw new InvalidRequestException("Ordering is only
supported is the first part of the PRIMARY KEY is restricted by an Equal or a
IN");
}
// If this is a query on tokens, it's necessary a range query
(there can be more than one key per token), so reject IN queries (as we don't
know how to do them)
[jira] [Commented] (CASSANDRA-4246) cql3 ORDER BY not ordering
[
https://issues.apache.org/jira/browse/CASSANDRA-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278001#comment-13278001
]
Jonathan Ellis commented on CASSANDRA-4246:
---
+1
> cql3 ORDER BY not ordering
> --
>
> Key: CASSANDRA-4246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4246
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
>Reporter: paul cannon
>Assignee: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.1.1
>
> Attachments: 4246-2.txt, 4246.txt
>
>
> Creating the simplest composite-key cql3 table I can think of, populating it
> with a few rows of data, then trying to do a query with an ORDER BY does not
> yield ordered results.
> Here's a cql script:
> {noformat}
> create keyspace test with strategy_class = 'SimpleStrategy'
>and strategy_options:replication_factor = 1;
> use test;
> create table moo (a int, b int, c int, primary key (a, b));
> insert into moo (a, b, c) values (123, 12, 3400);
> insert into moo (a, b, c) values (122, 13, 3500);
> insert into moo (a, b, c) values (124, 10, 3600);
> insert into moo (a, b, c) values (121, 11, 3700);
> select * from moo;
> select * from moo order by b;
> {noformat}
> Here is the output of those two queries:
> {noformat}
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> {noformat}
> I also tried these using the bare thrift interface, to make sure it wasn't
> python-cql or cqlsh doing something stupid. Same results. Am I totally
> missing something important here about how this is supposed to work?
--
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-4246) cql3 ORDER BY not ordering
[
https://issues.apache.org/jira/browse/CASSANDRA-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4246:
Attachment: 4246-2.txt
I'm good with that. Attaching v2 with that change.
> cql3 ORDER BY not ordering
> --
>
> Key: CASSANDRA-4246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4246
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
>Reporter: paul cannon
>Assignee: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.1.1
>
> Attachments: 4246-2.txt, 4246.txt
>
>
> Creating the simplest composite-key cql3 table I can think of, populating it
> with a few rows of data, then trying to do a query with an ORDER BY does not
> yield ordered results.
> Here's a cql script:
> {noformat}
> create keyspace test with strategy_class = 'SimpleStrategy'
>and strategy_options:replication_factor = 1;
> use test;
> create table moo (a int, b int, c int, primary key (a, b));
> insert into moo (a, b, c) values (123, 12, 3400);
> insert into moo (a, b, c) values (122, 13, 3500);
> insert into moo (a, b, c) values (124, 10, 3600);
> insert into moo (a, b, c) values (121, 11, 3700);
> select * from moo;
> select * from moo order by b;
> {noformat}
> Here is the output of those two queries:
> {noformat}
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> {noformat}
> I also tried these using the bare thrift interface, to make sure it wasn't
> python-cql or cqlsh doing something stupid. Same results. Am I totally
> missing something important here about how this is supposed to work?
--
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-4246) cql3 ORDER BY not ordering
[
https://issues.apache.org/jira/browse/CASSANDRA-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277976#comment-13277976
]
Jonathan Ellis commented on CASSANDRA-4246:
---
doh, demorgan fail :)
i do think it's a little clearer to have a chain of || than a mix of || and &&,
though
> cql3 ORDER BY not ordering
> --
>
> Key: CASSANDRA-4246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4246
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
>Reporter: paul cannon
>Assignee: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.1.1
>
> Attachments: 4246.txt
>
>
> Creating the simplest composite-key cql3 table I can think of, populating it
> with a few rows of data, then trying to do a query with an ORDER BY does not
> yield ordered results.
> Here's a cql script:
> {noformat}
> create keyspace test with strategy_class = 'SimpleStrategy'
>and strategy_options:replication_factor = 1;
> use test;
> create table moo (a int, b int, c int, primary key (a, b));
> insert into moo (a, b, c) values (123, 12, 3400);
> insert into moo (a, b, c) values (122, 13, 3500);
> insert into moo (a, b, c) values (124, 10, 3600);
> insert into moo (a, b, c) values (121, 11, 3700);
> select * from moo;
> select * from moo order by b;
> {noformat}
> Here is the output of those two queries:
> {noformat}
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> {noformat}
> I also tried these using the bare thrift interface, to make sure it wasn't
> python-cql or cqlsh doing something stupid. Same results. Am I totally
> missing something important here about how this is supposed to work?
--
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-4233) overlapping sstables in leveled compaction strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277968#comment-13277968
]
Sylvain Lebresne commented on CASSANDRA-4233:
-
I'd submit that my version was giving a slightly better feedback through JMX
but I guess that's not a big deal.
But other than that, the definition of isCompactionDisabled so far has been to
disallow automatic compaction, but forced compaction ("maximal" ones) was still
allowed. v2 change that for LCS. I'll note that disabling compaction was
respected for background tasks by LCS by the fact that
DataTracker.maxCompacting was skipping compaction when maxCompactionThreshold
is 0, but allowed for maximal tasks since the maxCompactionThreshold is
overriden in compactionManager in that case. I don't know if it's a big deal
though (I suspect some tests would fail if run with LCS because they rely on
that) but wanted to mention it.
> overlapping sstables in leveled compaction strategy
> ---
>
> Key: CASSANDRA-4233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4233
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 1.1.1
>
> Attachments:
> 0001-Make-sure-Leveled-compaction-always-use-the-right-min-.txt,
> 4233-assert.txt, 4233-v2.txt, 4233-v3.txt, system.log.bz2
>
>
> CASSANDRA-4142 introduces test failures, that are caused by overlapping
> tables within a level, which Shouldn't Happen.
--
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-4233) overlapping sstables in leveled compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4233: -- Attachment: 4233-v3.txt tweaked v3 to not mess w/ min/max settings at all (which would result in re-activating compaction if it's "disabled") > overlapping sstables in leveled compaction strategy > --- > > Key: CASSANDRA-4233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4233 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Fix For: 1.1.1 > > Attachments: > 0001-Make-sure-Leveled-compaction-always-use-the-right-min-.txt, > 4233-assert.txt, 4233-v2.txt, 4233-v3.txt, system.log.bz2 > > > CASSANDRA-4142 introduces test failures, that are caused by overlapping > tables within a level, which Shouldn't Happen. -- 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-4233) overlapping sstables in leveled compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4233: -- Attachment: 4233-v2.txt simpler v2 attached, to just ignore CFS min/max in the actual LeveledCompactionTask. also respects isCompactionDisabled in LCS. > overlapping sstables in leveled compaction strategy > --- > > Key: CASSANDRA-4233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4233 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Fix For: 1.1.1 > > Attachments: > 0001-Make-sure-Leveled-compaction-always-use-the-right-min-.txt, > 4233-assert.txt, 4233-v2.txt, system.log.bz2 > > > CASSANDRA-4142 introduces test failures, that are caused by overlapping > tables within a level, which Shouldn't Happen. -- 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-4246) cql3 ORDER BY not ordering
[
https://issues.apache.org/jira/browse/CASSANDRA-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277954#comment-13277954
]
Sylvain Lebresne commented on CASSANDRA-4246:
-
Given that !(A&&B) == (!A)||(!B), I'd suggest that both are fine :)
But I'm fine going with the second one if you find it more readable.
> cql3 ORDER BY not ordering
> --
>
> Key: CASSANDRA-4246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4246
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
>Reporter: paul cannon
>Assignee: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.1.1
>
> Attachments: 4246.txt
>
>
> Creating the simplest composite-key cql3 table I can think of, populating it
> with a few rows of data, then trying to do a query with an ORDER BY does not
> yield ordered results.
> Here's a cql script:
> {noformat}
> create keyspace test with strategy_class = 'SimpleStrategy'
>and strategy_options:replication_factor = 1;
> use test;
> create table moo (a int, b int, c int, primary key (a, b));
> insert into moo (a, b, c) values (123, 12, 3400);
> insert into moo (a, b, c) values (122, 13, 3500);
> insert into moo (a, b, c) values (124, 10, 3600);
> insert into moo (a, b, c) values (121, 11, 3700);
> select * from moo;
> select * from moo order by b;
> {noformat}
> Here is the output of those two queries:
> {noformat}
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> {noformat}
> I also tried these using the bare thrift interface, to make sure it wasn't
> python-cql or cqlsh doing something stupid. Same results. Am I totally
> missing something important here about how this is supposed to work?
--
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-4246) cql3 ORDER BY not ordering
[
https://issues.apache.org/jira/browse/CASSANDRA-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277943#comment-13277943
]
Jonathan Ellis commented on CASSANDRA-4246:
---
Is this right?
{code}
if (stmt.keyRestriction == null ||
!(stmt.keyRestriction.isEquality() && stmt.keyRestriction.eqValues.size() == 1))
{code}
I would have expected
{code}
if (stmt.keyRestriction == null ||
!stmt.keyRestriction.isEquality() || stmt.keyRestriction.eqValues.size() != 1)
{code}
> cql3 ORDER BY not ordering
> --
>
> Key: CASSANDRA-4246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4246
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
>Reporter: paul cannon
>Assignee: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.1.1
>
> Attachments: 4246.txt
>
>
> Creating the simplest composite-key cql3 table I can think of, populating it
> with a few rows of data, then trying to do a query with an ORDER BY does not
> yield ordered results.
> Here's a cql script:
> {noformat}
> create keyspace test with strategy_class = 'SimpleStrategy'
>and strategy_options:replication_factor = 1;
> use test;
> create table moo (a int, b int, c int, primary key (a, b));
> insert into moo (a, b, c) values (123, 12, 3400);
> insert into moo (a, b, c) values (122, 13, 3500);
> insert into moo (a, b, c) values (124, 10, 3600);
> insert into moo (a, b, c) values (121, 11, 3700);
> select * from moo;
> select * from moo order by b;
> {noformat}
> Here is the output of those two queries:
> {noformat}
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> {noformat}
> I also tried these using the bare thrift interface, to make sure it wasn't
> python-cql or cqlsh doing something stupid. Same results. Am I totally
> missing something important here about how this is supposed to work?
--
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-3991) Investigate importance of jsvc in debian packages
[ https://issues.apache.org/jira/browse/CASSANDRA-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3991: -- Fix Version/s: (was: 1.1.1) 1.2 Doesn't look like this is going to make 1.1.1, and 1.1.2 is probably too late to change this, so pushing to 1.2 > Investigate importance of jsvc in debian packages > - > > Key: CASSANDRA-3991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3991 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 1.2 > > > jsvc seems to be buggy at best. For instance, if you set a small heap like > 128M it seems to completely ignore this and use as much memory as it wants. > I don't know what this is buying us over launching /usr/bin/cassandra > directly like the redhat scripts do, but I've seen multiple complaints about > its memory usage. -- 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] [Resolved] (CASSANDRA-4244) RangeSlice command with CL.One doesn't do RR
[
https://issues.apache.org/jira/browse/CASSANDRA-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4244.
---
Resolution: Duplicate
Fix Version/s: (was: 1.1.1)
Assignee: (was: Vijay)
duplicate of CASSANDRA-3687 and CASSANDRA-967
> RangeSlice command with CL.One doesn't do RR
>
>
> Key: CASSANDRA-4244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4244
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.10
>Reporter: Vijay
>Priority: Minor
>
> Looks like SP.getRangeSlice has the following code
> {quote}
> if (consistency_level == ConsistencyLevel.ONE &&
> !liveEndpoints.isEmpty() &&
> liveEndpoints.get(0).equals(FBUtilities.getBroadcastAddress()))
> {quote}
> We might want to change it to use LocalReadRunnable consistent with fetchRows.
--
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-4233) overlapping sstables in leveled compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4233: Attachment: 0001-Make-sure-Leveled-compaction-always-use-the-right-min-.txt This was kind of a test problem, though this is kind of a bug. The main problem is that LeveledCompaction should never get a maxCompactionThreshold < Integer.MAX_VALUE, otherwise it ends up not compaction what it should and this screw up the levels. However, the way we try to ensure that is by overriding the maxCompactionThreshold in LeveledCompactionStrategy constructor. This is however dangerous because it means that if anyone change the threshold afterward, it will break. And sure enough, that is what happens with CompactionsTest. So attaching a patch that change the code to ensure this doesn't happen. To a large extend this patch is a hack and in the long run, we should refactor all this to move the min/max compaction threshold inside SizeTieredCompaction, where they belong. This is however a bigger refactor than I want to do on the 1.1 branch as currently the thresholds are used to deactivate automatic compaction and whatnot. > overlapping sstables in leveled compaction strategy > --- > > Key: CASSANDRA-4233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4233 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis > Fix For: 1.1.1 > > Attachments: > 0001-Make-sure-Leveled-compaction-always-use-the-right-min-.txt, > 4233-assert.txt, system.log.bz2 > > > CASSANDRA-4142 introduces test failures, that are caused by overlapping > tables within a level, which Shouldn't Happen. -- 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-4223) Non Unique Streaming session ID's
[
https://issues.apache.org/jira/browse/CASSANDRA-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277889#comment-13277889
]
Yuki Morishita commented on CASSANDRA-4223:
---
Aaron,
Go ahead. :)
> Non Unique Streaming session ID's
> -
>
> Key: CASSANDRA-4223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4223
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 10.04.2 LTS
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
> "Bare metal" servers from
> https://www.stormondemand.com/servers/baremetal.html
> The servers run on a custom hypervisor.
>
>Reporter: Aaron Morton
>Assignee: Aaron Morton
> Labels: datastax_qa
> Fix For: 1.0.11, 1.1.1
>
> Attachments: 4223_counter_session_id-V2.diff,
> 4223_counter_session_id.diff, NanoTest.java, fmm streaming bug.txt
>
>
> I have observed repair processes failing due to duplicate Streaming session
> ID's. In this installation it is preventing rebalance from completing. I
> believe it has also prevented repair from completing in the past.
> The attached streaming-logs.txt file contains log messages and an explanation
> of what was happening during a repair operation. it has the evidence for
> duplicate session ID's.
> The duplicate session id's were generated on the repairing node and sent to
> the streaming node. The streaming source replaced the first session with the
> second which resulted in both sessions failing when the first FILE_COMPLETE
> message was received.
> The errors were:
> {code:java}
> DEBUG [MiscStage:1] 2012-05-03 21:40:33,997 StreamReplyVerbHandler.java (line
> 47) Received StreamReply StreamReply(sessionId=26132848816442266,
> file='/var/lib/cassandra/data/FMM_Studio/PartsData-hc-1-Data.db',
> action=FILE_FINISHED)
> ERROR [MiscStage:1] 2012-05-03 21:40:34,027 AbstractCassandraDaemon.java
> (line 139) Fatal exception in thread Thread[MiscStage:1,5,main]
> java.lang.IllegalStateException: target reports current file is
> /var/lib/cassandra/data/FMM_Studio/PartsData-hc-1-Data.db but is null
> at
> org.apache.cassandra.streaming.StreamOutSession.validateCurrentFile(StreamOutSession.java:195)
> at
> org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:58)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> and
> {code:java}
> DEBUG [MiscStage:2] 2012-05-03 21:40:36,497 StreamReplyVerbHandler.java (line
> 47) Received StreamReply StreamReply(sessionId=26132848816442266,
> file='/var/lib/cassandra/data/OpsCenter/rollups7200-hc-3-Data.db',
> action=FILE_FINISHED)
> ERROR [MiscStage:2] 2012-05-03 21:40:36,497 AbstractCassandraDaemon.java
> (line 139) Fatal exception in thread Thread[MiscStage:2,5,main]
> java.lang.IllegalStateException: target reports current file is
> /var/lib/cassandra/data/OpsCenter/rollups7200-hc-3-Data.db but is null
> at
> org.apache.cassandra.streaming.StreamOutSession.validateCurrentFile(StreamOutSession.java:195)
> at
> org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:58)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> I think this is because System.nanoTime() is used for the session ID when
> creating the StreamInSession objects (driven from
> StorageService.requestRanges()) .
> From the documentation
> (http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime())
> {quote}
> This method provides nanosecond precision, but not necessarily nanosecond
> accuracy. No guarantees are made about how frequently values change.
> {quote}
> Also some info here on clocks and timers
> https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks
> The hypervisor may be at fault here. But it seems like we cannot rely on
> successive calls to nanoTime() to return different values.
> To avoid message/interface changes on the StreamHeader it would be good to
> keep the session ID a long. The simplest approach may be to make successive
> calls to nanoTime until the result changes. We could fail if a certain number
> of milliseconds have passed.
> Hash
[jira] [Updated] (CASSANDRA-4233) overlapping sstables in leveled compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4233: Affects Version/s: 1.1.0 Fix Version/s: 1.1.1 > overlapping sstables in leveled compaction strategy > --- > > Key: CASSANDRA-4233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4233 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis > Fix For: 1.1.1 > > Attachments: 4233-assert.txt, system.log.bz2 > > > CASSANDRA-4142 introduces test failures, that are caused by overlapping > tables within a level, which Shouldn't Happen. -- 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-4246) cql3 ORDER BY not ordering
[
https://issues.apache.org/jira/browse/CASSANDRA-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4246:
Attachment: 4246.txt
We were doing some validation that order by was not used when multiple internal
rows are queried, but only for the reversed case for some reason. Patch
attached to fix (it also refuse order by when a IN is used on the row key as
this would require a bit more work to have it work correctly).
> cql3 ORDER BY not ordering
> --
>
> Key: CASSANDRA-4246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4246
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
>Reporter: paul cannon
>Assignee: Sylvain Lebresne
> Labels: cql3
> Attachments: 4246.txt
>
>
> Creating the simplest composite-key cql3 table I can think of, populating it
> with a few rows of data, then trying to do a query with an ORDER BY does not
> yield ordered results.
> Here's a cql script:
> {noformat}
> create keyspace test with strategy_class = 'SimpleStrategy'
>and strategy_options:replication_factor = 1;
> use test;
> create table moo (a int, b int, c int, primary key (a, b));
> insert into moo (a, b, c) values (123, 12, 3400);
> insert into moo (a, b, c) values (122, 13, 3500);
> insert into moo (a, b, c) values (124, 10, 3600);
> insert into moo (a, b, c) values (121, 11, 3700);
> select * from moo;
> select * from moo order by b;
> {noformat}
> Here is the output of those two queries:
> {noformat}
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> a | b | c
> -++--
> 121 | 11 | 3700
> 122 | 13 | 3500
> 124 | 10 | 3600
> 123 | 12 | 3400
> {noformat}
> I also tried these using the bare thrift interface, to make sure it wasn't
> python-cql or cqlsh doing something stupid. Same results. Am I totally
> missing something important here about how this is supposed to work?
--
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-4245) Provide a UT8Type (case insensitive) comparator
[ https://issues.apache.org/jira/browse/CASSANDRA-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277751#comment-13277751 ] Sylvain Lebresne commented on CASSANDRA-4245: - bq. Where the case of the string is preserved but then ignored in queries. I don't think that this is what the '6 columns' option does. Namely, if we have 6 columns, it means that we don't ignore the case in queries (since we have multiple values for the same name but with different case). In other words, if its case insensitivity we want, it's the 3 columns option, for which I kind of agree with Jonathan and Brandon, can be done client side fairly easily by lower-casing everything. The 6 columns option is more about having a different string order that puts strings that differ only by case closer, which can be neat, but is it so useful that it justify being a native type? > Provide a UT8Type (case insensitive) comparator > --- > > Key: CASSANDRA-4245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4245 > Project: Cassandra > Issue Type: New Feature >Reporter: Ertio Lew >Priority: Minor > > It is a common use case to use a bunch of entity names as column names & then > use the row as a search index, using search by range. For such use cases & > others, it is useful to have a UTF8 comparator that provides case insensitive > ordering of columns. -- 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-4223) Non Unique Streaming session ID's
[
https://issues.apache.org/jira/browse/CASSANDRA-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277722#comment-13277722
]
Aaron Morton commented on CASSANDRA-4223:
-
Yuki were you going to commit this or do you want me to?
> Non Unique Streaming session ID's
> -
>
> Key: CASSANDRA-4223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4223
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 10.04.2 LTS
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
> "Bare metal" servers from
> https://www.stormondemand.com/servers/baremetal.html
> The servers run on a custom hypervisor.
>
>Reporter: Aaron Morton
>Assignee: Aaron Morton
> Labels: datastax_qa
> Fix For: 1.0.11, 1.1.1
>
> Attachments: 4223_counter_session_id-V2.diff,
> 4223_counter_session_id.diff, NanoTest.java, fmm streaming bug.txt
>
>
> I have observed repair processes failing due to duplicate Streaming session
> ID's. In this installation it is preventing rebalance from completing. I
> believe it has also prevented repair from completing in the past.
> The attached streaming-logs.txt file contains log messages and an explanation
> of what was happening during a repair operation. it has the evidence for
> duplicate session ID's.
> The duplicate session id's were generated on the repairing node and sent to
> the streaming node. The streaming source replaced the first session with the
> second which resulted in both sessions failing when the first FILE_COMPLETE
> message was received.
> The errors were:
> {code:java}
> DEBUG [MiscStage:1] 2012-05-03 21:40:33,997 StreamReplyVerbHandler.java (line
> 47) Received StreamReply StreamReply(sessionId=26132848816442266,
> file='/var/lib/cassandra/data/FMM_Studio/PartsData-hc-1-Data.db',
> action=FILE_FINISHED)
> ERROR [MiscStage:1] 2012-05-03 21:40:34,027 AbstractCassandraDaemon.java
> (line 139) Fatal exception in thread Thread[MiscStage:1,5,main]
> java.lang.IllegalStateException: target reports current file is
> /var/lib/cassandra/data/FMM_Studio/PartsData-hc-1-Data.db but is null
> at
> org.apache.cassandra.streaming.StreamOutSession.validateCurrentFile(StreamOutSession.java:195)
> at
> org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:58)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> and
> {code:java}
> DEBUG [MiscStage:2] 2012-05-03 21:40:36,497 StreamReplyVerbHandler.java (line
> 47) Received StreamReply StreamReply(sessionId=26132848816442266,
> file='/var/lib/cassandra/data/OpsCenter/rollups7200-hc-3-Data.db',
> action=FILE_FINISHED)
> ERROR [MiscStage:2] 2012-05-03 21:40:36,497 AbstractCassandraDaemon.java
> (line 139) Fatal exception in thread Thread[MiscStage:2,5,main]
> java.lang.IllegalStateException: target reports current file is
> /var/lib/cassandra/data/OpsCenter/rollups7200-hc-3-Data.db but is null
> at
> org.apache.cassandra.streaming.StreamOutSession.validateCurrentFile(StreamOutSession.java:195)
> at
> org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:58)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> I think this is because System.nanoTime() is used for the session ID when
> creating the StreamInSession objects (driven from
> StorageService.requestRanges()) .
> From the documentation
> (http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime())
> {quote}
> This method provides nanosecond precision, but not necessarily nanosecond
> accuracy. No guarantees are made about how frequently values change.
> {quote}
> Also some info here on clocks and timers
> https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks
> The hypervisor may be at fault here. But it seems like we cannot rely on
> successive calls to nanoTime() to return different values.
> To avoid message/interface changes on the StreamHeader it would be good to
> keep the session ID a long. The simplest approach may be to make successive
> calls to nanoTime until the result changes. We could fail if a certain number
> of m
[jira] [Commented] (CASSANDRA-4245) Provide a UT8Type (case insensitive) comparator
[
https://issues.apache.org/jira/browse/CASSANDRA-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277721#comment-13277721
]
Aaron Morton commented on CASSANDRA-4245:
-
bq. "case-insensitive but case-preserving,"
Thinking about it, the "six columns" option more closely matches the RDBMS
experience. Where the case of the string is preserved but then ignored in
queries. It probably also take less to implement.
bq. And providing a comparator per locale is clearly insane.
I would imagine the collation being a comparator property that was used to
construct the java.text.Collator - e.g
UTF8Type("query_collation"="english_CI_AS") for english local, case
insensitive, accent sensitive. Would need to do some research on how to use the
java.text.Collator correctly though.
Still think there may be a need, but it's more than a drop in comparator.
> Provide a UT8Type (case insensitive) comparator
> ---
>
> Key: CASSANDRA-4245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4245
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Ertio Lew
>Priority: Minor
>
> It is a common use case to use a bunch of entity names as column names & then
> use the row as a search index, using search by range. For such use cases &
> others, it is useful to have a UTF8 comparator that provides case insensitive
> ordering of columns.
--
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.
[
https://issues.apache.org/jira/browse/CASSANDRA-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4221:
---
Attachment: CASSANDRA-4221-logging.patch
Interesting, I can't reproduce it myself. Can you please run it with logging
patch attached (and enabled DEBUG logging) and attach debug log from your C*
node to this task, so I can check that is happening inside of DataTracker in
your case?...
> 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.SSTabl
[jira] [Commented] (CASSANDRA-2834) Avoid repair getting started twice at the same time for the same CF
[ https://issues.apache.org/jira/browse/CASSANDRA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277694#comment-13277694 ] Sylvain Lebresne commented on CASSANDRA-2834: - You mean having a node skip a validation compaction if it is already running one for the same range? If we do that, what do we answer to the node that asked for a a merkle tree but we've decided to not do it? And even if we answer to the node a 'won't do it' (which probably already require a small protocol change), then what does that node do? Either it continue a repair that won't be complete, or he tries to abort it, but then we need a way to abort a repair. Besides, if 2 repair X and Y are started on 2 different nodes, there is no guarantee that one node won't skip a repair for session X, and another for session Y, so we're not even sure to make correct progress on any of those session. > Avoid repair getting started twice at the same time for the same CF > --- > > Key: CASSANDRA-2834 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2834 > Project: Cassandra > Issue Type: Improvement >Reporter: Terje Marthinussen >Assignee: Sylvain Lebresne >Priority: Minor > > It may seem like it is possible to start repair twice at the same time on the > same CF? > Not 100% verified, but if this is indeed the case, we may want to consider > avoiding that including making nodetool repair abort and return and error if > repair is attempted on the same CF as one which already have repair running. -- 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
