[jira] [Resolved] (CASSANDRA-4168) Setup section of tools/stress/README.txt needs update
[ https://issues.apache.org/jira/browse/CASSANDRA-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4168. - Resolution: Fixed Done in 2d029e86d99e74c8d0eeb321d821daeaa27b1b52 Setup section of tools/stress/README.txt needs update --- Key: CASSANDRA-4168 URL: https://issues.apache.org/jira/browse/CASSANDRA-4168 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.1 Reporter: Tyler Patterson Priority: Minor Labels: stress The README.txt file states Run `ant` from the Cassandra source directory, then Run `ant` from the contrib/stress directory. The file needs to reflect the changes in the way stress is built. -- 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-2246) Enable Pig to use indexed data as described in CASSANDRA-2245
[ https://issues.apache.org/jira/browse/CASSANDRA-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-2246. - Resolution: Not A Problem Fix Version/s: (was: 1.1.1) 1.1.0 CASSANDRA-2878 solved this by allowing you to pass a list a of IndexExpressions to setInputRange. Enable Pig to use indexed data as described in CASSANDRA-2245 - Key: CASSANDRA-2246 URL: https://issues.apache.org/jira/browse/CASSANDRA-2246 Project: Cassandra Issue Type: Improvement Components: Contrib Affects Versions: 0.7.2 Reporter: Matt Kennedy Assignee: Brandon Williams Priority: Minor Labels: hadoop Fix For: 1.1.0 Original Estimate: 24h Remaining Estimate: 24h in contrib/pig, add query parameters to CassandraStorage keyspace/column family string to specify column search predicates. For example: rows = LOAD 'cassandra://mykeyspace/mycolumnfamily?country=UK' using CassandraStorage(); This depends on CASSANDRA-1600 -- 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-4045) BOF fails when some nodes are down
[ https://issues.apache.org/jira/browse/CASSANDRA-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4045. - Resolution: Fixed Committed. BOF fails when some nodes are down -- Key: CASSANDRA-4045 URL: https://issues.apache.org/jira/browse/CASSANDRA-4045 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Labels: hadoop Fix For: 1.1.1 Attachments: 4045.txt As the summary says, we should allow jobs to complete when some targets are unavailable. -- 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-3909) Pig should handle wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3909. - Resolution: Fixed Committed. Pig should handle wide rows --- Key: CASSANDRA-3909 URL: https://issues.apache.org/jira/browse/CASSANDRA-3909 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.1 Attachments: 3909.txt Pig should be able to use the wide row support in CFIF. -- 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-4143) HH delivery should not be attempted when target node is down
[
https://issues.apache.org/jira/browse/CASSANDRA-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-4143.
-
Resolution: Not A Problem
bq. INFO [HintedHandoff:1] 2012-04-12 03:19:54,924 HintedHandOffManager.java
(line 292) Endpoint /64.6.104.18 died before hint delivery, aborting
This is where it checked the FD and gave up.
{noformat}
if (!FailureDetector.instance.isAlive(endpoint))
{
logger.info(Endpoint {} died before hint delivery, aborting,
endpoint);
return;
}
{noformat}
HH delivery should not be attempted when target node is down
Key: CASSANDRA-4143
URL: https://issues.apache.org/jira/browse/CASSANDRA-4143
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.9
Reporter: Radim Kolar
Priority: Minor
Look at this log fragment. Cassandra tries to do HH delivery every 10 minutes
even if host is marked down by gossip.
INFO [GossipTasks:1] 2012-04-12 03:01:55,040 Gossiper.java (line 818)
InetAddress /64.6.104.18 is now dead.
INFO [MemoryMeter:1] 2012-04-12 03:04:12,503 Memtable.java (line 186)
CFS(Keyspace='system', ColumnFamily='HintsColumnFamily') liveRatio is
1.7635719581514129 (just-counted was 1.7635719581514129). calculation took
224ms for 226 columns
WARN [MemoryMeter:1] 2012-04-12 03:08:48,995 Memtable.java (line 176)
setting live ratio to minimum of 1.0 instead of 0.8717337990312605
INFO [MemoryMeter:1] 2012-04-12 03:08:48,995 Memtable.java (line 186)
CFS(Keyspace='system', ColumnFamily='HintsColumnFamily') liveRatio is
1.7635719581514129 (just-counted was 1.0). calculation took 8ms for 738
columns
INFO [HintedHandoff:1] 2012-04-12 03:09:31,269 HintedHandOffManager.java
(line 292) Endpoint /64.6.104.18 died before hint delivery, aborting
INFO [MemoryMeter:1] 2012-04-12 03:16:58,007 Memtable.java (line 186)
CFS(Keyspace='system', ColumnFamily='HintsColumnFamily') liveRatio is
1.7635719581514129 (just-counted was 1.0055416029080733). calculation took
19ms for 1762 columns
INFO [HintedHandoff:1] 2012-04-12 03:19:54,924 HintedHandOffManager.java
(line 292) Endpoint /64.6.104.18 died before hint delivery, aborting
--
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-4094) MS.getCommandPendingTasks returns a double
[ https://issues.apache.org/jira/browse/CASSANDRA-4094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4094. - Resolution: Not A Problem Not sure what I was looking at when I made this. MS.getCommandPendingTasks returns a double -- Key: CASSANDRA-4094 URL: https://issues.apache.org/jira/browse/CASSANDRA-4094 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Priority: Trivial Labels: lhf Fix For: 1.2 This makes no sense, since you can't have a partial task. -- 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-4086) decom should shut thrift down
[ https://issues.apache.org/jira/browse/CASSANDRA-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4086. - Resolution: Fixed Reviewer: jbellis Committed. decom should shut thrift down - Key: CASSANDRA-4086 URL: https://issues.apache.org/jira/browse/CASSANDRA-4086 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Fix For: 1.0.9, 1.1.0 Attachments: 4086.txt If you decom a node an then try to use it, you get nothing but timeouts. Instead let's just kill thrift so intelligent clients can move along. -- 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-4067) Report lifetime compaction throughput
[ https://issues.apache.org/jira/browse/CASSANDRA-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4067. - Resolution: Fixed Committed. Report lifetime compaction throughput - Key: CASSANDRA-4067 URL: https://issues.apache.org/jira/browse/CASSANDRA-4067 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Trivial Labels: compaction Fix For: 1.1.0 Attachments: 0001-Track-and-expose-lifetime-bytes-compacted.txt, 0002-Track-and-expose-total-compactions.txt Would be useful to be able to monitor total compaction throughput without having to poll frequently enough to make sure we get every CompactionInfo object. -- 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-4020) System time suddenly changed made gossip working abnormally
[ https://issues.apache.org/jira/browse/CASSANDRA-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4020. - Resolution: Duplicate Looks like the same issues as CASSANDRA-4066 System time suddenly changed made gossip working abnormally - Key: CASSANDRA-4020 URL: https://issues.apache.org/jira/browse/CASSANDRA-4020 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.6 Reporter: MaHaiyang I hava four cassandra node (A,B,C,D) . I changed node A's system time to one hour ahead and change the time to normal after serval seconds.Then I use nodetool's ring command at node B , node B look node A is down . It's the same thing on node C and D . But node A look itself is UP by ring command . -- 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-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4066. - Resolution: Won't Fix Cassandra cluster stops responding on time change (scheduling not using monotonic time?) - Key: CASSANDRA-4066 URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 Project: Cassandra Issue Type: Bug Components: Core Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 Reporter: David Daeschler Assignee: Brandon Williams Priority: Minor Labels: gossip Fix For: 1.1.1 The server installation I set up did not have ntpd installed in the base installation. When I noticed that the clocks were skewing I installed ntp and set the date on all the servers in the cluster. A short time later, I started getting UnavailableExceptions on the clients. Also, one sever seemed to be unaffected by the time change. That server happened to have it's time pushed forward, not backwards like the other 3 in the cluster. This leads me to believe something is running on a timer/schedule that is not monotonic. I'm posting this as a bug, but I suppose it might just be part of the communication protocols etc for the cluster and part of the design. But I think the devs should be aware of what I saw. Otherwise, thank you for a fantastic product. Even after restarting 75% of the cluster things seem to have recovered nicely. -- 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-4058) Debian package does not create /var/lib/cassandra/data
[ https://issues.apache.org/jira/browse/CASSANDRA-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4058. - Resolution: Not A Problem Cassandra itself will create this directory if it doesn't exist. You likely have a problem in a directory higher up in the hierarchy making it inaccessible. Debian package does not create /var/lib/cassandra/data -- Key: CASSANDRA-4058 URL: https://issues.apache.org/jira/browse/CASSANDRA-4058 Project: Cassandra Issue Type: Bug Components: Packaging Environment: Ubuntu 11.10 Reporter: Jacob Fenwick I installed Cassandra using the Debian packages as described here: http://wiki.apache.org/cassandra/DebianPackaging When trying to start Cassandra using /etc/init.d/cassandra start I get this error: java.io.IOError: java.io.IOException: unable to mkdirs /var/lib/cassandra/data The directory /var/lib/cassandra exists, but the directory /var/lib/cassandra/data does not. I would assume the data directory should have been created with the correct permissions, but it was not. However, I tried creating /var/lib/cassandra/data and setting it the permissions to 666 and setting the user/group to cassandra/cassandra, and now I get this error: java.lang.AssertionError: Directory /var/lib/cassandra/data is not accessible. So what could possibly be the problem here? -- 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-4058) Debian package does not create /var/lib/cassandra/data
[ https://issues.apache.org/jira/browse/CASSANDRA-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4058. - Resolution: Not A Problem I don't think papering over a problem a user has caused is a good idea, since they are possibly doing something they don't intend to. Debian package does not create /var/lib/cassandra/data -- Key: CASSANDRA-4058 URL: https://issues.apache.org/jira/browse/CASSANDRA-4058 Project: Cassandra Issue Type: Bug Components: Packaging Environment: Ubuntu 11.10 Reporter: Jacob Fenwick I installed Cassandra using the Debian packages as described here: http://wiki.apache.org/cassandra/DebianPackaging When trying to start Cassandra using /etc/init.d/cassandra start I get this error: java.io.IOError: java.io.IOException: unable to mkdirs /var/lib/cassandra/data The directory /var/lib/cassandra exists, but the directory /var/lib/cassandra/data does not. I would assume the data directory should have been created with the correct permissions, but it was not. However, I tried creating /var/lib/cassandra/data and setting it the permissions to 666 and setting the user/group to cassandra/cassandra, and now I get this error: java.lang.AssertionError: Directory /var/lib/cassandra/data is not accessible. So what could possibly be the problem here? -- 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-3910) make phi_convict_threshold Float
[ https://issues.apache.org/jira/browse/CASSANDRA-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3910. - Resolution: Fixed Fix Version/s: 1.2 Committed everything except the yaml change, since the current example was correct. make phi_convict_threshold Float Key: CASSANDRA-3910 URL: https://issues.apache.org/jira/browse/CASSANDRA-3910 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.7 Reporter: Radim Kolar Assignee: Harish Doddi Fix For: 1.2 Attachments: CASSANDRA-3910-trunk.txt I would like to have phi_convict_threshold floating point number instead of integer. Value 8 is too low for me and value 9 is too high. With converting to floating point, it can be better fine tuned. -- 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-3120) Move RING_DELAY and operations that use it to Gossiper
[ https://issues.apache.org/jira/browse/CASSANDRA-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3120. - Resolution: Not A Problem Closing as this was better solved by CASSANDRA-3600 Move RING_DELAY and operations that use it to Gossiper -- Key: CASSANDRA-3120 URL: https://issues.apache.org/jira/browse/CASSANDRA-3120 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor RING_DELAY more appropriately belongs to Gossiper, rather than SS. SS has a history of not respecting it correctly (such as CASSANDRA-2072) so we should confine it to the Gossiper, and have SS call methods on the Gossiper where needed. Currently we're allowing delays to be passed in some instances to the Gossiper in order to cheat RING_DELAY for tests so we don't have to wait the full delay. Instead we can use a special constructor on the Gossiper that is only used in tests. -- 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-3986) Cli shouldn't call FBU.getBroadcastAddress needlessly
[
https://issues.apache.org/jira/browse/CASSANDRA-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3986.
-
Resolution: Fixed
Reviewer: dbros...@apache.org
Committed. Probably only causes a problem on windows because the cli doesn't
have the yaml in the classpath from the bat file.
Cli shouldn't call FBU.getBroadcastAddress needlessly
-
Key: CASSANDRA-3986
URL: https://issues.apache.org/jira/browse/CASSANDRA-3986
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.8
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.9, 1.1.0
Attachments: 3986.txt
The cli is calling this, which causes yaml to be loaded, but the broadcast
address isn't needed.
{code}
// adding default data center from SimpleSnitch
if (currentStrategyOptions == null ||
currentStrategyOptions.isEmpty())
{
SimpleSnitch snitch = new SimpleSnitch();
MapString, String options = new HashMapString, String();
options.put(snitch.getDatacenter(FBUtilities.getBroadcastAddress()), 1);
ksDef.setStrategy_options(options);
}
{code}
because SimpleSnitch always returns 'datacenter1'
--
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-3684) Composite Column Support for PIG
[ https://issues.apache.org/jira/browse/CASSANDRA-3684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3684. - Resolution: Fixed Committed, thanks! Composite Column Support for PIG Key: CASSANDRA-3684 URL: https://issues.apache.org/jira/browse/CASSANDRA-3684 Project: Cassandra Issue Type: Bug Reporter: Benjamin Coverston Assignee: Janne Jalkanen Fix For: 1.0.9, 1.1.0 Attachments: 3684-jalkanen-test-v2.txt, 3684-jalkanen-test.txt, 3684-jalkanen.txt It appears that some changes need to be made to support CompositeColumns. Right now if you try to load and use a column family that utilizes composite columns you get the following exception[1]. It appears to me that we need to modify the storage handler for Pig to support this scenario. [1] Backend error message - java.lang.RuntimeException: Unexpected data type -1 found in stream. at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:478) at org.apache.pig.data.BinInterSedes.writeTuple(BinInterSedes.java:541) at org.apache.pig.data.BinInterSedes.writeBag(BinInterSedes.java:522) at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:361) at org.apache.pig.data.BinInterSedes.writeTuple(BinInterSedes.java:541) at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:357) at org.apache.pig.data.BinSedesTuple.write(BinSedesTuple.java:57) at org.apache.pig.impl.io.PigNullableWritable.write(PigNullableWritable.java:123) at org.apache.hadoop.io.serializer.WritableSerialization$WritableSerializer.serialize(WritableSerialization.java:90) at org.apache.hadoop.io.serializer.WritableSerialization$WritableSerializer.serialize(WritableSerialization.java:77) at org.apache.hadoop.mapred.MapTask$MapOutputBuffer.collect(MapTask.java:1061) at org.apache.hadoop.mapred.MapTask$NewOutputCollector.write(MapTask.java:691) at org.apache.hadoop.mapreduce.TaskInputOutputContext.write(TaskInputOutputContext.java:80) at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapReduce$Map.collect(PigMapReduce.java:116) at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.runPipeline(PigMapBase.java:239) at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:232) at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:53) at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:144) at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:764) at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370) at org.apache.hadoop.mapred.Child$4.run(Child.java:272) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1059) at org.apache.hadoop.mapred.Child.main(Child.java:266) Backend error message - java.lang.Throwable: Child Error at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:271) Caused by: java.io.IOException: Task process exit with nonzero status of 65. at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:258) -- 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-3973) Pig CounterColumnFamily support
[ https://issues.apache.org/jira/browse/CASSANDRA-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3973. - Resolution: Fixed Fix Version/s: 1.1.0 1.0.9 Committed, thanks! Pig CounterColumnFamily support --- Key: CASSANDRA-3973 URL: https://issues.apache.org/jira/browse/CASSANDRA-3973 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.0.8 Environment: OSX 10.6.latest, Pig 0.9.2 Reporter: Janne Jalkanen Assignee: Janne Jalkanen Labels: counters, hadoop, pig Fix For: 1.0.9, 1.1.0 Attachments: 3973-v2.txt, cassandrastorage.txt, testpatch.txt, v3.txt Included a patch to the current test script to demonstrate that CassandraStorage does not support counter columns, as well as a patch to fix the issue. The core reason is that CassandraStorage assumes that counters can be unpacked using CounterColumnType, when in fact the column value is already a Long. -- 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-3972) HintedHandoff fails to deliver any hints
[ https://issues.apache.org/jira/browse/CASSANDRA-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3972. - Resolution: Fixed Reviewer: jbellis (was: slebresne) Committed. HintedHandoff fails to deliver any hints Key: CASSANDRA-3972 URL: https://issues.apache.org/jira/browse/CASSANDRA-3972 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Blocker Labels: hintedhandoff Fix For: 1.1.0 Attachments: 3972.txt Summary says it all. Whether in a memtable or sstable, no hints are delivered. -- 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-3356) Add more data type checks when storing data from Pig to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3356. - Resolution: Fixed Think I got this one in CASSANDRA-3886. Add more data type checks when storing data from Pig to Cassandra - Key: CASSANDRA-3356 URL: https://issues.apache.org/jira/browse/CASSANDRA-3356 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.7 Reporter: Jeremy Hanna Priority: Minor Labels: pig Pre-CASSANDRA-2810, the decompose method was tried before assuming the data was of type DataByteArray. It needs to have both - first a check to see if it can be decomposed. If that doesn't work (exception) it can try the cast. If that doesn't work, then we can't store the object - or as Brandon says, we need to put another special case in ObjToBB. This is all based on a conversation in IRC with Brandon Williams, Jacob Perkins, and Jeremy Hanna about a problem arising when trying to store an object of type long to Cassandra. -- 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-3815) Alllow compression setting adjustment via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3815. - Resolution: Fixed Committed. Alllow compression setting adjustment via JMX - Key: CASSANDRA-3815 URL: https://issues.apache.org/jira/browse/CASSANDRA-3815 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.0 Attachments: 3815.txt As the title says, let's allow enabling/disabling/setting chunk size via JMX. -- 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-3928) Bulk loading to cassandra with Python Hadoop Job.
[ https://issues.apache.org/jira/browse/CASSANDRA-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3928. - Resolution: Won't Fix Reviewer: (was: jbellis) The only way to do this short of reimplementing everything in python would be to use jython to write the sstables via BOF and stream them in. Alternatively, you could insert the data via thrift from cpython. Bulk loading to cassandra with Python Hadoop Job. - Key: CASSANDRA-3928 URL: https://issues.apache.org/jira/browse/CASSANDRA-3928 Project: Cassandra Issue Type: New Feature Components: Hadoop, Tools Affects Versions: 1.2 Reporter: Samarth Gahire Assignee: Brandon Williams Priority: Minor Labels: bulkloader, hadoop, python, sstableloader Fix For: 1.2 Original Estimate: 48h Remaining Estimate: 48h I was wondering if we can have a OutPutFormat to Bulkload the data to Cassandra with Hadoop Job Written in Python. I am having very complex Hadoop job written in Python which processes test data and generate structured data in sequential file. I read this data and stream it to cassandra using BulkOutPutFormat. Is there any way that I can avoid writing to sequential file and directly process and stream data to Cassandra(With Hadoop Job written in python)? What could be a possible solution for same? -- 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-3886) Pig can't store some types after loading them
[
https://issues.apache.org/jira/browse/CASSANDRA-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3886.
-
Resolution: Fixed
Committed.
Pig can't store some types after loading them
-
Key: CASSANDRA-3886
URL: https://issues.apache.org/jira/browse/CASSANDRA-3886
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.7
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.8
Attachments: 3886.txt
In CASSANDRA-2810, we removed the decompose methods in putNext instead
relying on objToBB, however it cannot sufficiently handle all types. For
instance, if longs are loaded and then an attempt to store them is made, this
causes a cast exception: java.io.IOException: java.io.IOException:
java.lang.ClassCastException: java.lang.Long cannot be cast to
org.apache.pig.data.DataByteArray Output must be (key, {(column,value)...})
for ColumnFamily or (key, {supercolumn:{(column,value)...}...}) for
SuperColumnFamily
--
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-3371) Cassandra inferred schema and actual data don't match
[
https://issues.apache.org/jira/browse/CASSANDRA-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3371.
-
Resolution: Fixed
Fix Version/s: 1.0.8
Committed w/cleanup patch.
Cassandra inferred schema and actual data don't match
-
Key: CASSANDRA-3371
URL: https://issues.apache.org/jira/browse/CASSANDRA-3371
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.7
Reporter: Pete Warden
Assignee: Brandon Williams
Fix For: 1.0.8
Attachments: 0001-Rework-pig-schema.txt,
0002-Output-support-to-match-input.txt, 3371-v2.txt, 3371-v3.txt,
3371-v4.txt, 3371-v5-rebased.txt, 3371-v5.txt, 3371-v6-cleanup.patch,
3371-v6.txt, pig.diff, smoke_test.txt
It's looking like there may be a mismatch between the schema that's being
reported by the latest CassandraStorage.java, and the data that's actually
returned. Here's an example:
rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
DESCRIBE rows;
rows: {key: chararray,columns: {(name: chararray,value:
bytearray,photo_owner: chararray,value_photo_owner: bytearray,pid:
chararray,value_pid: bytearray,matched_string:
chararray,value_matched_string: bytearray,src_big: chararray,value_src_big:
bytearray,time: chararray,value_time: bytearray,vote_type:
chararray,value_vote_type: bytearray,voter: chararray,value_voter:
bytearray)}}
DUMP rows;
(691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
getSchema() is reporting the columns as an inner bag of tuples, each of which
contains 16 values. In fact, getNext() seems to return an inner bag
containing 7 tuples, each of which contains two values.
It appears that things got out of sync with this change:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083r2=1177082pathrev=1177083
See more discussion at:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
--
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-3886) Pig can't store some types after loading them
[
https://issues.apache.org/jira/browse/CASSANDRA-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3886.
-
Resolution: Fixed
Committed w/nit fixed.
Pig can't store some types after loading them
-
Key: CASSANDRA-3886
URL: https://issues.apache.org/jira/browse/CASSANDRA-3886
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.7
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.8
Attachments: 3886.txt
In CASSANDRA-2810, we removed the decompose methods in putNext instead
relying on objToBB, however it cannot sufficiently handle all types. For
instance, if longs are loaded and then an attempt to store them is made, this
causes a cast exception: java.io.IOException: java.io.IOException:
java.lang.ClassCastException: java.lang.Long cannot be cast to
org.apache.pig.data.DataByteArray Output must be (key, {(column,value)...})
for ColumnFamily or (key, {supercolumn:{(column,value)...}...}) for
SuperColumnFamily
--
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-3876) nodetool removetoken force causes an inconsistent state
[
https://issues.apache.org/jira/browse/CASSANDRA-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3876.
-
Resolution: Fixed
Fix Version/s: 1.0.8
Committed, thanks.
nodetool removetoken force causes an inconsistent state
---
Key: CASSANDRA-3876
URL: https://issues.apache.org/jira/browse/CASSANDRA-3876
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7, 1.1
Reporter: Sam Overton
Assignee: Sam Overton
Labels: force, nodetool, removetoken
Fix For: 1.0.8
Attachments: 3876.patch
Steps to reproduce (tested on 1.0.7 and trunk):
* Create a cluster of 3 nodes
* Insert some data
* stop one of the nodes
* Call removetoken on the token of the stopped node
* Immediately after, do removetoken force
- this will cause the original removetoken to fail with an error after 30s
since the generation changed for the leaving node, but this is a convenient
way of simulating the case where a removetoken hangs at streaming since the
cleanup logic at the end of StorageService.removeToken is never executed.
- if you want a more realistic reproduction then get a removetoken to hang
in streaming, then do removetoken force
Effects:
* removetoken status now throws an exception because
StorageService.removingNode is not cleared, but the endpoint is no longer a
member of the ring:
$ nodetool -h localhost removetoken status
{noformat}
Exception in thread main java.lang.AssertionError
at
org.apache.cassandra.locator.TokenMetadata.getToken(TokenMetadata.java:304)
at
org.apache.cassandra.service.StorageService.getRemovalStatus(StorageService.java:2369)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
at
com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
at
com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:205)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:683)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:672)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
at
javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:619)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{noformat}
* truncate no longer works in the cli because the removed endpoint is not
removed from Gossiper.unreachableEndpoints.
The cli errors immediately with:
{noformat}
[default@ks1] truncate cf1;
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$truncate_result.read(Cassandra.java:20978)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_truncate(Cassandra.java:942)
at
[jira] [Resolved] (CASSANDRA-3677) NPE during HH delivery when gossip turned off on target
[ https://issues.apache.org/jira/browse/CASSANDRA-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3677. - Resolution: Fixed Good catch, Sam. Committed. NPE during HH delivery when gossip turned off on target --- Key: CASSANDRA-3677 URL: https://issues.apache.org/jira/browse/CASSANDRA-3677 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.7 Reporter: Radim Kolar Assignee: Brandon Williams Priority: Trivial Fix For: 1.0.8 Attachments: 3677-v1.patch, 3677.txt probably not important bug ERROR [OptionalTasks:1] 2011-12-27 21:44:25,342 AbstractCassandraDaemon.java (line 138) Fatal exception in thread Thread[OptionalTasks:1,5,main] java.lang.NullPointerException at org.cliffc.high_scale_lib.NonBlockingHashMap.hash(NonBlockingHashMap.java:113) at org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:553) at org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:348) at org.cliffc.high_scale_lib.NonBlockingHashMap.putIfAbsent(NonBlockingHashMap.java:319) at org.cliffc.high_scale_lib.NonBlockingHashSet.add(NonBlockingHashSet.java:32) at org.apache.cassandra.db.HintedHandOffManager.scheduleHintDelivery(HintedHandOffManager.java:371) at org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:356) at org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:84) at org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:119) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) 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] [Resolved] (CASSANDRA-3863) Nodetool ring output not sorted by token order
[ https://issues.apache.org/jira/browse/CASSANDRA-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3863. - Resolution: Fixed Committed. Nodetool ring output not sorted by token order -- Key: CASSANDRA-3863 URL: https://issues.apache.org/jira/browse/CASSANDRA-3863 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1 Reporter: Michael Allen Assignee: Yuki Morishita Priority: Minor Fix For: 1.1 Attachments: cassandra-1.1-3863.txt Prior to 1.1 the output of nodetool ring was sorted in token order. It looks like StorageService.getTokenToEndpointMap has been changed to return MapString,String in place of the previously used MapToken, String. -- 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-3847) Pig should throw a useful error when the destination CF doesn't exist
[
https://issues.apache.org/jira/browse/CASSANDRA-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3847.
-
Resolution: Fixed
Committed.
Pig should throw a useful error when the destination CF doesn't exist
-
Key: CASSANDRA-3847
URL: https://issues.apache.org/jira/browse/CASSANDRA-3847
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.7.0
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.8
Attachments: 3847.txt
When trying to store data to nonexistent CF, no good error is returned.
Instead you get a message like:
{noformat}
[main] ERROR org.apache.pig.tools.grunt.Grunt - ERROR 2042: Error in new
logical plan. Try -Dpig.usenewlogicalplan=false.
{noformat}
Which, if you follow its advice, will eventually lead you to an NPE in
initSchema.
--
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-3826) Pig cannot use output formats other than CFOF
[ https://issues.apache.org/jira/browse/CASSANDRA-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3826. - Resolution: Fixed Committed w/ternary change. Pig cannot use output formats other than CFOF - Key: CASSANDRA-3826 URL: https://issues.apache.org/jira/browse/CASSANDRA-3826 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1 Attachments: 3826.txt Pig has ColumnFamilyOutputFormat hard coded. -- 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-3802) Cli returns UE on truncate when command is successful
[
https://issues.apache.org/jira/browse/CASSANDRA-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3802.
-
Resolution: Not A Problem
UE will be thrown on timeout until 1.1. Increasing rpc_timeout will increase
the time until the exception is thrown (but truncate may work despite the
exception, TOE always means you don't know what happened)
Cli returns UE on truncate when command is successful
-
Key: CASSANDRA-3802
URL: https://issues.apache.org/jira/browse/CASSANDRA-3802
Project: Cassandra
Issue Type: Bug
Reporter: Joaquin Casares
Much like: https://issues.apache.org/jira/browse/CASSANDRA-3651
The UE is returned instead of a timeout error, but in this case, the timeout
error is returned even though the command executes successfully. Could we
have a tunable parameter to increase the timeout period?
Example stacktrace:
{noformat}
[default@cfs] truncate cleanup;
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$truncate_result.read(Cassandra.java:20210)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_truncate(Cassandra.java:1077)
at org.apache.cassandra.thrift.Cassandra$Client.truncate(Cassandra.java:1052)
at org.apache.cassandra.cli.CliClient.executeTruncate(CliClient.java:1498)
at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:270)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:346)
{noformat}
JNA confirmed on all machines via jinfo. Flush and snapshot confirmed to be
successful individually.
A truncate was tried again and the view from cfstats changed:
{noformat}
Column Family: sblocks
SSTable count: 3
Space used (live): 22200
Space used (total): 22200
Number of Keys (estimate): 384
Memtable Columns Count: 0
Memtable Data Size: 0
Memtable Switch Count: 0
Read Count: 0
Read Latency: NaN ms.
Write Count: 0
Write Latency: NaN ms.
Pending Tasks: 0
Bloom Filter False Postives: 0
Bloom Filter False Ratio: 0.0
Bloom Filter Space Used: 56
Key cache capacity: 100
Key cache size: 0
Key cache hit rate: NaN
Row cache: disabled
Compacted row minimum size: 73
Compacted row maximum size: 4768
Compacted row mean size: 1379
to
Column Family: sblocks
SSTable count: 0
Space used (live): 0
Space used (total): 0
Number of Keys (estimate): 0
Memtable Columns Count: 0
Memtable Data Size: 0
Memtable Switch Count: 0
Read Count: 0
Read Latency: NaN ms.
Write Count: 0
Write Latency: NaN ms.
Pending Tasks: 0
Bloom Filter False Postives: 0
Bloom Filter False Ratio: 0.0
Bloom Filter Space Used: 0
Key cache capacity: 100
Key cache size: 0
Key cache hit rate: NaN
Row cache: disabled
Compacted row minimum size: 0
Compacted row maximum size: 0
Compacted row mean size: 0
{noformat}
even though the UE was still thrown (as a possible TE).
After trying to truncate different cfs back-to-back, one completed
successfully and the rest all followed with successful completions.
--
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-1805) refactor and remove contrib/
[ https://issues.apache.org/jira/browse/CASSANDRA-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-1805. - Resolution: Fixed refactor and remove contrib/ Key: CASSANDRA-1805 URL: https://issues.apache.org/jira/browse/CASSANDRA-1805 Project: Cassandra Issue Type: Task Reporter: Jonathan Ellis Priority: Minor Fix For: 1.1 Attachments: 1805-sstabledebug.txt Contrib is a mix of examples, tools, and miscellanea that probably doesn't belong in our source tree. -- 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-3745) contrib/PIG example fails when column metadata exists for CF
[
https://issues.apache.org/jira/browse/CASSANDRA-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3745.
-
Resolution: Duplicate
Ultimately the same issue as CASSANDRA-3371. Despite the unclear error
message, the problem is actually the validators -- duplicate names of value
contrib/PIG example fails when column metadata exists for CF
Key: CASSANDRA-3745
URL: https://issues.apache.org/jira/browse/CASSANDRA-3745
Project: Cassandra
Issue Type: Bug
Components: Contrib
Affects Versions: 1.0.6
Reporter: Sasha Dolgy
Labels: cassandra, pig
I have a sandbox CF for prototyping and it has 17 Secondary Indexes defined.
When I would run the contrib/PIG example, using pig 0.8.1 and even the pig
0.8.3 jar, with Cassandra 1.0.6, I would receive the following error from the
second line of the example script [ cols = FOREACH rows GENERATE
flatten(columns); ]:
2012-01-14 06:54:27,551 [main] ERROR org.apache.pig.tools.grunt.Grunt - ERROR
1007: Found duplicates in schema. : 18 columns. Please alias the columns with
unique names.
I proceeded to drop all of the indexes, and tried again. Same error. On
further inspection, show schema showed that the metadata still existed on the
CF from the indexes. I ran the following:
update column family user with column_metadata = [];
I can now run the full contrib/pig example against my CF.
*If I select another CF with 2 secondary indexes, the same behaviour persists:
2012-01-14 08:34:31,413 [main] ERROR org.apache.pig.tools.grunt.Grunt - ERROR
1007: Found duplicates in schema. : 3 columns. Please alias the columns with
unique names.
grunt describe users;
2012-01-14 08:36:58,227 [main] INFO org.apache.hadoop.metrics.jvm.JvmMetrics
- Cannot initialize JVM Metrics with processName=JobTracker, sessionId= -
already initialized
users: {key: bytearray,columns: {T: (name: chararray,value:
bytearray,column_family: chararray,value: bytearray,owner_id:
chararray,value: bytearray)}}
grunt
grunt dump users;
-- removed INFO/WARN output --
HadoopVersion PigVersion UserId StartedAt FinishedAt
Features
0.20.2 0.8.1 sasha 2012-01-14 08:37:24 2012-01-14 08:37:43
UNKNOWN
Success!
Job Stats (time in seconds):
JobId Alias Feature Outputs
job_local_0001 users MAP_ONLY
file:/tmp/temp-1366421017/tmp-1001688304,
Input(s):
Successfully read records from: cassandra://sdo/entity_relations
Output(s):
Successfully stored records in: file:/tmp/temp-1366421017/tmp-1001688304
Job DAG:
job_local_0001
(d1540edc-cb16-47dd-96e3-90e1657c2d77:a721966c6026ee85ef35f2108b75d3784b52bf1217f0b62564bdefe67b9504d9,{(content_id,d1540edc-cb16-47dd-96e3-90e1657c2d77:a721966c6026ee85ef35f2108b75d3784b52bf1217f0b62564bdefe67b9504d9),(owner_id,d1540edc-cb16-47dd-96e3-90e1657c2d77)})
grunt
I have also tried this with PIG 0.9.1 but encounter
https://issues.apache.org/jira/browse/CASSANDRA-3371
--
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-3737) Its impossible to removetoken joining down node
[ https://issues.apache.org/jira/browse/CASSANDRA-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3737. - Resolution: Fixed Committed. Its impossible to removetoken joining down node --- Key: CASSANDRA-3737 URL: https://issues.apache.org/jira/browse/CASSANDRA-3737 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Assignee: Brandon Williams Fix For: 1.0.8 Attachments: 3737.txt We have a node that incidentaly started to join cluster. Admins made it down quicky, so now it looks : 10.112.0.234datacenter1 rack1 Down Joining 46.83 GB2,90% 15893087653239874101909022095979644640 And I can't removetoken such a node: nodetool -h tap9600 removetoken 15893087653239874101909022095979644640 Exception in thread main java.lang.UnsupportedOperationException: Token not found. at org.apache.cassandra.service.StorageService.removeToken(StorageService.java:2376) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807) at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) -- 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-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3733.
-
Resolution: Fixed
Committed.
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Minor
Fix For: 1.0.8
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
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-3717) remove contrib/javautils
[ https://issues.apache.org/jira/browse/CASSANDRA-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3717. - Resolution: Fixed Committed. remove contrib/javautils Key: CASSANDRA-3717 URL: https://issues.apache.org/jira/browse/CASSANDRA-3717 Project: Cassandra Issue Type: Sub-task Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1 As far as I know only hector uses this and it doesn't really belong in our tree. Patch is 'rm -rf contrib/javautils' -- 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-3720) Adding tombstone statistics to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3720. - Resolution: Duplicate CASSANDRA-3515 Adding tombstone statistics to cfstats -- Key: CASSANDRA-3720 URL: https://issues.apache.org/jira/browse/CASSANDRA-3720 Project: Cassandra Issue Type: New Feature Reporter: Jackson Chung Priority: Minor Fix For: 1.2 given the number of tombstones can affect read performance (eg when read the first column) , could we look into adding some stats monitoring of tombstone in cfstats or cfhistogram? Even if not for read performance, it's good to find a way to tell a tombstone status of a CF. eg: similar to cfstats compaction row min/mean/max size section, a min/mean/max for tombstone count ? maybe nice also to check in cfhistogram, or maybe just have some open jmx methods? ideas open -- 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-3197) Separate input and output connection details in ConfigHelper
[ https://issues.apache.org/jira/browse/CASSANDRA-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3197. - Resolution: Fixed Committed again with trivial fixes to BRW. Separate input and output connection details in ConfigHelper Key: CASSANDRA-3197 URL: https://issues.apache.org/jira/browse/CASSANDRA-3197 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.7.0 Reporter: Mck SembWever Assignee: Mck SembWever Priority: Minor Fix For: 1.1 Attachments: CASSANDRA-3197.patch Currently ConfigHelper's getInitialAddress(..) getRpcPort(..) and getPartitioner(..) presume CFIF will be using the same cluster as CFOF. The latter two are a problem for me as on the same servers i'm running two clusters, one w/ ByteOrderingPartitioner and the other with RP), and i would like to read from the BOP cluster and write to the RP cluster. -- 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-3695) Hibernating nodes that die never go away
[ https://issues.apache.org/jira/browse/CASSANDRA-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3695. - Resolution: Not A Problem Punting on this. I can't see a way to solve this without special-casing HIBERNATE as a third kind of state in a lot of places, and I think the two kinds we have (alive, dead) provide a good logical delineation already that I don't want to taint. Hibernating nodes that die never go away Key: CASSANDRA-3695 URL: https://issues.apache.org/jira/browse/CASSANDRA-3695 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Brandon Williams Title says it all. We should be able to monitor these via the gossip heartbeat like other nodes, but it's tricky since it's a dead state. -- 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-3677) NPE during HH delivery when gossip turned off on target
[ https://issues.apache.org/jira/browse/CASSANDRA-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3677. - Resolution: Not A Problem Fix Version/s: (was: 1.0.8) NPE during HH delivery when gossip turned off on target --- Key: CASSANDRA-3677 URL: https://issues.apache.org/jira/browse/CASSANDRA-3677 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.7 Reporter: Radim Kolar Assignee: Brandon Williams Priority: Trivial Attachments: 3677.txt probably not important bug ERROR [OptionalTasks:1] 2011-12-27 21:44:25,342 AbstractCassandraDaemon.java (line 138) Fatal exception in thread Thread[OptionalTasks:1,5,main] java.lang.NullPointerException at org.cliffc.high_scale_lib.NonBlockingHashMap.hash(NonBlockingHashMap.java:113) at org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:553) at org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:348) at org.cliffc.high_scale_lib.NonBlockingHashMap.putIfAbsent(NonBlockingHashMap.java:319) at org.cliffc.high_scale_lib.NonBlockingHashSet.add(NonBlockingHashSet.java:32) at org.apache.cassandra.db.HintedHandOffManager.scheduleHintDelivery(HintedHandOffManager.java:371) at org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:356) at org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:84) at org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:119) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) 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] [Resolved] (CASSANDRA-3669) [patch] Word count sample has a flawed addToMutationMap, fix
[ https://issues.apache.org/jira/browse/CASSANDRA-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3669. - Resolution: Fixed Committed. [patch] Word count sample has a flawed addToMutationMap, fix Key: CASSANDRA-3669 URL: https://issues.apache.org/jira/browse/CASSANDRA-3669 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.0.7 Attachments: mutation_sample.diff The WordCount example shows how to use client.batch_mutate, and has a helper method for building a mutation map. While the example works properly, the example addToMutationMap is flawed in that it won't allow adding of multiple columns to the same row, as is what is needed to perform a 'sql like insert' operation, which is the most likely example someone learning cassandra will want to do. Fixed the sample addToMutationMap code so that it works correctly for multi column inserts in one 'row'. -- 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-3415) show schema fails
[
https://issues.apache.org/jira/browse/CASSANDRA-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3415.
-
Resolution: Fixed
Fix Version/s: 0.8.10
show schema fails
-
Key: CASSANDRA-3415
URL: https://issues.apache.org/jira/browse/CASSANDRA-3415
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: freebsd
Reporter: Radim Kolar
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.10, 1.0.7
following command breaks show schema cli command with error A long is
exactly 8 bytes: 5
create column family resultcache with column_type = 'Super' and comparator =
'LongType' and key_validation_class = 'UTF8Type' and subcomparator =
'AsciiType' and replicate_on_write = false and rows_cached = 700 and
keys_cached = 3 and key_cache_save_period = 0 and column_metadata = [
{column_name: id, validation_class: LongType}, {column_name: name,
validation_class: 'AsciiType'}, {column_name: crc32, validation_class:
LongType}, {column_name: size, validation_class: LongType} ];
--
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-3602) Remove test/distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3602. - Resolution: Fixed Assignee: Brandon Williams Committed. Remove test/distributed --- Key: CASSANDRA-3602 URL: https://issues.apache.org/jira/browse/CASSANDRA-3602 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Priority: Trivial Fix For: 1.0.6, 1.1 Now that we've shifted focus to the new ccm-based distributed tests (https://github.com/riptano/cassandra-dtest) I think it's time to remove the now long-neglected distributed test cruft from our tree. -- 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-3563) Packaging should increase vm.max_map_count to accommodate leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3563. - Resolution: Fixed You're right. Committed. Packaging should increase vm.max_map_count to accommodate leveled compaction Key: CASSANDRA-3563 URL: https://issues.apache.org/jira/browse/CASSANDRA-3563 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.6 Attachments: 0001-increase-debian-limit.txt, 0002-fix-sysctl.d-installation.txt As the title says, leveled can create a lot of files and you can run into an IOError trying to mmap all of them. -- 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-3550) Relax phi threshold enforcement
[ https://issues.apache.org/jira/browse/CASSANDRA-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3550. - Resolution: Not A Problem Closing in favor of the JMX method. Relax phi threshold enforcement --- Key: CASSANDRA-3550 URL: https://issues.apache.org/jira/browse/CASSANDRA-3550 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Priority: Trivial Fix For: 1.0.6 Attachments: 3550.txt Currently we clamp the phi threshold between 5 and 16. For distributed testing purposes, 5 slows things down. Instead let's allow values down to 1, but add a warning for anything less than 5. -- 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-3599) NullPointerException in OutbountTcpConnection when encryption_options not in cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3599. - Resolution: Duplicate CASSANDRA-3489 solved this. NullPointerException in OutbountTcpConnection when encryption_options not in cassandra.yaml --- Key: CASSANDRA-3599 URL: https://issues.apache.org/jira/browse/CASSANDRA-3599 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.5 Environment: Ubuntu Lucid 64-bit Reporter: Bryce Allen Priority: Minor I setup a 3 node cluster in VirtualBox, and none of the nodes were seeing each other (nodetool -h localhost ring showed just the local node on each). The non-seed nodes had this in the log file: AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/192.168.33.101,5,main] java.lang.NullPointerException at org.apache.cassandra.net.OutboundTcpConnectionPool.isEncryptedChannel(OutboundTcpConnectionPool.java:93) at org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:77) at org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:212) Copying the encryption_options section from the default cassandra.yaml into my configs fixed this. -- 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-3503) IncomingStreamReader uses socket.getRemoteSocketAddress() which might be diffrent than FB.getBroadcastAddress()
[ https://issues.apache.org/jira/browse/CASSANDRA-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3503. - Resolution: Fixed Committed, thanks! IncomingStreamReader uses socket.getRemoteSocketAddress() which might be diffrent than FB.getBroadcastAddress() --- Key: CASSANDRA-3503 URL: https://issues.apache.org/jira/browse/CASSANDRA-3503 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.1 Attachments: 0001-fixing-the-bca-lookup-for-streaming-v2.patch, 0001-fixing-the-bca-lookup-for-streaming.patch We can add BCA to the streaming so the receiver can use this to StreamInSession.get(bca, sid) Currently this causes the repairs to hang when the bca is diffrent than LocalAddress. -- 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-3114) After Choosing EC2Snitch you can't migrate off w/o a full cluster restart
[ https://issues.apache.org/jira/browse/CASSANDRA-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3114. - Resolution: Fixed Closing, see CASSANDRA-3186 After Choosing EC2Snitch you can't migrate off w/o a full cluster restart - Key: CASSANDRA-3114 URL: https://issues.apache.org/jira/browse/CASSANDRA-3114 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.8, 0.8.4 Reporter: Benjamin Coverston Once you choose the Ec2Snitch the gossip messages will trigger this exception if you try to move (for example) to the property file snitch: ERROR [pool-2-thread-11] 2011-08-30 16:38:06,935 Cassandra.java (line 3041) Internal error processing get_slice java.lang.NullPointerException at org.apache.cassandra.locator.Ec2Snitch.getDatacenter(Ec2Snitch.java:84) at org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:122) at org.apache.cassandra.service.DatacenterReadCallback.assureSufficientLiveNodes(DatacenterReadCallback.java:77) at org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:516) at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:480) at org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:109) at org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:263) at org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:345) at org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:306) at org.apache.cassandra.thrift.Cassandra$Processor$get_slice.process(Cassandra.java:3033) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187) 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) -- 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-2855) Skip rows with empty columns when slicing entire row
[ https://issues.apache.org/jira/browse/CASSANDRA-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-2855. - Resolution: Fixed Committed. Skip rows with empty columns when slicing entire row Key: CASSANDRA-2855 URL: https://issues.apache.org/jira/browse/CASSANDRA-2855 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jeremy Hanna Assignee: T Jake Luciani Priority: Minor Labels: hadoop Fix For: 0.8.8 Attachments: 2855-v2.txt, 2855-v3.txt, 2855-v4.txt, 2855-v5.txt, v1-0001-CASSANDRA-2855-ignore-ghosts-when-no-predicate-specifi.txt We have been finding that range ghosts appear in results from Hadoop via Pig. This could also happen if rows don't have data for the slice predicate that is given. This leads to having to do a painful amount of defensive checking on the Pig side, especially in the case of range ghosts. We would like to add an option to skip rows that have no column values in it. That functionality existed before in core Cassandra but was removed because of the performance penalty of that checking. However with Hadoop support in the RecordReader, that is batch oriented anyway, so individual row reading performance isn't as much of an issue. Also we would make it an optional config parameter for each job anyway, so people wouldn't have to incur that penalty if they are confident that there won't be those empty rows or they don't care. It could be parameter cassandra.skip.empty.rows and be true/false. -- 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-3088) Expose compaction_throughput_mb_per_sec for JMX tweaking
[ https://issues.apache.org/jira/browse/CASSANDRA-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3088. - Resolution: Not A Problem CASSANDRA-2156 came with this. Expose compaction_throughput_mb_per_sec for JMX tweaking Key: CASSANDRA-3088 URL: https://issues.apache.org/jira/browse/CASSANDRA-3088 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8.0 Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Minor Labels: lhf Fix For: 1.0.1 -- 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-3384) it would be nice if show schema; in cli shows Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3384. - Resolution: Not A Problem I too see this in 0.8. it would be nice if show schema; in cli shows Cache Provider Key: CASSANDRA-3384 URL: https://issues.apache.org/jira/browse/CASSANDRA-3384 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Environment: JVM on Linux Reporter: Vijay Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 0.8.8, 1.0.1 Show schema in the cli doesn't show the cache provider it would be nice to show it to verify the settings. -- 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-3364) [patch] use long math, if you want long results
[ https://issues.apache.org/jira/browse/CASSANDRA-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3364. - Resolution: Fixed Reviewer: brandon.williams Committed, thanks. [patch] use long math, if you want long results --- Key: CASSANDRA-3364 URL: https://issues.apache.org/jira/browse/CASSANDRA-3364 Project: Cassandra Issue Type: Bug Components: Core Reporter: Dave Brosius Priority: Trivial Attachments: use_long_math.diff Code calculates long values, using integer intermediate input, which can cause truncation errors, safer just to use long input. -- 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-3365) [patch] don't stutter exception messages
[ https://issues.apache.org/jira/browse/CASSANDRA-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3365. - Resolution: Fixed Reviewer: brandon.williams Committed. [patch] don't stutter exception messages Key: CASSANDRA-3365 URL: https://issues.apache.org/jira/browse/CASSANDRA-3365 Project: Cassandra Issue Type: Improvement Reporter: Dave Brosius Priority: Trivial Fix For: 1.0.1 Attachments: stutter_ex.diff doing log.error(e.getMessage(), e); just stutters the error message twice, which is annoying. Use a real message -- 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-3214) Make CFIF use rpc_endpoint prior to trying endpoint
[ https://issues.apache.org/jira/browse/CASSANDRA-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3214. - Resolution: Fixed Committed with formatting fixes. Thanks! Make CFIF use rpc_endpoint prior to trying endpoint --- Key: CASSANDRA-3214 URL: https://issues.apache.org/jira/browse/CASSANDRA-3214 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.8.6 Environment: Hadoop 0.20 / Cassandra 0.8.5 / Ubuntu 10.04 / Reporter: Eldon Stegall Assignee: Eldon Stegall Priority: Minor Fix For: 0.8.8 Attachments: CASSANDRA-3214-make-cfif-use-rpc-endpoints-v1.txt, CASSANDRA-3214.patch Following up on CASSANDRA-3187 , we probably need to attempt to use the rpc_endpoint address first, and then fall back to the gossip endpoint if we don't get what we want. -- 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-2357) Load spikes on coordinators since upgrade from 0.6.8 to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-2357. - Resolution: Not A Problem Load spikes on coordinators since upgrade from 0.6.8 to 0.7 --- Key: CASSANDRA-2357 URL: https://issues.apache.org/jira/browse/CASSANDRA-2357 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.4 Reporter: Jason Harvey Attachments: thread_dump.txt Since our move from 0.6.8 to 0.7, all of the nodes which speak with clients have been having periodic, abrupt load spikes going into the hundreds. We have been seeing these load spikes 1 to 2 times per hour on every node which clients are speaking with. The load graph for a typical spike: http://i.imgur.com/jY8AV.png I have verified that client connections are not spiking at the same time via TCP statistics. I have also verified that we aren't seeing any spikes in reads/mutations/etc. We were using the DynamicSnitch, but I turned that off as a troubleshooting step. The issue was unchanged. When the spikes occur, the box's responsiveness slows to a crawl so I am unable to do much in terms of real-time diagnostics. I was able to get a thread dump a few seconds after a spike, which I have attached to this ticket. Not sure if it will show anything since I couldn't capture it immediately during the spike. I should note that David King noticed a similar problem (#2058) when he tried moving us from 0.6.8 to 0.6.10. The main issue at the time was a long-lasting load spike, but he also saw occasional abrupt load spikes like we are seeing now. When we moved back to 0.6.8, we didn't see the problem again, until the move to 0.7. I realize this information is somewhat nebulous. If there is any further info I can provide, please let me know. The spikes are causing quite a bit of instability, so we are considering retreating back to 0.6.8. I'd like to investigate every possible solution before we resort to that. -- 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-3352) do not bind to a specific address for listening
[ https://issues.apache.org/jira/browse/CASSANDRA-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3352. - Resolution: Invalid You can already specify 0.0.0.0 for rpc_address to bind all interfaces. do not bind to a specific address for listening --- Key: CASSANDRA-3352 URL: https://issues.apache.org/jira/browse/CASSANDRA-3352 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Priority: Minor now the thrift api binds to a specific address when it opens up the tcp socket. this creates a little inconvenience when you access the box in cassandra-cli: you have to find the exact host name. but if you are using cassandra-cli on localhost, you would normally like to just use localhost; similarly there is a problem if you use EC2, you have to find the external address, instead of using the local ip, which is available to you. I understand that the bind address would be useful in cases of testing (you can create multiple clusters on the same box), but probably we could preserve that behavior through a config var for testing mode only -- 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-3346) HsHa broken at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3346.
-
Resolution: Fixed
Assignee: Brandon Williams
Stupid mistake fixed in r1181816
HsHa broken at startup
--
Key: CASSANDRA-3346
URL: https://issues.apache.org/jira/browse/CASSANDRA-3346
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.0
{noformat}
ERROR 09:10:21,781 Exception encountered during startup
java.lang.IllegalArgumentException
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:589)
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:514)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.init(DebuggableThreadPoolExecutor.java:90)
at
org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutor.init(JMXEnabledThreadPoolExecutor.java:76)
at
org.apache.cassandra.thrift.CassandraDaemon$ThriftServer.init(CassandraDaemon.java:192)
at
org.apache.cassandra.thrift.CassandraDaemon.startServer(CassandraDaemon.java:75)
at
org.apache.cassandra.service.AbstractCassandraDaemon.startRPCServer(AbstractCassandraDaemon.java:281)
at
org.apache.cassandra.service.AbstractCassandraDaemon.start(AbstractCassandraDaemon.java:253)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:350)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
{noformat}
--
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-3329) make HSHA the default Thrift server
[ https://issues.apache.org/jira/browse/CASSANDRA-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3329. - Resolution: Fixed Bumped to cores * 4 in r1180277 make HSHA the default Thrift server --- Key: CASSANDRA-3329 URL: https://issues.apache.org/jira/browse/CASSANDRA-3329 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0.0 Attachments: 3329.txt HSHA has been an option since 0.8.3 (CASSANDRA-1405) and has been stable. Besides making possible lots of unpooled connections such as are common in some environments (*cough* PHP), we've seen EC2 in particular have trouble with lots of threads (CASSANDRA-2170). -- 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-2170) Load spikes
[ https://issues.apache.org/jira/browse/CASSANDRA-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-2170. - Resolution: Fixed bq. Is the stack trace I gave interesting enough to pursue further investigation into the issue, or should I just leave the answer as 'HSHA' ? I'm content with calling this 'ec2 sucks when there are tons of threads.' (Jason told me he's opening 2000+ connections) Load spikes --- Key: CASSANDRA-2170 URL: https://issues.apache.org/jira/browse/CASSANDRA-2170 Project: Cassandra Issue Type: Bug Affects Versions: 0.6.11 Reporter: Jonathan Ellis Assignee: Brandon Williams as reported on CASSANDRA-2058, some users are still seeing load spikes on 0.6.11, even with fairly low-volume read workloads. -- 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-3242) Nodes which are not in the ring but are dead in gossip prevent truncation
[ https://issues.apache.org/jira/browse/CASSANDRA-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-3242. - Resolution: Duplicate I'm pretty sure CASSANDRA-3259 addressed the root cause of this. Nodes which are not in the ring but are dead in gossip prevent truncation - Key: CASSANDRA-3242 URL: https://issues.apache.org/jira/browse/CASSANDRA-3242 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.5 Reporter: Jason Harvey Assignee: Brandon Williams Priority: Trivial All of the nodes in my ring are up, however I do have an 'unreachable' node in gossip which was removed some time ago. When I attempt to run a truncation, it does not execute since some nodes are dead, despite those nodes not owning anything in the ring. Could isAnyHostDown in StorageProxy.java be modified to not care about unreachable nodes that are not in the ring? -- 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
