[jira] [Commented] (CASSANDRA-4049) Add SSTable components required by new DSE CFS compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229943#comment-13229943 ] Sylvain Lebresne commented on CASSANDRA-4049: - Agreed with Stu. > Add SSTable components required by new DSE CFS compaction strategy > -- > > Key: CASSANDRA-4049 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Piotr Kołaczkowski >Priority: Minor > Attachments: component_patch.diff > > > CFS compaction strategy coming up in the next DSE release needs to store some > important information in Tombstones.db and RemovedKeys.db files, one per > sstable. However, currently Cassandra issues warnings when these files are > found in the data directory. Additionally, when switched to > SizeTieredCompactionStrategy, the files are left in the data directory after > compaction. > The attached patch adds new components to the Component class so Cassandra > knows about those files. -- 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-3811) Empty rpc_address prevents running MapReduce job outside a cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrik Modesto updated CASSANDRA-3811:
--
Priority: Critical (was: Major)
Affects Version/s: 0.8.10
Changed to critical, because Cassandra-Hadoop doesn't work.
The problem really is the rpc_endpoint: 0.0.0.0, the CFIF can't handle that.
What happens if you setup a Cassandra cluster with rpc_endpoint: 0.0.0.0:
A) you run mapreduce job from outside the cluster, where there is no Cassandra
server on localhost; job fails, can't connect to localhost to get splits.
B) you run mapreduce job from inside the cluster, where there is Cassandra
server on localhost:
1) CFIF calls describe_ring that returns something like this:
{noformat}
148873535527910577765226390751398592512 -
21267647932558653966460912964485513216 [10.0.18.129,10.0.18.99,10.0.18.98]
[0.0.0.0,0.0.0.0,0.0.0.0]
106338239662793269832304564822427566080 -
148873535527910577765226390751398592512 [10.0.18.87,10.0.18.129,10.0.18.99]
[0.0.0.0,0.0.0.0,0.0.0.0]
63802943797675961899382738893456539648 -
106338239662793269832304564822427566080 [10.0.18.98,10.0.18.87,10.0.18.129]
[0.0.0.0,0.0.0.0,0.0.0.0]
21267647932558653966460912964485513216 - 63802943797675961899382738893456539648
[10.0.18.99,10.0.18.98,10.0.18.87] [0.0.0.0,0.0.0.0,0.0.0.0]
{noformat}
Note the 0.0.0.0 IPs returned as rpc_endpoints.
2) CFIF.getSplits then asks each node for the respective key range, which is
the 0.0.0.0 ie. localhost instead of a node that really owns the key range
3) localhost has of course just its key range and for it, correctly returns
the splits, for other key ranges it returns start_key:end_key which is wrong
4) hadoop then uses these wrong splits to calculate work for tasks etc. and
such tasks never finish and get killed eventualy
Here is output of my simple test utility:
{noformat}
$ ./describe.py rfTest2
describe_ring
148873535527910577765226390751398592512 -
21267647932558653966460912964485513216 [10.0.18.129,10.0.18.99]
[0.0.0.0,0.0.0.0]
106338239662793269832304564822427566080 -
148873535527910577765226390751398592512 [10.0.18.87,10.0.18.129]
[0.0.0.0,0.0.0.0]
63802943797675961899382738893456539648 -
106338239662793269832304564822427566080 [10.0.18.98,10.0.18.87]
[0.0.0.0,0.0.0.0]
21267647932558653966460912964485513216 - 63802943797675961899382738893456539648
[10.0.18.99,10.0.18.98] [0.0.0.0,0.0.0.0]
10.0.18.98: ['148873535527910577765226390751398592512',
'21267647932558653966460912964485513216']
10.0.18.98: ['106338239662793269832304564822427566080',
'148873535527910577765226390751398592512']
10.0.18.98: ['63802943797675961899382738893456539648',
'68793533432627989494832763003260446472',
'74819769657966890059528779911565558455',
'80567991868944382942831588469855825734',
'87891603877459256288845990379651315512',
'93924679813695495884062398757642798961',
'100192950219560445380847254251687782801',
'106338239662793269832304564822427566080']
10.0.18.98: ['21267647932558653966460912964485513216',
'2624410683717175587596295327909742',
'32201975146808227304585609407713826911',
'38824800339023975211549544003547061559',
'45039424797795217820051587252107982434',
'50205785598336646901229997590646295071',
'57012896007316411899806797335411421637',
'63802943797675961899382738893456539648']
{noformat}
To explain the output. I have 4 node test cluster, keyspace rfTest2 has RF=2.
It calls describe_ring to get node list. Then it calls describe_splits for each
key range but asks always the same node, the same way CFIF does. You can see
that nodes which don't have the key range return just start_key:end_key.
Solutions:
A) never return 0.0.0.0 from describe_ring
B) fix CFIF to use endpoint if rpc_endpoint is localhost
Regars,
Patrik
> Empty rpc_address prevents running MapReduce job outside a cluster
> --
>
> Key: CASSANDRA-3811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3811
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.9, 0.8.10
> Environment: Debian Stable,
> Cassandra 0.8.9,
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03),
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>Reporter: Patrik Modesto
>Priority: Critical
>
> Setting rpc_address to empty to make Cassandra listen on all network
> intefaceces breaks running mapredude job from outside the cluster. The jobs
> wont even start, showing these messages:
> {noformat}
> 12/01/26 11:15:21 DEBUG hadoop.ColumnFamilyInputFormat: failed
> connect to endpoint 0.0.0.0
> java.io.IOException: unable to connect to server
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:389)
>at
> org.apache.ca
[jira] [Created] (CASSANDRA-4053) IncomingTcpConnection can not be closed when the peer is brutaly terminated or switch is failed
IncomingTcpConnection can not be closed when the peer is brutaly terminated or switch is failed --- Key: CASSANDRA-4053 URL: https://issues.apache.org/jira/browse/CASSANDRA-4053 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.8 Reporter: Zhu Han IncomingTcpConnection has no way to detect the peer is down when the peer meets power loss or the network infrastructure is failed, and the thread is leaked... For safety, as least SO_KEEPALIVE should be set on those IncomingTcpConnections. The better way is to close the incoming connections when failure detector notifies the peer failure, but it requires some extra bookmarking. Besides it, it would be better if IncomingTcpConnection and OutgoingTcpConnection is marked as daemon thread... -- 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-4054) SStableImport and SStableExport does not serialize row level deletion
SStableImport and SStableExport does not serialize row level deletion - Key: CASSANDRA-4054 URL: https://issues.apache.org/jira/browse/CASSANDRA-4054 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.8 Reporter: Zhu Han SSTableImport and SSTableExport does not serialize/de-serialize the row-level deletion info to/from the json file. This brings back the deleted data after restore from the json file. -- 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-4017) Unify migrations
[
https://issues.apache.org/jira/browse/CASSANDRA-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230155#comment-13230155
]
Sylvain Lebresne commented on CASSANDRA-4017:
-
I've put some initial patch at
https://github.com/pcmanus/cassandra/commits/4017.
As described above, the main idea is to unify code between what happens on the
initial node applying the migration and the rest of the nodes. With this patch,
when a schema change has to happen, we generate the RowMutation corresponding
and send it to all nodes (including the localhost) and all the node use that to
figure out what changed and how to update in-memory structures. The patch
removes the Migration classes (that weren't doing much anyway) and moves a bit
a code around to make it easier to follow a migration path.
Sadly, this ended up posing problem with the unit tests. More precisely,
SchemaLoader was not using the migration path, but only loading the schema
in-memory. Because the patch removes the local special case, this was breaking
DefsTest. The solution was to make SchemaLoader use actual migrations (to get
stuffs written to disk). But now that means that SchemaLoader needs to be
merged with CleanupHelper (otherwise, since the cleanup was happening with the
schema loading, the loading was conflicting with the schema of the previous
test).
When that's fixed (which the patch does), MoveTest still broke with a
ClassCastException between BytesToken and BigIntegerToken. The reason is that
MoveTest use {{ss.setPartitionerUnsafe}} to set the RandomPartitioner. But it
does that *after* the schema has been loaded. But now the schema happens to
trigger flushing of system tables. Those are flushed with the order preserving
partitioner and later conflict with the sstable created after the partitioner
change. I'm not sure what the best fix is for this and so the patch doesn't fix
that failure. Maybe we could just make MoveTest keep the test partitioner. But
I suppose the intention was to test the random partitioner, so
> Unify migrations
>
>
> Key: CASSANDRA-4017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4017
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.1.0
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
>
> Now that we can send a schema as a RowMutation, there's no need to keep
> separate add/drop/update migration classes around. Let's just send the
> schema to our counterparts and let them figure out what changed. Currently
> we have "figure out what changed" code to both generate migrations on the
> sender, and for application on the target, which adds complexity.
--
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
git commit: Fix small bug introduced by #2319
Updated Branches: refs/heads/trunk 845f40733 -> 65c33fac9 Fix small bug introduced by #2319 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65c33fac Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65c33fac Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65c33fac Branch: refs/heads/trunk Commit: 65c33fac9c974fe93b617cc8f3e77c929733df21 Parents: 845f407 Author: Sylvain Lebresne Authored: Thu Mar 15 15:24:45 2012 +0100 Committer: Sylvain Lebresne Committed: Thu Mar 15 15:24:45 2012 +0100 -- .../io/sstable/SSTableIdentityIterator.java|6 -- 1 files changed, 4 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/65c33fac/src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java -- diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java b/src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java index f5895a2..f22cb2e 100644 --- a/src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java +++ b/src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java @@ -82,13 +82,15 @@ public class SSTableIdentityIterator implements Comparable
[jira] [Commented] (CASSANDRA-2319) Promote row index
[ https://issues.apache.org/jira/browse/CASSANDRA-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230193#comment-13230193 ] Sylvain Lebresne commented on CASSANDRA-2319: - You're right, I'm pushed the trivial fix with commit 65c33fa. > Promote row index > - > > Key: CASSANDRA-2319 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2319 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Stu Hood >Assignee: Sylvain Lebresne > Labels: index, timeseries > Fix For: 1.2 > > Attachments: 2319-v1.tgz, 2319-v2.tgz, promotion.pdf, version-f.txt, > version-g-lzf.txt, version-g.txt > > > The row index contains entries for configurably sized blocks of a wide row. > For a row of appreciable size, the row index ends up directing the third seek > (1. index, 2. row index, 3. content) to nearby the first column of a scan. > Since the row index is always used for wide rows, and since it contains > information that tells us whether or not the 3rd seek is necessary (the > column range or name we are trying to slice may not exist in a given > sstable), promoting the row index into the sstable index would allow us to > drop the maximum number of seeks for wide rows back to 2, and, more > importantly, would allow sstables to be eliminated using only the index. > An example usecase that benefits greatly from this change is time series data > in wide rows, where data is appended to the beginning or end of the row. Our > existing compaction strategy gets lucky and clusters the oldest data in the > oldest sstables: for queries to recently appended data, we would be able to > eliminate wide rows using only the sstable index, rather than needing to seek > into the data file to determine that it isn't interesting. For narrow rows, > this change would have no effect, as they will not reach the threshold for > indexing anyway. > A first cut design for this change would look very similar to the file format > design proposed on #674: > http://wiki.apache.org/cassandra/FileFormatDesignDoc: row keys clustered, > column names clustered, and offsets clustered and delta encoded. -- 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-3811) Empty rpc_address prevents running MapReduce job outside a cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3811:
--
Priority: Minor (was: Critical)
Changing to Minor.
I don't like to argue about priorities, but "Critical" means "things are badly
broken;" either it doesn't work AT ALL in the common case, or in edge cases it
can fail catastrophically (data loss or cascading failure).
This is not the case here; we have a problem with an edge case that we barely
support (jobs from outside the cluster) that does not affect more normal
setups. That's minor for the project as a whole.
> Empty rpc_address prevents running MapReduce job outside a cluster
> --
>
> Key: CASSANDRA-3811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3811
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.9, 0.8.10
> Environment: Debian Stable,
> Cassandra 0.8.9,
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03),
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>Reporter: Patrik Modesto
>Priority: Minor
>
> Setting rpc_address to empty to make Cassandra listen on all network
> intefaceces breaks running mapredude job from outside the cluster. The jobs
> wont even start, showing these messages:
> {noformat}
> 12/01/26 11:15:21 DEBUG hadoop.ColumnFamilyInputFormat: failed
> connect to endpoint 0.0.0.0
> java.io.IOException: unable to connect to server
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:389)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:224)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:73)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:193)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:178)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.thrift.transport.TTransportException:
> java.net.ConnectException: Connection refused
>at org.apache.thrift.transport.TSocket.open(TSocket.java:183)
>at
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:385)
>... 9 more
> Caused by: java.net.ConnectException: Connection refused
>at java.net.PlainSocketImpl.socketConnect(Native Method)
>at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
>at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:211)
>at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
>at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
>at java.net.Socket.connect(Socket.java:529)
>at org.apache.thrift.transport.TSocket.open(TSocket.java:178)
>... 11 more
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.io.IOException: failed connecting to all endpoints
> 10.0.18.129,10.0.18.99,10.0.18.98
>at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:156)
>... 19 more
> Caused by: java.io.IOException: failed connecting to all endpoints
> 10.0.18.129,10.0.18.99,10.0.18.98
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:241)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:73)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:193)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:178)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> {no
[jira] [Updated] (CASSANDRA-4022) Compaction of hints can get stuck in a loop
[
https://issues.apache.org/jira/browse/CASSANDRA-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4022:
--
Affects Version/s: 1.2
> Compaction of hints can get stuck in a loop
> ---
>
> Key: CASSANDRA-4022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4022
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2
>Reporter: Brandon Williams
>Assignee: Yuki Morishita
>Priority: Critical
> Fix For: 1.2
>
> Attachments: 4022.txt
>
>
> Not exactly sure how I caused this as I was working on something else in
> trunk, but:
> {noformat}
> INFO 17:41:35,682 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-339-Data.db')]
> INFO 17:41:36,430 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.912220MB/s. Time: 748ms.
> INFO 17:41:36,431 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db')]
> INFO 17:41:37,238 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.479976MB/s. Time: 807ms.
> INFO 17:41:37,239 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db')]
> INFO 17:41:38,163 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.786083MB/s. Time: 924ms.
> INFO 17:41:38,164 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db')]
> INFO 17:41:39,014 GC for ParNew: 274 ms for 1 collections, 541261288 used;
> max is 1024458752
> INFO 17:41:39,151 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.485132MB/s. Time: 986ms.
> INFO 17:41:39,151 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db')]
> INFO 17:41:40,016 GC for ParNew: 308 ms for 1 collections, 585582200 used;
> max is 1024458752
> INFO 17:41:40,200 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.223821MB/s. Time: 1,047ms.
> INFO 17:41:40,201 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db')]
> INFO 17:41:41,017 GC for ParNew: 252 ms for 1 collections, 617877904 used;
> max is 1024458752
> INFO 17:41:41,178 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.526449MB/s. Time: 977ms.
> INFO 17:41:41,179 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db')]
> INFO 17:41:41,885 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 6.263938MB/s. Time: 706ms.
> INFO 17:41:41,887 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db')]
> INFO 17:41:42,617 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 6.066311MB/s. Time: 729ms.
> INFO 17:41:42,618 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db')]
> INFO 17:41:43,376 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 5.834222MB/s. Time: 758ms.
> INFO 17:41:43,377 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db')]
> INFO 17:41:44,307 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-349-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 4.760323MB/s. Time: 929ms.
> INFO 17:41:44,308 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColu
[jira] [Commented] (CASSANDRA-4049) Add SSTable components required by new DSE CFS compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230218#comment-13230218 ] Piotr Kołaczkowski commented on CASSANDRA-4049: --- If it could be made pluggable, it would be great! > Add SSTable components required by new DSE CFS compaction strategy > -- > > Key: CASSANDRA-4049 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Piotr Kołaczkowski >Priority: Minor > Attachments: component_patch.diff > > > CFS compaction strategy coming up in the next DSE release needs to store some > important information in Tombstones.db and RemovedKeys.db files, one per > sstable. However, currently Cassandra issues warnings when these files are > found in the data directory. Additionally, when switched to > SizeTieredCompactionStrategy, the files are left in the data directory after > compaction. > The attached patch adds new components to the Component class so Cassandra > knows about those files. -- 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-4022) Compaction of hints can get stuck in a loop
[
https://issues.apache.org/jira/browse/CASSANDRA-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230238#comment-13230238
]
Yuki Morishita commented on CASSANDRA-4022:
---
I understand the situation, but isn't it covered by just checking key overlap?
If there is no overlap, then tombstones in target sstable are guaranteed to be
the only and the newest ones?
> Compaction of hints can get stuck in a loop
> ---
>
> Key: CASSANDRA-4022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4022
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2
>Reporter: Brandon Williams
>Assignee: Yuki Morishita
>Priority: Critical
> Fix For: 1.2
>
> Attachments: 4022.txt
>
>
> Not exactly sure how I caused this as I was working on something else in
> trunk, but:
> {noformat}
> INFO 17:41:35,682 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-339-Data.db')]
> INFO 17:41:36,430 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.912220MB/s. Time: 748ms.
> INFO 17:41:36,431 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db')]
> INFO 17:41:37,238 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.479976MB/s. Time: 807ms.
> INFO 17:41:37,239 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db')]
> INFO 17:41:38,163 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.786083MB/s. Time: 924ms.
> INFO 17:41:38,164 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db')]
> INFO 17:41:39,014 GC for ParNew: 274 ms for 1 collections, 541261288 used;
> max is 1024458752
> INFO 17:41:39,151 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.485132MB/s. Time: 986ms.
> INFO 17:41:39,151 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db')]
> INFO 17:41:40,016 GC for ParNew: 308 ms for 1 collections, 585582200 used;
> max is 1024458752
> INFO 17:41:40,200 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.223821MB/s. Time: 1,047ms.
> INFO 17:41:40,201 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db')]
> INFO 17:41:41,017 GC for ParNew: 252 ms for 1 collections, 617877904 used;
> max is 1024458752
> INFO 17:41:41,178 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.526449MB/s. Time: 977ms.
> INFO 17:41:41,179 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db')]
> INFO 17:41:41,885 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 6.263938MB/s. Time: 706ms.
> INFO 17:41:41,887 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db')]
> INFO 17:41:42,617 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 6.066311MB/s. Time: 729ms.
> INFO 17:41:42,618 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db')]
> INFO 17:41:43,376 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 5.834222MB/s. Time: 758ms.
> INFO 17:41:43,377 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db')]
> INFO 17:41:44,307 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system
[jira] [Commented] (CASSANDRA-4052) Add way to force the cassandra-cli to refresh it's schema
[
https://issues.apache.org/jira/browse/CASSANDRA-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230253#comment-13230253
]
Jonathan Ellis commented on CASSANDRA-4052:
---
Is schema querying so slow that we really need to cache it? Sounds to me like
we may have overengineered this.
> Add way to force the cassandra-cli to refresh it's schema
> -
>
> Key: CASSANDRA-4052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4052
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Affects Versions: 1.0.8
>Reporter: Tupshin Harper
>Priority: Minor
>
> By design, the cassandra-cli caches the schema and doesn't refresh it when
> various commands like "describe keyspaces" are run. This is reasonable, and
> it is easy enough to restart the cli if necessary. However, this does lead
> to confusion since a new user can reasonably assume that describe keyspaces
> will always show an accurate current represention of the ring. We should find
> a way to reduce the surprise (and lack of easy discoverability) of this
> behaviour.
> I propose any one of the following(#1 is probably the easiest and most
> likely):
> 1) Add a command (that would be documented in the cli's help) to explicitly
> refresh the schema ("schema refresh", "refresh schema", or anything similar).
> 2) Always force a refresh of the schema when performing at least the
> "describe keyspaces" command.
> 3) Add a flag to cassandra-cli to explicitly enable schema caching. If that
> flag is not passed, then schema caching will be disabled for that session.
> This suggestion assumes that for simple deployments (few CFs, etc), schema
> caching isn't very important to the performance of the cli.
--
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-3811) Empty rpc_address prevents running MapReduce job outside a cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230251#comment-13230251
]
Patrik Modesto commented on CASSANDRA-3811:
---
I don't agree that it's an edge case. Why do you force people to install a job
to a cluster node? It doesn't need to be there and there is no reason to force
people to do that. To run a Hadoop job, you just need to *point* it to a
Namenode and Jobtracker, thats all, no special placement required. It's the
same as with Hadoop Namenode+Datanodes or Jobtracker+Tasktrackers, does Hadoop
force you to have Jobtracker is on the same node as Tasktracker? No.
So instead of fixing the bug you declare that an edge case? Great!
You force us to stay with quite old version 0.8.7 that was the last working
version and start looking for alternatives. That's sad.
Patrik
> Empty rpc_address prevents running MapReduce job outside a cluster
> --
>
> Key: CASSANDRA-3811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3811
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.9, 0.8.10
> Environment: Debian Stable,
> Cassandra 0.8.9,
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03),
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>Reporter: Patrik Modesto
>Priority: Minor
>
> Setting rpc_address to empty to make Cassandra listen on all network
> intefaceces breaks running mapredude job from outside the cluster. The jobs
> wont even start, showing these messages:
> {noformat}
> 12/01/26 11:15:21 DEBUG hadoop.ColumnFamilyInputFormat: failed
> connect to endpoint 0.0.0.0
> java.io.IOException: unable to connect to server
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:389)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:224)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:73)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:193)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:178)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.thrift.transport.TTransportException:
> java.net.ConnectException: Connection refused
>at org.apache.thrift.transport.TSocket.open(TSocket.java:183)
>at
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:385)
>... 9 more
> Caused by: java.net.ConnectException: Connection refused
>at java.net.PlainSocketImpl.socketConnect(Native Method)
>at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
>at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:211)
>at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
>at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
>at java.net.Socket.connect(Socket.java:529)
>at org.apache.thrift.transport.TSocket.open(TSocket.java:178)
>... 11 more
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.io.IOException: failed connecting to all endpoints
> 10.0.18.129,10.0.18.99,10.0.18.98
>at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:156)
>... 19 more
> Caused by: java.io.IOException: failed connecting to all endpoints
> 10.0.18.129,10.0.18.99,10.0.18.98
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:241)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:73)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:193)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:178)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>
[jira] [Assigned] (CASSANDRA-4037) Move CfDef and KsDef validation to CFMetaData and KSMetaData
[ https://issues.apache.org/jira/browse/CASSANDRA-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-4037: --- Assignee: Sylvain Lebresne > Move CfDef and KsDef validation to CFMetaData and KSMetaData > > > Key: CASSANDRA-4037 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4037 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.1.1 > > > Following CASSANDRA-3792, CQL don't need to use thrift CfDef and KsDef. > However, those are still used in order to reuse ThriftValidation validation > methods. We should move that validation to CFM and KSM and remove the use of > those thrift structures by CQL. -- 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-4022) Compaction of hints can get stuck in a loop
[
https://issues.apache.org/jira/browse/CASSANDRA-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230284#comment-13230284
]
Jonathan Ellis commented on CASSANDRA-4022:
---
Right, if there's no overlap we're free to compact -- but I'm worried that with
SizeTiered compaction we'll have overlap in a lot of cases where we could still
compact if we looked closer.
> Compaction of hints can get stuck in a loop
> ---
>
> Key: CASSANDRA-4022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4022
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2
>Reporter: Brandon Williams
>Assignee: Yuki Morishita
>Priority: Critical
> Fix For: 1.2
>
> Attachments: 4022.txt
>
>
> Not exactly sure how I caused this as I was working on something else in
> trunk, but:
> {noformat}
> INFO 17:41:35,682 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-339-Data.db')]
> INFO 17:41:36,430 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.912220MB/s. Time: 748ms.
> INFO 17:41:36,431 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db')]
> INFO 17:41:37,238 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.479976MB/s. Time: 807ms.
> INFO 17:41:37,239 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db')]
> INFO 17:41:38,163 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.786083MB/s. Time: 924ms.
> INFO 17:41:38,164 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db')]
> INFO 17:41:39,014 GC for ParNew: 274 ms for 1 collections, 541261288 used;
> max is 1024458752
> INFO 17:41:39,151 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.485132MB/s. Time: 986ms.
> INFO 17:41:39,151 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db')]
> INFO 17:41:40,016 GC for ParNew: 308 ms for 1 collections, 585582200 used;
> max is 1024458752
> INFO 17:41:40,200 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.223821MB/s. Time: 1,047ms.
> INFO 17:41:40,201 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db')]
> INFO 17:41:41,017 GC for ParNew: 252 ms for 1 collections, 617877904 used;
> max is 1024458752
> INFO 17:41:41,178 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.526449MB/s. Time: 977ms.
> INFO 17:41:41,179 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db')]
> INFO 17:41:41,885 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 6.263938MB/s. Time: 706ms.
> INFO 17:41:41,887 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db')]
> INFO 17:41:42,617 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 6.066311MB/s. Time: 729ms.
> INFO 17:41:42,618 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db')]
> INFO 17:41:43,376 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 5.834222MB/s. Time: 758ms.
> INFO 17:41:43,377 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db')]
> INFO 17:41:44,307 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/syst
[jira] [Commented] (CASSANDRA-1311) Triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230382#comment-13230382 ] Brian ONeill commented on CASSANDRA-1311: - Jonathan, FYI -- we implemented both of your suggestions: a single CSCL per host, and switched to use a row per hour approach. We released those enhancements today in version 0.15.1. https://github.com/hmsonline/cassandra-triggers -brian > Triggers > > > Key: CASSANDRA-1311 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 > Project: Cassandra > Issue Type: New Feature >Reporter: Maxim Grinev > Fix For: 1.2 > > Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, > HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, > ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt, > trunk-984391-update2.txt > > > Asynchronous triggers is a basic mechanism to implement various use cases of > asynchronous execution of application code at database side. For example to > support indexes and materialized views, online analytics, push-based data > propagation. > Please find the motivation, triggers description and list of applications: > http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ > An example of using triggers for indexing: > http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ > Implementation details are attached. -- 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-3811) Empty rpc_address prevents running MapReduce job outside a cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230424#comment-13230424
]
Brandon Williams commented on CASSANDRA-3811:
-
It's an edge case because most people run hadoop colocated with cassandra.
Why? Because hadoop is about moving computation to data, not the other way
around, and without colocation this is exactly what you're doing.
That said, we understand this is a problem that needs to be addressed, but it
is hardly critical.
> Empty rpc_address prevents running MapReduce job outside a cluster
> --
>
> Key: CASSANDRA-3811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3811
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.9, 0.8.10
> Environment: Debian Stable,
> Cassandra 0.8.9,
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03),
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>Reporter: Patrik Modesto
>Priority: Minor
>
> Setting rpc_address to empty to make Cassandra listen on all network
> intefaceces breaks running mapredude job from outside the cluster. The jobs
> wont even start, showing these messages:
> {noformat}
> 12/01/26 11:15:21 DEBUG hadoop.ColumnFamilyInputFormat: failed
> connect to endpoint 0.0.0.0
> java.io.IOException: unable to connect to server
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:389)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:224)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:73)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:193)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:178)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.thrift.transport.TTransportException:
> java.net.ConnectException: Connection refused
>at org.apache.thrift.transport.TSocket.open(TSocket.java:183)
>at
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:385)
>... 9 more
> Caused by: java.net.ConnectException: Connection refused
>at java.net.PlainSocketImpl.socketConnect(Native Method)
>at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
>at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:211)
>at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
>at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
>at java.net.Socket.connect(Socket.java:529)
>at org.apache.thrift.transport.TSocket.open(TSocket.java:178)
>... 11 more
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.io.IOException: failed connecting to all endpoints
> 10.0.18.129,10.0.18.99,10.0.18.98
>at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:156)
>... 19 more
> Caused by: java.io.IOException: failed connecting to all endpoints
> 10.0.18.129,10.0.18.99,10.0.18.98
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:241)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:73)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:193)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:178)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> {noformat}
> Describe ring retunrs:
> {noformat}
> describe_ring returns:
> endpoints: 10.0.18.129,10.0.1
[jira] [Commented] (CASSANDRA-3229) Remove ability to disable dynamic snitch entirely
[ https://issues.apache.org/jira/browse/CASSANDRA-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230459#comment-13230459 ] david vanderfeesten commented on CASSANDRA-3229: we are experimenting with workload split between OLTP and OLAP workload using network topology strategy. The OLTP keyspace has replicas in both (virtual)DCs. OLTP would only be written to nodes in DC1 and only being read as OLAP input in DC2. While we don't know yet if this is the right approach, with dynamic snitch off (and read repair chance:0) in case no nodes are down we hope to avoid OLAP reads to show up in DC1. Without being able to switch off dynamic snitch - I am not sure how we are able to achieve workload split (to be proven if that gives a performance benefit). > Remove ability to disable dynamic snitch entirely > - > > Key: CASSANDRA-3229 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3229 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 1.0.0 > > Attachments: 3229.txt > > > We've moved dynamic snitch from "new, default to off" to "well tested, > default to true," and it's time now to take the next step to "there is no > reason to disable it, and keeping the option around just lets people shoot > their foot off." -- 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-3229) Remove ability to disable dynamic snitch entirely
[ https://issues.apache.org/jira/browse/CASSANDRA-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230465#comment-13230465 ] Brandon Williams commented on CASSANDRA-3229: - You can use the badness threshold from CASSANDRA-1519 > Remove ability to disable dynamic snitch entirely > - > > Key: CASSANDRA-3229 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3229 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 1.0.0 > > Attachments: 3229.txt > > > We've moved dynamic snitch from "new, default to off" to "well tested, > default to true," and it's time now to take the next step to "there is no > reason to disable it, and keeping the option around just lets people shoot > their foot off." -- 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-3811) Empty rpc_address prevents running MapReduce job outside a cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230511#comment-13230511
]
Patrik Modesto commented on CASSANDRA-3811:
---
I can see there is a misunderstanding about our Hadoop cluster setup. We use
quite common setup that's why I made this ticket "critical".
Our setup looks like this:
||node||Components||
|node1|Datanode, Tasktracker, Cassandra|
|node2|Datanode, Tasktracker, Cassandra|
|node3|Datanode, Tasktracker, Cassandra|
|node4|Datanode, Tasktracker, Cassandra|
|node5|Namenode, Jobtracker, our mapreduce jobs|
All with rpc_endpoints: 0.0.0.0
I'd say, this is quite reasonable clean setup.
The problem is, that with this setup, we can't use Cassandra 0.8.8 and above
because of the problem I've described earlier today. With this exact setup our
jobs just fail to start because there is no Cassandra on node5. Moving our jobs
to, for example, node1 allows them to run but CFIF gets wrong split sizes (it
asks just 0.0.0.0 for all of the key ranges) and there are tasks that shows
thousands of percent of progress. Please carefuly read my earlier post about
describe_splits().
We use rpc_endpoint: 0.0.0.0 because we have other non-Hadoop components that
connect to Cassandra for data and they are on different intefaces.
I hope I've explained the setup so you can understand that from my point of
view it is critical. With Cassandra 0.8.8 and above our Hadoop jobs eihter fail
to start or fail to complete the work.
We have quite wide rows (even tens of thousands columns) and write heavy
cluster so we use batch.size=512 and split.size=8196 for our Hadoop jobs. That
may or may not be connected to the wrong key ranges.
Regards,
Patrik
> Empty rpc_address prevents running MapReduce job outside a cluster
> --
>
> Key: CASSANDRA-3811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3811
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.9, 0.8.10
> Environment: Debian Stable,
> Cassandra 0.8.9,
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03),
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>Reporter: Patrik Modesto
>Priority: Minor
>
> Setting rpc_address to empty to make Cassandra listen on all network
> intefaceces breaks running mapredude job from outside the cluster. The jobs
> wont even start, showing these messages:
> {noformat}
> 12/01/26 11:15:21 DEBUG hadoop.ColumnFamilyInputFormat: failed
> connect to endpoint 0.0.0.0
> java.io.IOException: unable to connect to server
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:389)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:224)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:73)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:193)
>at
> org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:178)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.thrift.transport.TTransportException:
> java.net.ConnectException: Connection refused
>at org.apache.thrift.transport.TSocket.open(TSocket.java:183)
>at
> org.apache.thrift.transport.TFramedTransport.open(TFramedTransport.java:81)
>at
> org.apache.cassandra.hadoop.ConfigHelper.createConnection(ConfigHelper.java:385)
>... 9 more
> Caused by: java.net.ConnectException: Connection refused
>at java.net.PlainSocketImpl.socketConnect(Native Method)
>at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
>at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:211)
>at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
>at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
>at java.net.Socket.connect(Socket.java:529)
>at org.apache.thrift.transport.TSocket.open(TSocket.java:178)
>... 11 more
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.io.IOException: failed connecting to all endpoints
> 10.0.18.129,10.0.18.99,10.0.18.98
>at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>at java.util.concurrent.FutureTask.get
[jira] [Commented] (CASSANDRA-4017) Unify migrations
[
https://issues.apache.org/jira/browse/CASSANDRA-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230552#comment-13230552
]
Jonathan Ellis commented on CASSANDRA-4017:
---
bq. More precisely, SchemaLoader was not using the migration path, but only
loading the schema in-memory. Because the patch removes the local special case,
this was breaking DefsTest.
Why can't we still call {{Schema.load(KSMetaData)}} directly?
> Unify migrations
>
>
> Key: CASSANDRA-4017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4017
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.1.0
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
>
> Now that we can send a schema as a RowMutation, there's no need to keep
> separate add/drop/update migration classes around. Let's just send the
> schema to our counterparts and let them figure out what changed. Currently
> we have "figure out what changed" code to both generate migrations on the
> sender, and for application on the target, which adds complexity.
--
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-4054) SStableImport and SStableExport does not serialize row level deletion
[
https://issues.apache.org/jira/browse/CASSANDRA-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230563#comment-13230563
]
Jonathan Ellis commented on CASSANDRA-4054:
---
I think we could fix that by splitting the row into {'key': key, 'metadata':
{...}, 'columns': [...]} instead of the current {key: [...]}.
Do you want to take a stab at that, Zhu?
> SStableImport and SStableExport does not serialize row level deletion
> -
>
> Key: CASSANDRA-4054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4054
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.0.8
>Reporter: Zhu Han
>
> SSTableImport and SSTableExport does not serialize/de-serialize the row-level
> deletion info to/from the json file. This brings back the deleted data after
> restore from the json file.
--
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-4054) SStableImport and SStableExport does not serialize row level deletion
[ https://issues.apache.org/jira/browse/CASSANDRA-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4054: -- Affects Version/s: (was: 1.0.8) 0.5 Fix Version/s: 1.1.0 Changing fix version to 1.1.0 since this would be backwards-incompatible. If we miss 1.1.0 we can push to 1.2. > SStableImport and SStableExport does not serialize row level deletion > - > > Key: CASSANDRA-4054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4054 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 0.5 >Reporter: Zhu Han > Fix For: 1.1.0 > > > SSTableImport and SSTableExport does not serialize/de-serialize the row-level > deletion info to/from the json file. This brings back the deleted data after > restore from the json file. -- 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-4055) Hector RetryService drop host
[
https://issues.apache.org/jira/browse/CASSANDRA-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Wang updated CASSANDRA-4055:
--
Environment:
This bug is in Hector code.
If there is exception in addCassandraHost() before adding host to hostPools,
since addCassandraHost does not throw exception, the host will be removed from
downedHostQueue, and the host will be gone forever.
if(downedHostQueue.contains(cassandraHost) &&
verifyConnection(cassandraHost)) {
connectionManager.addCassandraHost(cassandraHost);
downedHostQueue.remove(cassandraHost);
return;
}
was:
If there is exception in addCassandraHost() before adding host to hostPools,
since addCassandraHost does not throw exception, the host will be removed from
downedHostQueue, and the host will be gone forever.
if(downedHostQueue.contains(cassandraHost) &&
verifyConnection(cassandraHost)) {
connectionManager.addCassandraHost(cassandraHost);
downedHostQueue.remove(cassandraHost);
return;
}
> Hector RetryService drop host
> -
>
> Key: CASSANDRA-4055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4055
> Project: Cassandra
> Issue Type: Bug
> Components: Drivers
> Environment: This bug is in Hector code.
> If there is exception in addCassandraHost() before adding host to hostPools,
> since addCassandraHost does not throw exception, the host will be removed
> from downedHostQueue, and the host will be gone forever.
> if(downedHostQueue.contains(cassandraHost) &&
> verifyConnection(cassandraHost)) {
> connectionManager.addCassandraHost(cassandraHost);
> downedHostQueue.remove(cassandraHost);
> return;
> }
>Reporter: Danny Wang
>Priority: Critical
>
--
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-4055) Hector RetryService drop host
Hector RetryService drop host
-
Key: CASSANDRA-4055
URL: https://issues.apache.org/jira/browse/CASSANDRA-4055
Project: Cassandra
Issue Type: Bug
Components: Drivers
Environment: If there is exception in addCassandraHost() before adding
host to hostPools, since addCassandraHost does not throw exception, the host
will be removed from downedHostQueue, and the host will be gone forever.
if(downedHostQueue.contains(cassandraHost) &&
verifyConnection(cassandraHost)) {
connectionManager.addCassandraHost(cassandraHost);
downedHostQueue.remove(cassandraHost);
return;
}
Reporter: Danny Wang
Priority: Critical
--
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-4055) Hector RetryService drop host
[
https://issues.apache.org/jira/browse/CASSANDRA-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4055.
---
Resolution: Fixed
The Hector client is maintained at https://github.com/rantav/hector.
> Hector RetryService drop host
> -
>
> Key: CASSANDRA-4055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4055
> Project: Cassandra
> Issue Type: Bug
> Components: Drivers
> Environment: This bug is in Hector code.
> If there is exception in addCassandraHost() before adding host to hostPools,
> since addCassandraHost does not throw exception, the host will be removed
> from downedHostQueue, and the host will be gone forever.
> if(downedHostQueue.contains(cassandraHost) &&
> verifyConnection(cassandraHost)) {
> connectionManager.addCassandraHost(cassandraHost);
> downedHostQueue.remove(cassandraHost);
> return;
> }
>Reporter: Danny Wang
>Priority: Critical
>
--
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-4022) Compaction of hints can get stuck in a loop
[
https://issues.apache.org/jira/browse/CASSANDRA-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230570#comment-13230570
]
Jonathan Ellis commented on CASSANDRA-4022:
---
Suppose for example we have two sstables:
SSTable A has a tombstone for row K, column foo, at time=100.
SSTable B has data for row K, column bar, at time=200.
We would like to allow A to be compacted by itself to get rid of tombstones,
since even though B has overlapping data it is new enough that removing the TS
is safe.
> Compaction of hints can get stuck in a loop
> ---
>
> Key: CASSANDRA-4022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4022
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2
>Reporter: Brandon Williams
>Assignee: Yuki Morishita
>Priority: Critical
> Fix For: 1.2
>
> Attachments: 4022.txt
>
>
> Not exactly sure how I caused this as I was working on something else in
> trunk, but:
> {noformat}
> INFO 17:41:35,682 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-339-Data.db')]
> INFO 17:41:36,430 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.912220MB/s. Time: 748ms.
> INFO 17:41:36,431 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db')]
> INFO 17:41:37,238 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 5.479976MB/s. Time: 807ms.
> INFO 17:41:37,239 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db')]
> INFO 17:41:38,163 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.786083MB/s. Time: 924ms.
> INFO 17:41:38,164 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db')]
> INFO 17:41:39,014 GC for ParNew: 274 ms for 1 collections, 541261288 used;
> max is 1024458752
> INFO 17:41:39,151 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.485132MB/s. Time: 986ms.
> INFO 17:41:39,151 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db')]
> INFO 17:41:40,016 GC for ParNew: 308 ms for 1 collections, 585582200 used;
> max is 1024458752
> INFO 17:41:40,200 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.223821MB/s. Time: 1,047ms.
> INFO 17:41:40,201 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db')]
> INFO 17:41:41,017 GC for ParNew: 252 ms for 1 collections, 617877904 used;
> max is 1024458752
> INFO 17:41:41,178 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 4.526449MB/s. Time: 977ms.
> INFO 17:41:41,179 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db')]
> INFO 17:41:41,885 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes
> for 1 keys at 6.263938MB/s. Time: 706ms.
> INFO 17:41:41,887 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db')]
> INFO 17:41:42,617 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 6.066311MB/s. Time: 729ms.
> INFO 17:41:42,618 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db')]
> INFO 17:41:43,376 Compacted to
> [/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db,].
> 4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at
> 5.834222MB/s. Time: 758ms.
> INFO 17:41:43,377 Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFam
[jira] [Commented] (CASSANDRA-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230575#comment-13230575
]
Jonathan Ellis commented on CASSANDRA-3954:
---
What if we just created the index CFMetadata with caching=NONE instead of
adding a special flag?
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Any ideas why they`ve appeared?
--
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-4017) Unify migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230578#comment-13230578 ] Sylvain Lebresne commented on CASSANDRA-4017: - The reason is that when we compute for a migration what has changed, we do that based on the on-disk schema. So calling only Schema.load() means that the on-disk schema is empty and thus some test of DefsTast that try to modify a CF are not recognized as updates but as add and fail (since the cf exists in memory). Now, an option could be to compute 'what has changed' based on the in-memory schema. However, even if we do that (I honestly don't have much argument for doing it or not doing it, but pleasing the unit tests seems like the worst possible reason to do it), I think it is still nice to use the normal path (i.e. not only load in memory with Schema.load()) to load the test schema because that means we exercise that code which is a good thing and make our unit tests less 'fake'. I'll note for instance that the patch fix a small bug in the current code that serialize/deserialize schema that was caught once I started writing the test schema on-disk but wasn't previously. > Unify migrations > > > Key: CASSANDRA-4017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4017 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Fix For: 1.1.0 > > > Now that we can send a schema as a RowMutation, there's no need to keep > separate add/drop/update migration classes around. Let's just send the > schema to our counterparts and let them figure out what changed. Currently > we have "figure out what changed" code to both generate migrations on the > sender, and for application on the target, which adds complexity. -- 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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3954:
---
Attachment: CASSANDRA-3954-v2.patch
That is a good idea, v2 implements that.
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954-v2.patch, CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Any ideas why they`ve appeared?
--
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-4017) Unify migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230596#comment-13230596 ] Jonathan Ellis commented on CASSANDRA-4017: --- Maybe we can tackle it from this direction, then: bq. now that means that SchemaLoader needs to be merged with CleanupHelper (otherwise, since the cleanup was happening with the schema loading, the loading was conflicting with the schema of the previous test) What I did over on CASSANDRA-3967 v2 was to make CleanupHelper manually call into SchemaLoader explicitly rather than leaving it up to the BeforeClass annotations as to which runs first. We could do something similar as a one-off for MoveTest: instead of extending CleanupHelper and giving up that control, it could call into it manually once it's set the partitioner the way it wants. > Unify migrations > > > Key: CASSANDRA-4017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4017 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Fix For: 1.1.0 > > > Now that we can send a schema as a RowMutation, there's no need to keep > separate add/drop/update migration classes around. Let's just send the > schema to our counterparts and let them figure out what changed. Currently > we have "figure out what changed" code to both generate migrations on the > sender, and for application on the target, which adds complexity. -- 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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230597#comment-13230597
]
Jonathan Ellis commented on CASSANDRA-3954:
---
better, but we should actually load key cache only for KEYS_ONLY or ALL, rather
than !NONE (which would include ROWS ONLY).
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954-v2.patch, CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Any ideas why they`ve appeared?
--
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-4048) SSTableLoader meets problem during the apply of the schema update
[ https://issues.apache.org/jira/browse/CASSANDRA-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230600#comment-13230600 ] Jonathan Ellis commented on CASSANDRA-4048: --- Unless you have a 1.0-specific fix I'm inclined to say "don't drop columnfamilies during bulk load," since we've already rewritten this for 1.1. > SSTableLoader meets problem during the apply of the schema update > --- > > Key: CASSANDRA-4048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4048 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.0.8 >Reporter: Zhu Han >Priority: Minor > > SSTableLoader tries to apply the "drop column family" meta data update, and > meets below problem. Seems like the column family > is dropped multiple times? > user@luzhou:/data/apache-cassandra-1.0.8$ bin/sstableloader -i hostA,hostB > /tmp/out/store/ > Starting client (and waiting 30 seconds for gossip) ... > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 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) > ERROR 18:35:51,423 Error in ThreadPoolExecutor > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 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) > ERROR 18:35:51,595 Error in ThreadPoolExecutor > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 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) -- 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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3954:
---
Attachment: (was: CASSANDRA-3954-v2.patch)
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Any ideas why they`ve appeared?
--
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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3954:
---
Attachment: CASSANDRA-3954-v2.patch
updated v2 which skips key cache read if caching is NONE or ROWS_ONLY.
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954-v2.patch, CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Any ideas why they`ve appeared?
--
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-2975) Upgrade MurmurHash to version 3
[ https://issues.apache.org/jira/browse/CASSANDRA-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2975: --- Reviewer: xedin (was: stuhood) > Upgrade MurmurHash to version 3 > --- > > Key: CASSANDRA-2975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2975 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brian Lindauer >Assignee: Vijay >Priority: Trivial > Labels: lhf > Fix For: 1.2 > > Attachments: 0001-CASSANDRA-2975.patch, > 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch, > 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch, > Murmur3Benchmark.java > > > MurmurHash version 3 was finalized on June 3. It provides an enormous speedup > and increased robustness over version 2, which is implemented in Cassandra. > Information here: > http://code.google.com/p/smhasher/ > The reference implementation is here: > http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp?spec=svn136&r=136 > I have already done the work to port the (public domain) reference > implementation to Java in the MurmurHash class and updated the BloomFilter > class to use the new implementation: > https://github.com/lindauer/cassandra/commit/cea6068a4a3e5d7d9509335394f9ef3350d37e93 > Apart from the faster hash time, the new version only requires one call to > hash() rather than 2, since it returns 128 bits of hash instead of 64. -- 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-2975) Upgrade MurmurHash to version 3
[ https://issues.apache.org/jira/browse/CASSANDRA-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230667#comment-13230667 ] Pavel Yaskevich commented on CASSANDRA-2975: Vijay, can you please rebase? > Upgrade MurmurHash to version 3 > --- > > Key: CASSANDRA-2975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2975 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brian Lindauer >Assignee: Vijay >Priority: Trivial > Labels: lhf > Fix For: 1.2 > > Attachments: 0001-CASSANDRA-2975.patch, > 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch, > 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch, > Murmur3Benchmark.java > > > MurmurHash version 3 was finalized on June 3. It provides an enormous speedup > and increased robustness over version 2, which is implemented in Cassandra. > Information here: > http://code.google.com/p/smhasher/ > The reference implementation is here: > http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp?spec=svn136&r=136 > I have already done the work to port the (public domain) reference > implementation to Java in the MurmurHash class and updated the BloomFilter > class to use the new implementation: > https://github.com/lindauer/cassandra/commit/cea6068a4a3e5d7d9509335394f9ef3350d37e93 > Apart from the faster hash time, the new version only requires one call to > hash() rather than 2, since it returns 128 bits of hash instead of 64. -- 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-4056) [patch] guard against npe due to null sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4056: Attachment: npe_guard.diff against trunk > [patch] guard against npe due to null sstable > - > > Key: CASSANDRA-4056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4056 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Dave Brosius >Priority: Trivial > Attachments: npe_guard.diff > > > SSTableIdentityIterator ctor can be called from sibling ctor with a null > sstable. So catch block's markSuspect should be npe guarded. -- 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-4056) [patch] guard against npe due to null sstable
[patch] guard against npe due to null sstable - Key: CASSANDRA-4056 URL: https://issues.apache.org/jira/browse/CASSANDRA-4056 Project: Cassandra Issue Type: Bug Components: Core Reporter: Dave Brosius Priority: Trivial Attachments: npe_guard.diff SSTableIdentityIterator ctor can be called from sibling ctor with a null sstable. So catch block's markSuspect should be npe guarded. -- 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-4057) [patch] use double math for double results
[ https://issues.apache.org/jira/browse/CASSANDRA-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4057: Attachment: hist_math_use_double.diff against trunk > [patch] use double math for double results > -- > > Key: CASSANDRA-4057 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4057 > Project: Cassandra > Issue Type: Improvement >Reporter: Dave Brosius >Priority: Trivial > Attachments: hist_math_use_double.diff > > > code uses long math and assigns to double... Just use double math. -- 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-4057) [patch] use double math for double results
[patch] use double math for double results -- Key: CASSANDRA-4057 URL: https://issues.apache.org/jira/browse/CASSANDRA-4057 Project: Cassandra Issue Type: Improvement Reporter: Dave Brosius Priority: Trivial Attachments: hist_math_use_double.diff code uses long math and assigns to double... Just use double math. -- 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-4048) SSTableLoader meets problem during the apply of the schema update
[ https://issues.apache.org/jira/browse/CASSANDRA-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230829#comment-13230829 ] Zhu Han commented on CASSANDRA-4048: OK. This is on testing cluster. I tried "drop cfs" several times before the test. Whatever, it does not matter for the bulk load result... > SSTableLoader meets problem during the apply of the schema update > --- > > Key: CASSANDRA-4048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4048 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.0.8 >Reporter: Zhu Han >Priority: Minor > > SSTableLoader tries to apply the "drop column family" meta data update, and > meets below problem. Seems like the column family > is dropped multiple times? > user@luzhou:/data/apache-cassandra-1.0.8$ bin/sstableloader -i hostA,hostB > /tmp/out/store/ > Starting client (and waiting 30 seconds for gossip) ... > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 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) > ERROR 18:35:51,423 Error in ThreadPoolExecutor > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 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) > ERROR 18:35:51,595 Error in ThreadPoolExecutor > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 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) -- 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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230873#comment-13230873
]
Jonathan Ellis commented on CASSANDRA-3954:
---
+1
nit: it's preferred to use == with enums
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954-v2.patch, CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Any ideas why they`ve appeared?
--
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-2975) Upgrade MurmurHash to version 3
[ https://issues.apache.org/jira/browse/CASSANDRA-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2975: - Attachment: 0001-CASSANDRA-2975-v2.patch Done! unit tests and functional tests works fine. > Upgrade MurmurHash to version 3 > --- > > Key: CASSANDRA-2975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2975 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brian Lindauer >Assignee: Vijay >Priority: Trivial > Labels: lhf > Fix For: 1.2 > > Attachments: 0001-CASSANDRA-2975-v2.patch, 0001-CASSANDRA-2975.patch, > 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch, > 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch, > Murmur3Benchmark.java > > > MurmurHash version 3 was finalized on June 3. It provides an enormous speedup > and increased robustness over version 2, which is implemented in Cassandra. > Information here: > http://code.google.com/p/smhasher/ > The reference implementation is here: > http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp?spec=svn136&r=136 > I have already done the work to port the (public domain) reference > implementation to Java in the MurmurHash class and updated the BloomFilter > class to use the new implementation: > https://github.com/lindauer/cassandra/commit/cea6068a4a3e5d7d9509335394f9ef3350d37e93 > Apart from the faster hash time, the new version only requires one call to > hash() rather than 2, since it returns 128 bits of hash instead of 64. -- 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
