[VOTE] Release Apache Cassandra 1.0.7
It's a new year, quite a bunch of fixes since 1.0.6, feels like it's time to do a new release. I thus propose the following artifacts for release as 1.0.7. Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/apache-cassandra/1.0.7/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-057/ The artifacts as well as the debian package are also available here: http://people.apache.org/~slebresne/ Note that I had to adapt a little bit to the switch to git. In particular, instead of using sha1 to mark the tentative commit of a release, I've decided to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the vote passes, I'll delete this temporary tag and create the actual cassandra-1.0.7 tag. My rational for not creating the final tag right away is that: - I want it to be clear 1.0.7 is not yet released - If the vote fails, we would have to delete the tag anyway If someone has a problem with that, let me know. The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/UTfwn (CHANGES.txt) [2]: http://goo.gl/EHlRp (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 1.0.7
-0: H may have to rework somewhat the pom generation now that moved to GIT... e.g. see https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/cassandra-parent/1.0.7/cassandra-parent-1.0.7.pom at XPath /project/scm Those are SVN urls... should be git urls... I don't see this as blocking this release, but if somebody can create a JIRA for me I'll find some time to fix the URL generation... or maybe we just remove the url generation altogether as being GIT, the GIT urls don't include a branch details so the URL could just be static... but in any case this is POMs so I'd prefer if I sort it out. -Stephen On 12 January 2012 11:36, Sylvain Lebresne wrote: > It's a new year, quite a bunch of fixes since 1.0.6, feels like it's time to > do a new release. I thus propose the following artifacts for release as 1.0.7. > > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/apache-cassandra/1.0.7/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-057/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > Note that I had to adapt a little bit to the switch to git. In particular, > instead of using sha1 to mark the tentative commit of a release, I've decided > to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the > vote passes, I'll delete this temporary tag and create the actual > cassandra-1.0.7 tag. My rational for not creating the final tag right away is > that: > - I want it to be clear 1.0.7 is not yet released > - If the vote fails, we would have to delete the tag anyway > If someone has a problem with that, let me know. > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/UTfwn (CHANGES.txt) > [2]: http://goo.gl/EHlRp (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 1.0.7
On Thu, Jan 12, 2012 at 12:56 PM, Stephen Connolly wrote: > -0: H may have to rework somewhat the pom generation now that > moved to GIT... > > e.g. see > https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/cassandra-parent/1.0.7/cassandra-parent-1.0.7.pom > at XPath /project/scm > > Those are SVN urls... should be git urls... > > I don't see this as blocking this release, Neither do I. > but if somebody can create > a JIRA for me I'll find some time to fix the URL generation... or > maybe we just remove the url generation altogether as being GIT, the > GIT urls don't include a branch details so the URL could just be > static... but in any case this is POMs so I'd prefer if I sort it out. There you go: https://issues.apache.org/jira/browse/CASSANDRA-3732 > > -Stephen > > On 12 January 2012 11:36, Sylvain Lebresne wrote: >> It's a new year, quite a bunch of fixes since 1.0.6, feels like it's time to >> do a new release. I thus propose the following artifacts for release as >> 1.0.7. >> >> Git: >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative >> Artifacts: >> https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/apache-cassandra/1.0.7/ >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecassandra-057/ >> >> The artifacts as well as the debian package are also available here: >> http://people.apache.org/~slebresne/ >> >> Note that I had to adapt a little bit to the switch to git. In particular, >> instead of using sha1 to mark the tentative commit of a release, I've decided >> to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the >> vote passes, I'll delete this temporary tag and create the actual >> cassandra-1.0.7 tag. My rational for not creating the final tag right away is >> that: >> - I want it to be clear 1.0.7 is not yet released >> - If the vote fails, we would have to delete the tag anyway >> If someone has a problem with that, let me know. >> >> The vote will be open for 72 hours (longer if needed). >> >> [1]: http://goo.gl/UTfwn (CHANGES.txt) >> [2]: http://goo.gl/EHlRp (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 1.0.7
On 12 January 2012 13:27, Sylvain Lebresne wrote: > On Thu, Jan 12, 2012 at 12:56 PM, Stephen Connolly > wrote: >> -0: H may have to rework somewhat the pom generation now that >> moved to GIT... >> >> e.g. see >> https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/cassandra-parent/1.0.7/cassandra-parent-1.0.7.pom >> at XPath /project/scm >> >> Those are SVN urls... should be git urls... >> >> I don't see this as blocking this release, > > Neither do I. > >> but if somebody can create >> a JIRA for me I'll find some time to fix the URL generation... or >> maybe we just remove the url generation altogether as being GIT, the >> GIT urls don't include a branch details so the URL could just be >> static... but in any case this is POMs so I'd prefer if I sort it out. > > There you go: https://issues.apache.org/jira/browse/CASSANDRA-3732 > Thanks >> >> -Stephen >> >> On 12 January 2012 11:36, Sylvain Lebresne wrote: >>> It's a new year, quite a bunch of fixes since 1.0.6, feels like it's time to >>> do a new release. I thus propose the following artifacts for release as >>> 1.0.7. >>> >>> Git: >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative >>> Artifacts: >>> https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/apache-cassandra/1.0.7/ >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachecassandra-057/ >>> >>> The artifacts as well as the debian package are also available here: >>> http://people.apache.org/~slebresne/ >>> >>> Note that I had to adapt a little bit to the switch to git. In particular, >>> instead of using sha1 to mark the tentative commit of a release, I've >>> decided >>> to use a lightweight tag, namely 1.0.7-tentative. My goal being that once >>> the >>> vote passes, I'll delete this temporary tag and create the actual >>> cassandra-1.0.7 tag. My rational for not creating the final tag right away >>> is >>> that: >>> - I want it to be clear 1.0.7 is not yet released >>> - If the vote fails, we would have to delete the tag anyway >>> If someone has a problem with that, let me know. >>> >>> The vote will be open for 72 hours (longer if needed). >>> >>> [1]: http://goo.gl/UTfwn (CHANGES.txt) >>> [2]: http://goo.gl/EHlRp (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 1.0.7
On Jan 12, 2012, at 5:36 AM, Sylvain Lebresne wrote:
> Note that I had to adapt a little bit to the switch to git. In particular,
> instead of using sha1 to mark the tentative commit of a release, I've decided
> to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the
> vote passes, I'll delete this temporary tag and create the actual
> cassandra-1.0.7 tag. My rational for not creating the final tag right away is
> that:
> - I want it to be clear 1.0.7 is not yet released
> - If the vote fails, we would have to delete the tag anyway
> If someone has a problem with that, let me know.
I'm -1 on not announcing a specific commit hash, for historical purposes. Tags
can be changed (and probably will be under this approach, if we have to
reroll), or deleted, and they may not even agree between different repos. With
a sha1, there is no ambiguity about which exact snapshot is being (or was)
voted on.
It's still probably a good idea to have a tag, as you say
("prospective/1.0.7/1" maybe? I find tag namespaces come in handy), but it
should be intended for convenience only.
p
Re: [VOTE] Release Apache Cassandra 1.0.7
Sorry to be That Guy, but CASSANDRA-3733 (just fixed by Brandon) can cause OOM during hint replay similar to the ones in CASSANDRA-3681. On Thu, Jan 12, 2012 at 5:36 AM, Sylvain Lebresne wrote: > It's a new year, quite a bunch of fixes since 1.0.6, feels like it's time to > do a new release. I thus propose the following artifacts for release as 1.0.7. > > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/apache-cassandra/1.0.7/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-057/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > Note that I had to adapt a little bit to the switch to git. In particular, > instead of using sha1 to mark the tentative commit of a release, I've decided > to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the > vote passes, I'll delete this temporary tag and create the actual > cassandra-1.0.7 tag. My rational for not creating the final tag right away is > that: > - I want it to be clear 1.0.7 is not yet released > - If the vote fails, we would have to delete the tag anyway > If someone has a problem with that, let me know. > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/UTfwn (CHANGES.txt) > [2]: http://goo.gl/EHlRp (NEWS.txt) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: [VOTE] Release Apache Cassandra 1.0.7
On Thu, Jan 12, 2012 at 4:40 PM, paul cannon wrote: > On Jan 12, 2012, at 5:36 AM, Sylvain Lebresne wrote: >> Note that I had to adapt a little bit to the switch to git. In particular, >> instead of using sha1 to mark the tentative commit of a release, I've decided >> to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the >> vote passes, I'll delete this temporary tag and create the actual >> cassandra-1.0.7 tag. My rational for not creating the final tag right away is >> that: >> - I want it to be clear 1.0.7 is not yet released >> - If the vote fails, we would have to delete the tag anyway >> If someone has a problem with that, let me know. > > I'm -1 on not announcing a specific commit hash, for historical purposes. > Tags can be changed (and probably will be under this approach, if we have to > reroll), or deleted, and they may not even agree between different repos. > With a sha1, there is no ambiguity about which exact snapshot is being (or > was) voted on. I'm good adding the commit sha1 in the vote announce mail, the tag is just for my own convenience and the one of those testing. -- Sylvain
Re: [VOTE CLOSED] Release Apache Cassandra 1.0.7
On Thu, Jan 12, 2012 at 6:07 PM, Jonathan Ellis wrote: > Sorry to be That Guy, but CASSANDRA-3733 (just fixed by Brandon) can > cause OOM during hint replay similar to the ones in CASSANDRA-3681. Ok, I'll rerolled. The vote is thus closed and I'll start a new one with CASSANDRA-3681 (and probably CASSANDRA-3635) shortly. -- Sylvain > > On Thu, Jan 12, 2012 at 5:36 AM, Sylvain Lebresne > wrote: >> It's a new year, quite a bunch of fixes since 1.0.6, feels like it's time to >> do a new release. I thus propose the following artifacts for release as >> 1.0.7. >> >> Git: >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative >> Artifacts: >> https://repository.apache.org/content/repositories/orgapachecassandra-057/org/apache/cassandra/apache-cassandra/1.0.7/ >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecassandra-057/ >> >> The artifacts as well as the debian package are also available here: >> http://people.apache.org/~slebresne/ >> >> Note that I had to adapt a little bit to the switch to git. In particular, >> instead of using sha1 to mark the tentative commit of a release, I've decided >> to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the >> vote passes, I'll delete this temporary tag and create the actual >> cassandra-1.0.7 tag. My rational for not creating the final tag right away is >> that: >> - I want it to be clear 1.0.7 is not yet released >> - If the vote fails, we would have to delete the tag anyway >> If someone has a problem with that, let me know. >> >> The vote will be open for 72 hours (longer if needed). >> >> [1]: http://goo.gl/UTfwn (CHANGES.txt) >> [2]: http://goo.gl/EHlRp (NEWS.txt) > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com
Re: FYI Cassandra Git Repo on Apache servers
On Tue, Jan 10, 2012 at 11:40 PM, Dave Brosius wrote: > Greetings, > > I wanted to mention this to folks who may be running into this issue. A > user on IRC reporting that cloning the cassandra repo on the apache servers > > http://git-wip-us.apache.org/repos/asf/cassandra.git > > fails with error git.apache.org is updating now and the github mirror should be in a few hours. -Brandon
Cache Row Size
I'm using ConcurrentLinkedHashCacheProvider and my data on disk is about 4gb, but the RAM used by the cache is around 25gb. I have 70k columns per row, and only about 2500 rows – so a lot more columns than rows. has there been any discussion or JIRAs discussing reducing the size of the cache? I can understand the overhead for column names, etc, but the ratio seems a bit distorted. I'm tracing through the code, so any pointers to help me understand is appreciated thx
Re: Cache Row Size
Twitter engineers reported a similar experience [1] (slide 32). They managed to reduce by 45% memory usage with cache provider backed by Memcached. Lately I've been worrying a lot with the swelling of Java objects. In 64-bit servers are tried using the JVM option -XX:+UseCompressedOops? This presentation [2] made me more worried. But let us know any progress in your experience. :-) [1] http://www.scribd.com/doc/59830692/Cassandra-at-Twitter [2] http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf -- Bruno Leonardo Gonçalves On Thu, Jan 12, 2012 at 22:07, Todd Burruss wrote: > I'm using ConcurrentLinkedHashCacheProvider and my data on disk is about > 4gb, but the RAM used by the cache is around 25gb. I have 70k columns per > row, and only about 2500 rows – so a lot more columns than rows. has there > been any discussion or JIRAs discussing reducing the size of the cache? I > can understand the overhead for column names, etc, but the ratio seems a > bit distorted. > > I'm tracing through the code, so any pointers to help me understand is > appreciated > > thx >
Re: Cache Row Size
8x is pretty normal for JVM and bookkeeping overhead with the CLHCP. The SerializedCacheProvider is the default in 1.0 and is much lighter-weight. On Thu, Jan 12, 2012 at 6:07 PM, Todd Burruss wrote: > I'm using ConcurrentLinkedHashCacheProvider and my data on disk is about 4gb, > but the RAM used by the cache is around 25gb. I have 70k columns per row, > and only about 2500 rows – so a lot more columns than rows. has there been > any discussion or JIRAs discussing reducing the size of the cache? I can > understand the overhead for column names, etc, but the ratio seems a bit > distorted. > > I'm tracing through the code, so any pointers to help me understand is > appreciated > > thx -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Prepared Statement support (CASSANDRA-2475)
Hi Eric, Thanks for the follow up. I see the point of "increased complexity on the clients" keep coming up in the references, but the truth is that we've pretty much all had to abstract serialization to some degree or another just to keep up with changes. At least in the case of Hector, dealing directly with the byte encoded form would be easier. If it's a couple of ticks faster on the server side, that's fine with me. Thanks for thinking of us though :) On Wed, Jan 11, 2012 at 3:14 PM, Eric Evans wrote: > On Wed, Dec 14, 2011 at 5:49 PM, Eric Evans wrote: >> Thanks to the hard work of Rick Shaw, prepared statements >> (https://issues.apache.org/jira/browse/CASSANDRA-2475) has been >> committed to trunk. However, before you use it, be advised that the >> API might be changing in the next few days. >> >> If it does change, it should be limited to moving the bind parameters >> from string to bytes, (pending a comparison of the performance). I'll >> send another email with the changes, if any, after the API is expected >> to be stable. > > To follow up on this, and to draw the attention of the folks on > client-dev@ who have some stake in this: > > There was some discussion in #2475, and later in #3634, about whether > clients would supply string, or binary bind arguments for a prepared > statement. > > I encourage anyone that is interesting to read through the tickets, > but the short version is that since Cassandra uses binary values > internally, having the clients serialize types to binary would be more > performant than having Cassandra do it, while string arguments result > in simpler, easier to code drivers. Since it boils down to a question > of trading one thing for another, we agreed to do some performance > testing so that we could at least put some real numbers to it. > > That performance testing is complete. Again, I encourage you to check > out the results[2] yourself, but they could be summarized by saying > that most operations (reads, counter increments, inserts with an > indexed columns) are equivalent. It mostly boils down to standard > inserts which are 10% faster when using binary arguments than for > string arguments. It's worth noting (because either way it's awesome > :)), that even with string arguments, writes using prepared statements > are 5% faster than RPC (16% with binary arguments). > > We need to drive a stake in the ground Real Soon Now, but since this > issue directly affects client maintainers, I'd be interested in > hearing what they had to say about this (either here, or in the > ticket). > > Cheers, > > > [1]: https://issues.apache.org/jira/browse/CASSANDRA-2475 > [2]: https://issues.apache.org/jira/browse/CASSANDRA-3634 > > > -- > Eric Evans > Acunu | http://www.acunu.com | @acunu
Re: Cache Row Size
thx for the info. I'm a bit leary on the memcached (or any out-of-process cache) because of coherency issues: https://issues.apache.org/jira/browse/CASSANDRA-2701 On 1/12/12 5:50 PM, "Bruno Leonardo Gonçalves" wrote: >Twitter engineers reported a similar experience [1] (slide 32). They >managed to reduce by 45% memory usage with cache provider backed by >Memcached. Lately I've been worrying a lot with the swelling of Java >objects. In 64-bit servers are tried using the JVM option >-XX:+UseCompressedOops? This presentation [2] made me more worried. But >let us know any progress in your experience. :-) > >[1] http://www.scribd.com/doc/59830692/Cassandra-at-Twitter >[2] >http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient- >java-tutorial.pdf > >-- >Bruno Leonardo Gonçalves > > >On Thu, Jan 12, 2012 at 22:07, Todd Burruss wrote: > >> I'm using ConcurrentLinkedHashCacheProvider and my data on disk is about >> 4gb, but the RAM used by the cache is around 25gb. I have 70k columns >>per >> row, and only about 2500 rows – so a lot more columns than rows. has >>there >> been any discussion or JIRAs discussing reducing the size of the cache? >> I >> can understand the overhead for column names, etc, but the ratio seems a >> bit distorted. >> >> I'm tracing through the code, so any pointers to help me understand is >> appreciated >> >> thx >>
Re: Cache Row Size
I can't use SerializedCacheProvider with wide rows. My tests show the performance of it is rediculously slow because of the copying to heap for each get Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Jonathan Ellis [jbel...@gmail.com] Received: Thursday, 12 Jan 2012, 6:18pm To: dev@cassandra.apache.org [dev@cassandra.apache.org] Subject: Re: Cache Row Size 8x is pretty normal for JVM and bookkeeping overhead with the CLHCP. The SerializedCacheProvider is the default in 1.0 and is much lighter-weight. On Thu, Jan 12, 2012 at 6:07 PM, Todd Burruss wrote: > I'm using ConcurrentLinkedHashCacheProvider and my data on disk is about 4gb, > but the RAM used by the cache is around 25gb. I have 70k columns per row, > and only about 2500 rows – so a lot more columns than rows. has there been > any discussion or JIRAs discussing reducing the size of the cache? I can > understand the overhead for column names, etc, but the ratio seems a bit > distorted. > > I'm tracing through the code, so any pointers to help me understand is > appreciated > > thx -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Cache Row Size
after looking through the code it seems fairly straight forward to create some different cache providers and try some things. has anyone tried ehcache w/o persistence? I see this JIRA https://issues.apache.org/jira/browse/CASSANDRA-1945 but the main complaint was the disk serialization, which I don't think anyone wants. On 1/12/12 6:18 PM, "Jonathan Ellis" wrote: >8x is pretty normal for JVM and bookkeeping overhead with the CLHCP. > >The SerializedCacheProvider is the default in 1.0 and is much >lighter-weight. > >On Thu, Jan 12, 2012 at 6:07 PM, Todd Burruss >wrote: >> I'm using ConcurrentLinkedHashCacheProvider and my data on disk is >>about 4gb, but the RAM used by the cache is around 25gb. I have 70k >>columns per row, and only about 2500 rows so a lot more columns than >>rows. has there been any discussion or JIRAs discussing reducing the >>size of the cache? I can understand the overhead for column names, etc, >>but the ratio seems a bit distorted. >> >> I'm tracing through the code, so any pointers to help me understand is >>appreciated >> >> thx > > > >-- >Jonathan Ellis >Project Chair, Apache Cassandra >co-founder of DataStax, the source for professional Cassandra support >http://www.datastax.com
Re: Cache Row Size
The serializing cache is basically optimal. Your problem is really that row cache is not designed for wide rows at all. See https://issues.apache.org/jira/browse/CASSANDRA-1956 On Thu, Jan 12, 2012 at 10:46 PM, Todd Burruss wrote: > after looking through the code it seems fairly straight forward to create > some different cache providers and try some things. > > has anyone tried ehcache w/o persistence? I see this JIRA > https://issues.apache.org/jira/browse/CASSANDRA-1945 but the main > complaint was the disk serialization, which I don't think anyone wants. > > > On 1/12/12 6:18 PM, "Jonathan Ellis" wrote: > >>8x is pretty normal for JVM and bookkeeping overhead with the CLHCP. >> >>The SerializedCacheProvider is the default in 1.0 and is much >>lighter-weight. >> >>On Thu, Jan 12, 2012 at 6:07 PM, Todd Burruss >>wrote: >>> I'm using ConcurrentLinkedHashCacheProvider and my data on disk is >>>about 4gb, but the RAM used by the cache is around 25gb. I have 70k >>>columns per row, and only about 2500 rows so a lot more columns than >>>rows. has there been any discussion or JIRAs discussing reducing the >>>size of the cache? I can understand the overhead for column names, etc, >>>but the ratio seems a bit distorted. >>> >>> I'm tracing through the code, so any pointers to help me understand is >>>appreciated >>> >>> thx >> >> >> >>-- >>Jonathan Ellis >>Project Chair, Apache Cassandra >>co-founder of DataStax, the source for professional Cassandra support >>http://www.datastax.com > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Welcome to our newest committer, Vijay Parthasarathy!
The Apache Cassandra PMC has voted to add Vijay as a committer. Thank you Vijay, and we look forward to continuing to work with you! -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Welcome to our newest committer, Vijay Parthasarathy!
Thanks Jonathan and Cassandra PMC, I am all set for 2.0 :) Regards, On Thu, Jan 12, 2012 at 10:06 PM, Jonathan Ellis wrote: > The Apache Cassandra PMC has voted to add Vijay as a committer. Thank > you Vijay, and we look forward to continuing to work with you! > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com >
