unsubscribe
unsubscribe ,thanks 2010-10-29 ke.yuan.whu
unsubscribe
Fatal error: Error instantiating snitch class 'org.apache.cassandra.locator.SimpleSnitch'.
Hi, I am trying to start a CassandraEmbeddedService for JUnit testing, using the 'standard' YAML configuration I found in Hector (no modification). I use 0.7.0-beta2 and I systematically get the following error message: 3687 [main] INFO org.apache.cassandra.config.DatabaseDescriptor - Loading settings from file:/C:... .../Cassandra/cassandra.yaml 4084 [main] INFO org.apache.cassandra.config.DatabaseDescriptor - DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard 4110 [main] ERROR org.apache.cassandra.config.DatabaseDescriptor - Fatal error: Error instantiating snitch class 'org.apache.cassandra.locator.SimpleSnitch'. Bad configuration; unable to start server Googling does not return much information. Does anyone know what is happening? Thanks, JVerstry P.S.: It is very late here -> going to bed and will read answers tomorrow.
RE: unsubscribe
unsubscribe # NOTE: All emails sent from Safaricom Limited are subject to Safaricoms Email Terms & Conditions. Please click here to read the policy. #
unsubscribe
unsubscribe Edwin Eduardo Silisqui Aramayo
Re: Fatal error: Error instantiating snitch class 'org.apache.cassandra.locator.SimpleSnitch'.
There's not a lot of useful information in that error. Cassandra consumes the stack trace and any exceptions underneath that cause the error instantiating the snitch. I've created https://issues.apache.org/jira/browse/CASSANDRA-1682 so we can include a full stack trace. In the meantime, I'd say that classpath is the likely culprit. Gary. On Fri, Oct 29, 2010 at 05:32, Jérôme Verstrynge wrote: > Hi, > > I am trying to start a CassandraEmbeddedService for JUnit testing, using the > 'standard' YAML configuration I found in Hector (no modification). I use > 0.7.0-beta2 and I systematically get the following error message: > > 3687 [main] INFO org.apache.cassandra.config.DatabaseDescriptor - Loading > settings from file:/C:... .../Cassandra/cassandra.yaml > 4084 [main] INFO org.apache.cassandra.config.DatabaseDescriptor - > DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard > 4110 [main] ERROR org.apache.cassandra.config.DatabaseDescriptor - Fatal > error: Error instantiating snitch class > 'org.apache.cassandra.locator.SimpleSnitch'. > Bad configuration; unable to start server > > Googling does not return much information. Does anyone know what is > happening? > > Thanks, > > JVerstry > > P.S.: It is very late here -> going to bed and will read answers tomorrow. >
If you want to unsubscribe
unsubscribe from this list, please send an empty message to: user-unsubscr...@cassandra.apache.org please don't send the message to the list, it will disturb thousands of people.
Re: If you want to unsubscribe
Strong agree. 2010/10/29 wroxdb > unsubscribe from this list, please send an empty message to: > > user-unsubscr...@cassandra.apache.org > > please don't send the message to the list, it will disturb thousands of > people. >
Any plans to support key metadata?
In 0.7, Cassandra now supports column metadata CfDef.default_validation_class and ColumnDef.validation_class. Is there any plan to provide similar metadata for keys, at the key space or column family level? Jim
Fast way to find responsible nodes for a key?
Hi all, I'm trying to find the most efficient way to find a node in the cluster (from the client side) that may hold a copy of rows I'm querying for. The scenario is quite simple: I have a hadoop job which reads an index and then has several thousands of keys, now I want to find a way to efficiently retrieve the according rows from the cluster, for this I have to find the node that is responsible for the key. Am I right in the assumption that I can just calculate the MD5 hash (in random partitioner) of the keys, order them according to their hash, then order the TokenRanges by their endToken and then do a merge sort? Is there a faster way to do this? Regards, Chris
Re: Any plans to support key metadata?
On Fri, Oct 29, 2010 at 10:07 AM, Jim Ancona wrote: > In 0.7, Cassandra now supports column metadata > CfDef.default_validation_class and ColumnDef.validation_class. Is > there any plan to provide similar metadata for keys, at the key space > or column family level? Sorry to respond to my own email, but in re-reading it I realized that I meant to say "type metadata", not just "metadata". I'm interested in optionally being able to store a key type in the same way we now have column types. > > Jim >
Re: Any plans to support key metadata?
Eventually, but I think this requires moving to partitioner-per-columnfamily which as discussed before is a ton of work. On Fri, Oct 29, 2010 at 7:07 AM, Jim Ancona wrote: > In 0.7, Cassandra now supports column metadata > CfDef.default_validation_class and ColumnDef.validation_class. Is > there any plan to provide similar metadata for keys, at the key space > or column family level? > > Jim > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Any suggestions tuning Cassandra
Hello Folks, We are evaluating cassandra for one of our storage needs. I am running a benchmark test to gauge cassandra's performance using http://github.com/brianfrankcooper/YCSB/wiki Setup for Cassandra is 5 node cluster, replication factor 3. CentOS55 on amazon ec2 Sample test data single field of size 8 KB Running 3-4 clients with 100 Threads each. Clients are also running in the same network(availability zone) on ec2. I have run tests ranging from 1 million to 12 million inserts. I am getting a throughput of around 5 MB/s on the network and on the disk. 1) Is there any tuning I can do to improve the performance. I am trying to figure out a way to max out the network and/or disk IO but for some reason it always stays steady. 2) Another thing I notice is that the load does not get evenly distributed. I tried setting the tokens using the formula suggested in Token Selection section of Operations wiki page. That actually led to a more unbalanced load distribution (Which the doc warned can happen if the key distribution is not even). Any suggestions/pointers are welcome. Thanks. -Adi
RE: Question regarding support of batch_mutate + delete + slice predicate
Aaron This did the trick - thanks. From: aaron morton [mailto:aa...@thelastpickle.com] Sent: Thursday, October 28, 2010 3:23 AM To: user@cassandra.apache.org Subject: Re: Question regarding support of batch_mutate + delete + slice predicate I cannot see anything in jira scheduled for 0.7 or 0.8 . Gary may be able to shed some light on it. There is a comment at the bottom of CASSANDRA-293 "Range operations cannot be made to work with the existing implementation of hinted handoff. Further, they were a bad fit for the transactional units in cassandra (column family ops)." which links to the CASSANDRA-494 . You can still send a SlicePredicate into the deletion, is just only supports column_names. You can also send a null SlicePredicate to delete and a super column or an entire row. Hope that helps. Aron On 28 Oct 2010, at 19:19, Dwight Smith wrote: Investigation of this combination led to the following: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/batch-m utate-deletion-slice-range-predicate-unsupported-td5048309.html Are there plans (6.x or 7) to support this? Thanks CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. --- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
