Re: How is Cassandra being used?
> Thoughts? > We'll turn this off, and would possibly patch it out of the code. That's not to say it wouldn't be useful to others. Bill On 15/11/11 23:23, Jonathan Ellis wrote: I started a "users survey" thread over on the users list (replies are still trickling in), but as useful as that is, I'd like to get feedback that is more quantitative and with a broader base. This will let us prioritize our development efforts to better address what people are actually using it for, with less guesswork. For instance: we put a lot of effort into compression for 1.0.0; if it turned out that only 1% of 1.0.x users actually enable compression, then it means that we should spend less effort fine-tuning that moving forward, and use the energy elsewhere. (Of course it could also mean that we did a terrible job getting the word out about new features and explaining how to use them, but either way, it would be good to know!) I propose adding a basic cluster reporting feature to cassandra.yaml, enabled by default. It would send anonymous information about your cluster to an apache.org VM. Information like, number (but not names) of keyspaces and columnfamilies, ks-level options like compression, cf options like compaction strategy, data types (again, not names) of columns, average row size (or better: the histogram data), and average sstables per read. Thoughts?
Re: Bootstrap source code
Hi I did some more looking. It looks like on bootstrap the token gets added to the bootstrapTokens list. However there is no change to the tokenToEndPointMap. So how do writes make it to the new node. It is only when bootstrap is complete are the tokens removed from bootstrapTokens list added to the tokenToEndPointMap opening them up to the ring. Which means during bootstrap writes continue to go to the old nodes and the when bootstrap is complete there could be some data that was written during the bootstrap that remains on the old node. Am I missing something here? Any pointers would be great. Cheers - bill > > -- Forwarded message -- > From: Stu Hood > Date: Sun, May 2, 2010 at 10:50 AM > Subject: Re: Bootstrap source code > To: dev@cassandra.apache.org > > > Nodes declare that they will be joining the ring at a particular position, > which makes them a member of the 'pending ranges' set. Nodes with pending > ranges are supposed to receive writes for those ranges, despite not > officially owning them yet. > > > -Original Message- > From: "Roger Schildmeijer" > Sent: Sunday, May 2, 2010 11:50am > To: dev@cassandra.apache.org > Subject: Re: Bootstrap source code > > s/hinted handoff/read repair > > > > > > > > > (Moved to developers mailing list) > > > > Without delve to deep into to that part of the code my educated(?) guess > is that this will (eventually) be solved/repaired thanks to hinted handoff > and anti entropy service. > > > > > > On 2 maj 2010, at 18.29em, Bill Hastings wrote: > > > >> Hi > >> > >> I have looking at the bootstrap source and seem to understand it for the > most part. This is what I do not follow: > >> > >> (1) New node joins and doesn't advertise its token. > >> (2) Requests nodes to send it data. The nodes that need to send it data > first flush memtables and then transfer SSTables. > >> > >> Once the streaming is over the new node advertises its token and starts > handling reads and writes correct? But what happens to keys that are being > written to the old nodes after the memtables have been dumped. Looks like > there is a window where keys would be going to the old nodes and not making > it to the new nodes. Am I missing something here. > >> > >> -- > >> Cheers > >> Bill > > > > > > > -- Cheers Bill
Re: Bootstrap source code
Ah. That makes sense. All nodes start up in bootstrap mode. So on start up where in the code do I need to look to figure out that bootstrap is not required resulting in a call to finishBootstrap(). On Tue, May 4, 2010 at 6:36 PM, Jonathan Ellis wrote: > AbstractReplicationStrategy.getWriteEndpoints is where bootstrapping > nodes get added as write destinations. > > On Tue, May 4, 2010 at 6:02 PM, Bill Hastings > wrote: > > Hi > > > > I did some more looking. It looks like on bootstrap the token gets added > to > > the bootstrapTokens list. However there is no change to the > > tokenToEndPointMap. So how do writes make it to the new node. It is only > > when bootstrap is complete are the tokens removed from bootstrapTokens > list > > added to the tokenToEndPointMap opening them up to the ring. Which means > > during bootstrap writes continue to go to the old nodes and the when > > bootstrap is complete there could be some data that was written during > the > > bootstrap that remains on the old node. Am I missing something here? Any > > pointers would be great. > > > > Cheers > > - bill > > > > > >> > >> -- Forwarded message -- > >> From: Stu Hood > >> Date: Sun, May 2, 2010 at 10:50 AM > >> Subject: Re: Bootstrap source code > >> To: dev@cassandra.apache.org > >> > >> > >> Nodes declare that they will be joining the ring at a particular > position, > >> which makes them a member of the 'pending ranges' set. Nodes with > pending > >> ranges are supposed to receive writes for those ranges, despite not > >> officially owning them yet. > >> > >> > >> -Original Message- > >> From: "Roger Schildmeijer" > >> Sent: Sunday, May 2, 2010 11:50am > >> To: dev@cassandra.apache.org > >> Subject: Re: Bootstrap source code > >> > >> s/hinted handoff/read repair > >> > >> > > >> > > >> > > >> > (Moved to developers mailing list) > >> > > >> > Without delve to deep into to that part of the code my educated(?) > guess > >> is that this will (eventually) be solved/repaired thanks to hinted > handoff > >> and anti entropy service. > >> > > >> > > >> > On 2 maj 2010, at 18.29em, Bill Hastings wrote: > >> > > >> >> Hi > >> >> > >> >> I have looking at the bootstrap source and seem to understand it for > the > >> most part. This is what I do not follow: > >> >> > >> >> (1) New node joins and doesn't advertise its token. > >> >> (2) Requests nodes to send it data. The nodes that need to send it > data > >> first flush memtables and then transfer SSTables. > >> >> > >> >> Once the streaming is over the new node advertises its token and > starts > >> handling reads and writes correct? But what happens to keys that are > being > >> written to the old nodes after the memtables have been dumped. Looks > like > >> there is a window where keys would be going to the old nodes and not > making > >> it to the new nodes. Am I missing something here. > >> >> > >> >> -- > >> >> Cheers > >> >> Bill > >> > > >> > >> > >> > >> > >> > > > > > > -- > > Cheers > > Bill > > > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com > -- Cheers Bill
Best way to fix JMX threads leak in NodeProbe
I have discovered a JMX threads leak in NodeProbe. Here is the original email thread on the user mailing list: http://www.mail-archive.com/u...@cassandra.apache.org/msg06764.html NodePorbe creats a JMXConnector but never calls JMXConnector.close(). The use of a JMXConnector in NodeProbe is not exposed in its API. So without changing the API, my initial thought is to add a finalize() method to NodeProbe in which JMXConnector.close() is called. But I am not sure if this is the best solution. Using a finalizer many lead to memory leak since in this case NodeProbe will not be garbage collector until its finalizer is called, but in Java the finalize() method is not guaranteed to be called at any particular time. We probably don't want to create a new JMXConnector for each operation. Should we add a close() method to NodeProbe which users of NodeProbe has to call to avoid using a finalizer? Bill
Re: Best way to fix JMX threads leak in NodeProbe
I have opened a jira for this issue: https://issues.apache.org/jira/browse/CASSANDRA-1665 I will submit a patch. Bill On Tue, Oct 26, 2010 at 12:21 PM, Jonathan Ellis wrote: > Yes, we should add a close method. > On Oct 26, 2010 9:14 AM, "Bill Au" wrote: > > I have discovered a JMX threads leak in NodeProbe. Here is the original > > email thread on the user mailing list: > > > > http://www.mail-archive.com/u...@cassandra.apache.org/msg06764.html > > > > NodePorbe creats a JMXConnector but never calls JMXConnector.close(). The > > use of a JMXConnector in NodeProbe is not exposed in its API. So without > > changing the API, my initial thought is to add a finalize() method to > > NodeProbe in which JMXConnector.close() is called. But I am not sure if > > this is the best solution. Using a finalizer many lead to memory leak > since > > in this case NodeProbe will not be garbage collector until its finalizer > is > > called, but in Java the finalize() method is not guaranteed to be called > at > > any particular time. We probably don't want to create a new JMXConnector > > for each operation. Should we add a close() method to NodeProbe which > users > > of NodeProbe has to call to avoid using a finalizer? > > > > Bill >
Checksumming
how does checksumming in Cassandra work? If there is a bit rot it is detected but how is it fixed? let's say a key column has been corrupted and the corruption is detected. How is it fixed?
Re: Discussion: release quality
I think we definitely need better quality for the releases. Just looked at 1.0.3 and 1.0.4. I am willing to test out release candidate and report back my finding on the mailing list. Hopefully more folks can do that to make the testing more comprehensive. And folks with binding votes can take the testing results into account before they vote. Bill On Tue, Nov 29, 2011 at 10:14 PM, Joe Stein wrote: > I need at least a week, maybe two to promote anything to staging which is > mainly because we do weekly releases. I could introduce a 2 day turn > around but only with a more fixed type schedule. I am running 0.8.6 in > production and REALLY want to upgrade for nothing more than getting > compression ( the cost of petabytes of uncompressed data is just stupid ). > So however I can help in changing my process OR better understanding the > PMC here I am game for. > > One thing I use C* for is holding days worth of data and re-running those > days for regression on our software... simulating production... It might > not take much to reverse it. > > /* > Joe Stein > http://www.medialets.com > Twitter: @allthingshadoop > */ > > On Nov 29, 2011, at 10:04 PM, Edward Capriolo > wrote: > > > On Tue, Nov 29, 2011 at 6:16 PM, Jeremy Hanna < > jeremy.hanna1...@gmail.com>wrote: > > > >> I'd like to start a discussion about ideas to improve release quality > for > >> Cassandra. Specifically I wonder if the community can do more to help > the > >> project as a whole become more solid. Cassandra has an active and > vibrant > >> community using Cassandra for a variety of things. If we all pitch in a > >> little bit, it seems like we can make a difference here. > >> > >> Release quality is difficult, especially for a distributed system like > >> Cassandra. The core devs have done an amazing job with this considering > >> how complicated it is. Currently, there are several things in place to > >> make sure that a release is generally usable: > >> - review-then-commit > >> - 72 hour voting period > >> - at least 3 binding +1 votes > >> - unit tests > >> - integration tests > >> Then there is the personal responsibility aspect - testing a release in > a > >> staging environment before pushing it to production. > >> > >> I wonder if more could be done here to give more confidence in releases. > >> I wanted to see if there might be ways that the community could help out > >> without being too burdensome on either the core devs or the community. > >> > >> Some ideas: > >> More automation: run YCSB and stress with various setups. Maybe people > >> can rotate donating cloud instances (or simply money for them) but have > a > >> common set of scripts to do this in the source. > >> > >> Dedicated distributed test suite: I know there has been work done on > >> various distributed test suites (which is great!) but none have really > >> caught on so far. > >> > >> I know what the apache guidelines say, but what if the community could > >> help out with the testing effort in a more formal way. For example, for > >> each release to be finalized, what if there needed to be 3 community > >> members that needed to try it out in their own environment? > >> > >> What if there was a post release +1 vote for the community to sign off > on > >> - sort of a "works for me" kind of thing to reassure others that it's > safe > >> to try. So when the release email gets posted to the user list, start a > >> tradition of people saying +1 in reply if they've tested it out and it > >> works for them. That's happening informally now when there are > problems, > >> but it might be nice to see a vote of confidence. Just another idea. > >> > >> Any other ideas or variations? > > > > > > I am no software engineering guru, but whenever I +1 a hive release I > > actually do checkout the code and run a couple queries. Mostly I find > that > > because there is just so many things not unit testable like those gosh > darn > > bash scripts that launch Java applications. There have been times when > even > > after multiple patch revisions and passing unit tests something just does > > not work in the real world. So I never +1 a binary release I don't spend > an > > hour with and if possible I try twisting the knobs on any new feature or > at > > least just trying the basics.Hive is aiming for something like quarterly > > releases. >
Re: 2.0
I'm not thrilled with Thrift, but I'd like to see and hear more real world use of CQL first (Avro all the things is not that long ago). That said, a major rev /could/ do this - not start the thrift server by default. It's then a hoop jump to enable it via nodetool/yaml, and signals to the client communities and user base, where the project intends to go. Bill On 30/11/12 22:49, Jonathan Ellis wrote: As attractive as it would be to clean house, I think we owe it to our users to keep Thrift around for the forseeable future rather than orphan all Thrift-using applications (which is virtually everyone) on 1.2. On Sat, Dec 1, 2012 at 7:33 AM, Jason Brown wrote: Hi Jonathan, I'm in favor of paying off the technical debt, as well, and I wonder if there is value in removing support for thrift with 2.0? We're currently in 'do as little as possible' mode with thrift, so should we aggressively cast it off and push the binary CQL protocol? Seems like a jump to '2.0', along with the other initiatives, would be a reasonable time/milestone to do so. Thanks, -Jason On Fri, Nov 30, 2012 at 12:12 PM, Jonathan Ellis wrote: The more I think about it, the more I think we should call 1.2-next, 2.0. I'd like to spend some time paying off our technical debt: - replace supercolumns with composites (CASSANDRA-3237) - rewrite counters (CASSANDRA-4775) - improve storage engine support for wide rows - better stage management to improve latency (disruptor? lightweight threads? custom executor + queue?) - improved repair (CASSANDRA-3362, 2699) Of course, we're planning some new features as well: - triggers (CASSANDRA-1311) - improved query fault tolerance (CASSANDRA-4705) - row size limits (CASSANDRA-3929) - cql3 integration for hadoop (CASSANDRA-4421) - improved caching (CASSANDRA-1956, 2864) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
Your sense of righteousness would be better directed to code. File a patch, be useful; if this community wants maven they'll follow you. Bill Hannes Schmidt wrote: In a nutshell, I disagree with the decision to resolve https://issues.apache.org/jira/browse/CASSANDRA-697 as Won't Fix. Here's why: One of the central motivations behind Maven was to once and for all get rid of binary dependencies in source repositories. You, the Cassandra committers operating under the Apache umbrella should have no difficulty getting those lib/*.jar dependencies into the official repository. It shouldn't take more than half an hour to "mvn deploy" a handful of jars. On that note, it should be a no-brainer to actually deploy the *Apache* Cassandra JAR to the *Apache* Maven repository. Sorry for the rant but taking shortcuts like this forces every Maven user down the stream to either do the work for you, e.g to deploy the Cassandra JAR and its dependencies to their local repository or take the very same shortcut. The Hector client, for example, has a dependency on the Thrift and Cassandra JARs and it takes the shortcut of having both JARs in the repository. If I want to use the client in my own Maven-built project, I can't do so without manually deploying those two JARs along with the Hector JAR to my local repository. To add fuel to the fire, I don't think that there is a real need for two coexisting build systems for Cassandra (I'm speaking of Ant/Ivy and Maven) but even if you decide to go with Ant/Ivy, the resulting artifacts should all be accessible in a public Maven repository. This is pretty much a convention for any OS project of Cassandra's reach and maturity. -- Hannes
