Re: Contribution to Cassandra Community and Branching Strategy

[Dave Brosius]

Thanks!

Not sure if i get fully your question, but you can see the various 
branches, and tags in use here


https://git-wip-us.apache.org/repos/asf?p=cassandra.git

Typically, if you are targeting a patch for an older release, the patch 
should be against that older branch, and hopefully it will automerge 
forward.


If you know this is not the case, then please supply different patch 
files for branches.



You can assign your self to an issue in JIRA (if you can't let us know, 
and we can add you as a contributor).
It may be wise (depending on the issue) to discuss in general how you 
will attack the problem first, to get feedback, so
you don't spend alot of energy first only to have to potentially redo, 
or such.
But yes, then attach the patch file. *.txt are preferred as they can be 
viewed directly from the web.


HTH,
dave

On 2015-05-18 14:48, Anuj Wadehra wrote:

Hi,
I want to submit patch for Cassandra JIRA tickets.

I have some questions:
1. As per http://wiki.apache.org/cassandra/HowToContribute, we need to
clone trunk and provide patch on that. So, I need to understand how
this patch is going to be merged in 2.0.x and 2.1.x ?
2. Where can I get the detailed Branching strategy followed by 
Cassandra?

3. How to say "that I am looking into a JIRA"? Should I just put a
patch when ready?
ThanksAnuj Wadehra
 

Re: [jira] [Created] (CASSANDRA-9506) casandra wouldn't start

[Dave Brosius]

That api was changed in commit 2385dc2d912391

I expect that StorageService just didn't get recompiled after the change 
came to ClientState


I'd recommend git pull ing again, and doing

ant realclean

ant jar




On 05/28/2015 08:27 PM, Chandran Anjur Narasimhan (JIRA) wrote:

Chandran Anjur Narasimhan created CASSANDRA-9506:


  Summary: casandra wouldn't start
  Key: CASSANDRA-9506
  URL: https://issues.apache.org/jira/browse/CASSANDRA-9506
  Project: Cassandra
   Issue Type: Bug
   Components: Core
  Environment: OS X 10.10.2
 Reporter: Chandran Anjur Narasimhan
 Priority: Critical
  Fix For: 3.x


Pull the latest snapshot today (5/28), compiled successfully. Throws exception 
while starting cassandra:

Java and Ant version

NCHAN-M-D0LZ:bin nchan$ $JAVA_HOME/bin/java -version
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
NCHAN-M-D0LZ:bin nchan$
NCHAN-M-D0LZ:bin nchan$ ant -version
Apache Ant(TM) version 1.9.4 compiled on April 29 2014
NCHAN-M-D0LZ:bin nchan$

cassandra version:
===
INFO  00:19:06 Cassandra version: 3.0.0-SNAPSHOT

git show output:
==
NCHAN-M-D0LZ:bin nchan$ git show
commit 64f1eadd5de8d2829087d7730516f9406f139c7a
Merge: 74b0b8a 7d06762
Author: T Jake Luciani 
Date:   Thu May 28 13:35:34 2015 -0400

 Merge branch 'cassandra-2.2' into trunk

git log snip
=
NCHAN-M-D0LZ:bin nchan$ git log
commit 64f1eadd5de8d2829087d7730516f9406f139c7a
Merge: 74b0b8a 7d06762
Author: T Jake Luciani 
Date:   Thu May 28 13:35:34 2015 -0400

 Merge branch 'cassandra-2.2' into trunk

commit 7d0676215ea1f834f9475f18f5853d80b261e29d
Author: T Jake Luciani 
Date:   Thu May 28 13:33:41 2015 -0400

 Revert refactor of doValidationCompaction which caused breaks from 9431

commit 74b0b8acc8349b4ee1236416e68a1175d3a90933
Merge: ea36ae9 1de8e39
Author: Tyler Hobbs 
Date:   Thu May 28 12:16:55 2015 -0500

 Merge branch 'cassandra-2.2' into trunk

commit 1de8e39ed5a00795ea16111931ca081024b4f325
Author: blerer 
Date:   Thu May 28 12:16:03 2015 -0500

 Disallow frozen<> types in functions
 
 Patch by Benjamin Lerer; reviewed by Tyler Hobbs for CASSANDRA-9441


Exception while trying to start cassandra

INFO  00:19:06 Compacting (515b8b70-0598-11e5-99de-8fc0c9ad1f24) 
[/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-17-big-Data.db:level=0,
 
/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-24-big-Data.db:level=0,
 
/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-19-big-Data.db:level=0,
 
/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-18-big-Data.db:level=0,
 
/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-23-big-Data.db:level=0,
 
/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-20-big-Data.db:level=0,
 
/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-21-big-Data.db:level=0,
 
/Users/nchan/Programs/apache/cassandra-3.0/bin/./../data/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/la-22-big-Data.db:level=0,
 ]
INFO  00:19:06 Cassandra version: 3.0.0-SNAPSHOT
INFO  00:19:06 Thrift API version: 20.1.0
Exception (java.lang.NoSuchMethodError) encountered during startup: 
org.apache.cassandra.service.ClientState.getCQLSupportedVersion()[Lorg/apache/cassandra/utils/SemanticVersion;
java.lang.NoSuchMethodError: 
org.apache.cassandra.service.ClientState.getCQLSupportedVersion()[Lorg/apache/cassandra/utils/SemanticVersion;
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:591)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:583)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:280)
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:452)
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:558)
ERROR 00:19:06 Exception encountered during startup
java.lang.NoSuchMethodError: 
org.apache.cassandra.service.ClientState.getCQLSupportedVersion()[Lorg/apache/cassandra/utils/SemanticVersion;
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:591) 
~[main/:na]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:

Re: Feedback of my Phd work in Cassandra Project

[Dave Brosius]

 >> Do these results surprise you? Can you think in any explanation for the
results?

That NodeCmd and NodeProbe are highly correlated is expected, 
NodeCmd delegates it's functionality to NodeProbe.



Do you think that our rate of prediction is good enough to be used for

building tool support for the software community?

Curious to know what your conjecture is about the correlation of 
files and how it can help you develop better. I suppose if two files are 
perfectly or near perfectly correlated, and you find a commit with only 
one file, you might be led to the conclusion that a mistake was made 
perhaps. Even that is probably dubious. Other than that, not sure what 
the benefit is.



Do you have any suggestion on what can be done to improve the change

recommendation?

Might be worth looking at package correlations, I could see where a 
particular package was say, spring beans, and any file in this directory 
is likely to be committed along side a spring xml file (if those are 
still used).



On 12/09/2015 06:25 PM, Igor Wiese wrote:

Hi, Cassandra Community.

My name is Igor Wiese, phd Student from Brazil. I am investigating two
important questions: What makes two files change together? Can we predict
when they are going to co-change again?

I've tried to investigate this question on the Cassandra project. I've
collected data from issue reports, discussions and commits and using some
machine learning techniques to build a prediction model.

I collected a total of 1197 commits in which a pair of files changed
together and could correctly predict 48% commits. These were the most
useful information for predicting co-changes of files:

- number of lines of code added,

- number of lines of code removed,

- sum of number of lines of code added, modified and removed,

- number of words used to describe and discuss the issues, and

- median value of closeness, a social network measure obtained from issue
comments.

To illustrate, consider the following example from our analysis. For
release 1.0, the files "cassandra/tools/NodeCmd.java" and
"cassandra/tools/NodeProbe.java" changed together in 16 commits. In another
6 commits, only the first file changed, but not the second. Collecting
contextual information for each commit made to first file in the previous
release, we were able to predict all 13 commits in which both files changed
together in release 1.0, and we only issued 2 false positives. For this
pair of files, the most important contextual information was the number of
lines of code added, removed and modified in each commit, the number of
words used to describe and discuss the issues and the number of comments in
the issues.

- Do these results surprise you? Can you think in any explanation for the
results?

- Do you think that our rate of prediction is good enough to be used for
building tool support for the software community?

- Do you have any suggestion on what can be done to improve the change
recommendation?

You can visit our webpage to inspect the results in details:
http://flosscoach.com/index.php/17-cochanges/66-cassandra

All the best,
Igor Wiese
Phd Candidate

Re: Proposal: deprecate Thrift now and remove support in 4.0

[Dave Brosius]

+1 now

On 12/28/2015 09:26 AM, Jonathan Ellis wrote:

Thrift has been officially frozen for almost two years and unofficially for
longer. [1]  Meanwhile, maintaining Thrift support through changes like
8099 has been a substantial investment.

I propose deprecating Thrift now and removing support in 4.0, i.e. Nov 2016
if tick-tock goes as planned.

I note that only 7% of our survey respondents [2] are using Thrift-only,
and and those users are often on old releases (1.1 and 1.2), i.e. unlikely
to upgrade to 4.x anyway.

Another 20% of users are using a mix of Thrift and CQL.  Some have been
unable to completely migrate because CQL doesn’t quite provide every
feature from Thrift.  The last such outstanding issue is mixing static and
dynamic Thrift “columns” in a single table.  We have an issue open to
address this [3].

I think it is reasonable to either deprecate Thrift immediately in 3.2 or
to wait until 10857 is committed in 3.4.

[1]
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201403.mbox/%3ccaldd-zim6knmr7f_zcpvpqk0b2g919tttathiuofnvlztaw...@mail.gmail.com%3E

[2]
https://docs.google.com/spreadsheets/d/1FegCArZgj2DNAjNkcXi1n2Y1Kfvf6cdZedkMPYQdvC0/edit#gid=0

[3] https://issues.apache.org/jira/browse/CASSANDRA-10857

Re: Wiki

[Dave Brosius]

Done

On 04/03/2016 10:56 AM, Pedro Gordo wrote:

Hi Jonathan

I forgot about that, sorry. It's "PedroGordo".

Best regards

Pedro Gordo

On 3 April 2016 at 15:41, Jonathan Ellis  wrote:


Hi Pedro,

We need your wiki username to add it to the editors list.  Thanks!

On Sun, Apr 3, 2016 at 9:15 AM, Pedro Gordo 
wrote:


Hi

I would like to contribute to C* Wiki if possible, so sending the email

as

requested on the wiki's front page. The reason for this is that the
nodetool
page  is missing the
"gossipinfo" command. I haven't checked if there's more commands missing.

Let me know if I can help!

Best regards
Pedro Gordo




--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: [Proposal] Mandatory comments

[Dave Brosius]

A less controversial tact would be to actively solicit input from 
contributors, etc, about what methods/classes are confusing, and put 
those classes/methods on a priority list for adding good javadoc. When 
that list goes to ~0, you've probably done enough.


The key tho is to actively solicit, and make it easy to do so. It's 
important to differentiate the list being 0 because you've done a good 
job, and 0 because people didn't know about it, or was to difficult to 
ask for.


--dave

---


On 2016-05-05 11:46, Jack Krupansky wrote:
FWIW, I recently wrote up a bunch of notes on Code Quality and 
published
them on Medium. There are notes on comments and consistency and 
boilerplate

buried in there.

WARNING: There's a lot of stuff there and it is not for the  faint of 
heart

or those not truly committed to code quality.

tl;dr - I'm not a fan of boiler plate just to say you did something, 
but...

I am a fan of consistency, but that doesn't mean every situation is the
same, just that similar situations should be treated similarly - unless
there is some reasonable reason to do otherwise.

See:
https://medium.com/@jackkrupansky/code-quality-preamble-932626a3131c#.ynrjbryus
https://medium.com/@jackkrupansky/software-and-product-quality-notes-no-1-346ab1d8df24#.xzg1ihuxb
https://medium.com/@jackkrupansky/code-quality-notes-no-1-4dc522a5e29c#.cm7tan2zu
https://medium.com/@jackkrupansky/code-quality-notes-no-2-7939377b73c6#.zco8oq3dj


-- Jack Krupansky

On Thu, May 5, 2016 at 10:55 AM, Eric Evans 
wrote:

On Wed, May 4, 2016 at 12:14 PM, Jonathan Ellis  
wrote:

> On Wed, May 4, 2016 at 2:27 AM, Sylvain Lebresne 
> wrote:
>
>> On Tue, May 3, 2016 at 6:57 PM, Eric Evans 
>> wrote:
>>
>> > On Mon, May 2, 2016 at 11:26 AM, Sylvain Lebresne <
sylv...@datastax.com>
>> > wrote:
>> > > Looking forward to other's opinions and feedbacks on this proposal.
>> >
>> > We might want to leave just a little wiggle room for judgment on the
>> > part of the reviewer, for the very simple cases.  Documenting
>> > something like setFoo(int) with "Sets foo" can get pretty tiresome for
>> > everyone, and doesn't add any value.
>> >
>>
>> I knew someone was going to bring this :). In principle, I don't really
>> disagree. In practice though,
>> I suspect it's sometimes just easier to adhere to such simple rule
somewhat
>> strictly. In particular,
>> I can guarantee that we don't all agree where the border lies between
what
>> warrants a javadoc
>> and what doesn't. Sure, there is a few cases where you're just
paraphrasing
>> the method name
>> (and while it might often be the case for getters and setters, it's
worth
>> noting that we don't really
>> do much of those in C*), but how hard is it to write a one line comment?
>> Surely that's a negligeable
>> part of writing a patch and we're not that lazy.
>>
>
> I'm more concerned that this kind of boilerplate commenting obscures
rather
> than clarifies.  When I'm reading code i look for comments to help me
> understand key points, points that aren't self-evident.  If we institute
a
> boilerplate "comment everything" rule then I lose that signpost.

This.

Additionally you could also probably argue that it obscures the true
purpose to leaving a comment; It becomes a check box to tick, having
some javadoc attached to every method, rather than genuinely looking
for the value that could be added with quality comments (or even
altering the approach so that the code is more obvious in the absence
of them).

The reason I suggested "wiggle room", is that I think everyone
basically agrees that the default should be to leave good comments
(and that that hasn't been the case), that we should start making this
a requirement to successful review, and that we can afford to leave
some room for judgment on the part of the reviewer.  Worse-case is
that we find in doing so that there isn't much common ground on what
constitutes a quality comment versus useless boilerplate, and that we
have to remove any wiggle room and make it 100% mandatory (I don't
think that will (has to) be the case, though).


--
Eric Evans
john.eric.ev...@gmail.com

Re: Wiki contributor

[Dave Brosius]

you should be added

On 06/01/2016 05:03 PM, Mahdi Mohammadi wrote:

Hi,

Would someone please add me to the Wiki 
contributors?

Username: MahdiMohammadi 

Best Regards

Re: Cassandra Java Driver and DataStax

[Dave Brosius]

There are many drivers for cassandra, supplied by various individuals 
and groups, one of those drivers was started by people at datastax which 
is available as an opensource project.


The open source project is not open to any random person on the internet 
to commit to (just like any open source project), so i suppose in that 
regard there is some 'control'. But i doubt that is what you are fishing 
for.


--dave

(not affiliated with datastax)

On 06/03/2016 10:29 PM, Chris Mattmann wrote:

Hi All,

I’m investigating something a few ASF members contacted
me about and pointed out, so I’m hoping you can help
guide me here as a community. I have heard that a company,
DataStax, whose marketing material mentions it as the only
Cassandra vendor, “controls” the Java Driver for Apache
Cassandra.

Of course, no company “controls” our projects or its code,
so I told the folks that mentioned it to me that I’d investigate
with my board hat on.

I’d like to hear the community’s thoughts here on this. Does
anyone in the community see this “controlling” behavior going
on? Please speak up, as I’d like to get to the bottom of it,
and I’ll be around on the lists, doing some homework and reading
up on the archives to see what’s up.

Thanks for any help you can provide in rooting this out.

Cheers,
Chris

Re: Cassandra Java Driver and DataStax

[Dave Brosius]

Here are just some of the drivers.

https://wiki.apache.org/cassandra/ClientOptions

There's tons more for the older thrift interface

https://wiki.apache.org/cassandra/ClientOptionsThrift

Being as the new interface is, well, newer, there are less options.
If you'd like to write your own and build a better one, fame and fortune 
awaits you.


--dave

On 06/03/2016 10:58 PM, Johan Edstrom wrote:

How many Java drivers could you point out?
Doesn’t it strike you slightly off that you’d not have a driver for a DB
in the same project you found the DB?




On Jun 3, 2016, at 8:51 PM, Dave Brosius  wrote:

There are many drivers for cassandra, supplied by various individuals and 
groups, one of those drivers was started by people at datastax which is 
available as an opensource project.

The open source project is not open to any random person on the internet to 
commit to (just like any open source project), so i suppose in that regard 
there is some 'control'. But i doubt that is what you are fishing for.

--dave

(not affiliated with datastax)

On 06/03/2016 10:29 PM, Chris Mattmann wrote:

Hi All,

I’m investigating something a few ASF members contacted
me about and pointed out, so I’m hoping you can help
guide me here as a community. I have heard that a company,
DataStax, whose marketing material mentions it as the only
Cassandra vendor, “controls” the Java Driver for Apache
Cassandra.

Of course, no company “controls” our projects or its code,
so I told the folks that mentioned it to me that I’d investigate
with my board hat on.

I’d like to hear the community’s thoughts here on this. Does
anyone in the community see this “controlling” behavior going
on? Please speak up, as I’d like to get to the bottom of it,
and I’ll be around on the lists, doing some homework and reading
up on the archives to see what’s up.

Thanks for any help you can provide in rooting this out.

Cheers,
Chris

Re: ant warning - multiple versions of ant detected in path for junit

[Dave Brosius]

It's just a warning, so hopefully isn't an issue. It's possible that adding

includeantruntime="false"

to the  tasks may help this, altho the combination of junit and 
forking might gum up the works.


I'd expect most people see this.

On 06/04/2016 09:46 PM, Mahdi Mohammadi wrote:

Output of `ant test` for each test suit contains this warning:

*test:*
*[mkdir] Created dir: /Users/mahdi/box/cassandra/build/test/cassandra*
*[mkdir] Created dir: /Users/mahdi/box/cassandra/build/test/output*
*[junit] WARNING: multiple versions of ant detected in path for junit *
*[junit]
  
jar:file:/usr/local/Cellar/ant/1.9.6/libexec/lib/ant.jar!/org/apache/tools/ant/Project.class*
*[junit]  and
jar:file:/Users/mahdi/box/cassandra/build/lib/jars/ant-1.9.4.jar!/org/apache/tools/ant/Project.class*

How can I fix this warning?

Best Regards

Re: Cassandra Java Driver and DataStax

[Dave Brosius]

I am a non-datastax-employee committer, and the large percentage of my 
commits are not reviewed by datastax exmployees. I see problems or areas 
of improvement in the code base, and directly commit them. No questions 
asked, no oversight, no direction at all from datastax or their 
employees. I have had a minor number of commits that were reviewed by 
cassandra committers, some of which are datastax employees, but the 
overwhelming number have not been that way.


If you go by pure commit counts, (an admittedly dubious rating, but 
still) i am #4 on number of commits.




On 06/05/2016 06:33 PM, Mattmann, Chris A (3980) wrote:

Thanks for the info Jonathan. I think have assessed based on
the replies thus far, my studying of the archives and
commit and project history the following situation.

Unfortunately it seems like there is a bit of control going on
I’m going to call a spade a spade here. A key portion of your
software’s stack, a client driver to use it, exists outside of
Apache in separate communities. This is an inherent risk to the
project. Some of you cite flexibility and adaptability as reasons
for this - I’ve seen it in so many communities over the last 12+
years in the foundation - it’s not really due to those issues.
There is definitely some control going on. I would ask you all
this - has there been a PR or patch in the past year or two that
wasn’t singularly reviewed by DataStax committers and PMC? Also,
as to the composition of the PMC when was the last time a non
DataStax person was elected to the PMC and/or as a committer?

By itself the diversity issues alone are not damning to the
project, but taken together with the citation to other project
communities even those outside of Apache (e.g., the comments
well “Postgres does it this way, so it’s a good example to
compare us to” or “these other 4 projects at the ASF do it
like this, so X”.. [sic]) and with the perception being created
to those that don’t work at DataStax, and there is an issue here.

I would like to see a discussion in your next board report about
the diversity and health issues of the project, and also some
ideas about potential strategies for mitigation.

I appreciate the open and honest conversation thus far. Let’s
keep it up.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/5/16, 1:51 PM, "Jonathan Ellis"  wrote:


On Sun, Jun 5, 2016 at 8:32 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:


1. Is Apache Cassandra useful *without* a driver? That is, can
you use the database without a driver to connect to it or in the
real world would your users all have to download at least one
driver in order to use the DB?


The users do need to download a driver--but this is pretty normal for
community-driven OSS databases.  Besides the Apache projects I listed,
PostgreSQL also runs on a community-maintained driver model.



2. To confirm again, at one point at least the Java driver code
lived in the code-base, and further, at one point, people did
submit some patches to add drivers, but the PMC didn’t want to
maintain that code (and apparently they didn’t want to create
any new PMC members and/or committers to do so) and so thus
people started their own new projects? That right?


I think that summary over-emphasizes the governance aspect at the expense
of more important considerations:

0. The very first Cassandra driver interface was Thrift.  No Thrift clients
were ever part of the Cassandra tree.

1. When we created the CQL protocol, we initially had a Java driver in tree
as a reference implementation.

2. But due primarily to the project management issues mentioned by Nate,
and secondarily to the governance aspects above, we moved quickly back to
the pure community-driven drivers approach that had worked for us before.

2a. While some Apache databases do ship a Java driver in tree, I think that
this hinders adoption because it signals to users that non-Java drivers are
second-class citizens.  (No doubt this is not the *intent* of that
decision, but it is a likely consequence nevertheless.)

2b. DataStax saw CQL adoption as a key driver for Cassandra adoption and
hence its own success, and hired a team to accelerate the production of
drivers for the new CQL protocol.  These drivers are Apache licensed and
see broad community participation, e.g. with ~70 contributors to the J

Re: NewBie Question ~ Book for Cassandra

[Dave Brosius]

Chris,

The tools supplied by Apache for documentation, ie, wiki, are awful. No 
human being should be subjected to those. It would be great if someone 
of your stature would do something about that for the entire Apache 
community.





On 06/11/2016 12:16 PM, Mattmann, Chris A (3980) wrote:

Hi Everyone,

While this may be a current great source of documentation on
Cassandra, and while it exists externally, the PMC should be
be promoting (and hopefully ensuring) that the source of documentation
for Apache Cassandra is here at the ASF.

I’m happy to be corrected that that is the case, and/or that
I’ve missed something, but the first reply to questions like
this from newbies shouldn’t be to point to an external website.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/11/16, 8:54 AM, "Bhuvan Rawal"  wrote:


Hi Deepak,

You can try Datastax Docs, they are most extensive and updated
documentation available.
As Cassandra is a fast developing technology I wonder if there is a Book in
the market which covers latest features like Materialized Views/ SASI Index
or new SSTable Format. I believe the best starting point would be the
Academy Tutorials and further Planet Cassandra - A week in Cassandra series
provides good overview of blogs and developments by Cassandra Evangelists.
It also provides link of top blogs which help understand internal working
of the Database.

However if you still feel the need, you may refer to books, here are some
that I know of -
Beginning Apache Cassandra Development - Vivek Mishra - 2014 - Link

Cassandra Data Modeling and Analysis - 2014 C.Y. Kan - Link

Mastering Apache Cassandra - Second Edition - March 26 2015 - Link

Cassandra Design Patterns - 2015 - Link

Cassandra High Availability - 2014 - Link

Learning Apache Cassandra - Manage Fault Tolerant and Scalable Real-Time
Data - 2015 - Link


Best Regards,
Bhuvan
Datastax Certified Architect

On Sat, Jun 11, 2016 at 8:28 PM, Deepak Goel  wrote:


Hey

Namaskara~Nalama~Guten Tag~Bonjour

I am a newbie.

Which would be the best book for a newbie to learn Cassandra?

Thank You
Deepak
--
Keigu

Deepak
73500 12833
www.simtree.net, dee...@simtree.net
deic...@gmail.com

LinkedIn: www.linkedin.com/in/deicool
Skype: thumsupdeicool
Google talk: deicool
Blog: http://loveandfearless.wordpress.com
Facebook: http://www.facebook.com/deicool

"Contribute to the world, environment and more :
http://www.gridrepublic.org
"

Re: NewBie Question ~ Book for Cassandra

[Dave Brosius]

So then, not going to help, at all. i see.

ok



On 06/11/2016 12:31 PM, Mattmann, Chris A (3980) wrote:

Hi Dave,

Can you please clarify what you mean by “someone of my stature
[sic]” should do something about the tools supplied by Apache? It’s
not my responsibility - it’s the community’s responsibility and
infra’s responsibility from a perspective of aiding the communities
here at the foundation.

Has anyone from the Apache Cassandra PMC contacted infra@ and
discussed tooling options for documentation? The CMS supports
markdown, and pretty much any flavor of external tool (it just needs
to be hooked in). Confluence is pretty good - have you tried it?
MoinMoin, admittedly, is extremely basic. There are a variety of
options.

Regardless of the state of the tooling, the documentation for Apache
Cassandra needs to live with the PMC, and not on an external company’s
website. Period.

Cheers,
Chris


++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/11/16, 9:26 AM, "Dave Brosius"  wrote:


Chris,

The tools supplied by Apache for documentation, ie, wiki, are awful. No
human being should be subjected to those. It would be great if someone
of your stature would do something about that for the entire Apache
community.




On 06/11/2016 12:16 PM, Mattmann, Chris A (3980) wrote:

Hi Everyone,

While this may be a current great source of documentation on
Cassandra, and while it exists externally, the PMC should be
be promoting (and hopefully ensuring) that the source of documentation
for Apache Cassandra is here at the ASF.

I’m happy to be corrected that that is the case, and/or that
I’ve missed something, but the first reply to questions like
this from newbies shouldn’t be to point to an external website.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/11/16, 8:54 AM, "Bhuvan Rawal"  wrote:


Hi Deepak,

You can try Datastax Docs, they are most extensive and updated
documentation available.
As Cassandra is a fast developing technology I wonder if there is a Book in
the market which covers latest features like Materialized Views/ SASI Index
or new SSTable Format. I believe the best starting point would be the
Academy Tutorials and further Planet Cassandra - A week in Cassandra series
provides good overview of blogs and developments by Cassandra Evangelists.
It also provides link of top blogs which help understand internal working
of the Database.

However if you still feel the need, you may refer to books, here are some
that I know of -
Beginning Apache Cassandra Development - Vivek Mishra - 2014 - Link
<https://www.amazon.com/Beginning-Apache-Cassandra-Development-Mishra/dp/1484201434>
Cassandra Data Modeling and Analysis - 2014 C.Y. Kan - Link
<https://www.amazon.com/Cassandra-Data-Modeling-Analysis-C-Y/dp/178396/ref=sr_1_1?s=books&ie=UTF8&qid=1465659906&sr=1-1&keywords=cassandra+data+modeling+and+analysis>
Mastering Apache Cassandra - Second Edition - March 26 2015 - Link
<https://www.amazon.com/gp/product/1784392618/ref=pd_lpo_sbs_dp_ss_3?pf_rd_p=1944687622&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=1484201434&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=YVM1QBXHKAFK18J1XBAC>
Cassandra Design Patterns - 2015 - Link
<https://www.amazon.com/Cassandra-Design-Patterns-Rajanarayanan-Thottuvaikkatumana/dp/178528570X/ref=sr_1_1?s=books&ie=UTF8&qid=1465659937&sr=1-1&keywords=cassandra+design+patterns>
Cassandra High Availability - 2014 - Link
<https://www.amazon.com/Cassandra-High-Availability-Robbie-Strickland/dp/1783989122/ref=sr_1_1?s=books&ie=UTF8&qid=1465659975&sr=1-1&keywords=cassandra+high+availability>
Learning Apache Cassandra - Manage Fault T

Re: Jira down, again?

[Dave Brosius]

They are aware of these things

https://twitter.com/infrabot 

On 06/14/2016 05:28 AM, Giampaolo Trapasso wrote:

Hi to all,
at the moment is the same for me. Is there a way to notify to someone this
situation?

Giampaolo

2016-06-13 23:27 GMT+02:00 Mahdi Mohammadi :


And when it is not down, it is very slow for me.

Do others have the same experience?

Best Regards

On Tue, Jun 14, 2016 at 4:19 AM, Brandon Williams 
wrote:


Everyone.

On Mon, Jun 13, 2016 at 3:18 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:


Seems like Apache Jira is 100% down, again, for like the 500th time in

the

last 2 months. Just me or everyone?

Re: Easy path to the latest Cassandra in Ubuntu

[Dave Brosius]

I notice that snapcraft.io already lists Cassandra as having a snap 
available on the front page.


On 06/26/2016 12:03 PM, Jonathan Ellis wrote:

Hi Evan,

Is Snap a new packaging format like deb/rpm, or does it consume the
existing deb package?

On Tue, Jun 21, 2016 at 8:26 PM, Evan Dandrea  wrote:


Hi,

Ubuntu 16.04 comes with a new way to deliver applications (
http://snapcraft.io), and I thought it would be a great way to simplify
getting set up with Cassandra.

So now, if you run the following on any Ubuntu 16.04 system

 snap install cassandra && snap connect cassandra:mount-observe
ubuntu-core:mount-observe

Cassandra 3.7 will be installed with Java and the rest of the dependencies
bundled in. You can even install the tip of master (built about once a
day):

 snap install --channel=edge cassandra && snap connect
cassandra:mount-observe ubuntu-core:mount-observe

Or if you already installed 3.7:

 snap refresh --channel=edge cassandra

None of this requires complex packaging or approval from the distribution
powers that be. If we move the snapcraft.yaml file [1] to a tree owned by
the dev community you can completely control upload and publishing.

This isn't limited to Ubuntu, either. If you install snapd this will work
on Arch, Debian, Fedora, and Gentoo too.

What do you think? I'd be happy to walk anyone through the details or put
together a pull request.

1:
https://github.com/evandandrea/cassandra-snap/blob/master/snapcraft.yaml

Re: [VOTE] Release Apache Cassandra 2.1.15

[Dave Brosius]

nits

snappy-java and thrift-server's license files have the wrong version 
numbers.




On 06/30/2016 03:30 PM, Jake Luciani wrote:

I propose the following artifacts for release as 2.1.15.

sha1: cb14186f8d6c2d1105a51e409c59a4e424958171
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.15-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1118/org/apache/cassandra/apache-cassandra/2.1.15/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1118/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~jake

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/Dah6P4 (CHANGES.txt)
[2]: http://goo.gl/ZFeiGF (NEWS.txt)

Re: [VOTE] Release Apache Cassandra 2.1.15

[Dave Brosius]

+1

On 06/30/2016 03:30 PM, Jake Luciani wrote:

I propose the following artifacts for release as 2.1.15.

sha1: cb14186f8d6c2d1105a51e409c59a4e424958171
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.15-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1118/org/apache/cassandra/apache-cassandra/2.1.15/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1118/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~jake

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/Dah6P4 (CHANGES.txt)
[2]: http://goo.gl/ZFeiGF (NEWS.txt)

Re: [VOTE] Release Apache Cassandra 2.2.7

[Dave Brosius]

+1

On 07/01/2016 10:58 AM, Jake Luciani wrote:

I propose the following artifacts for release as 2.2.7.

sha1: 092054170ec3daf92ec494a0db295037d3563229
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.7-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1121/org/apache/cassandra/apache-cassandra/2.2.7/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1121/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~jake

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/R37fmZ (CHANGES.txt)
[2]: http://goo.gl/PaGj7e (NEWS.txt)
[3]: https://goo.gl/DKoHDw (Test Report)

Re: [VOTE] Release Apache Cassandra 3.0.8

[Dave Brosius]

+1

On 07/01/2016 11:40 AM, Jake Luciani wrote:

I propose the following artifacts for release as 3.0.8.

sha1: 8b21d9e9e975ea07023ae6ec4c04d997006c1a0a
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.8-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1122/org/apache/cassandra/apache-cassandra/3.0.8/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1122/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~jake

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/6B1cR3 (CHANGES.txt)
[2]: http://goo.gl/1IXyg0 (NEWS.txt)
[3]: https://goo.gl/1o8K6t (Test Report)

Re: [VOTE] Release Apache Cassandra 3.8

[Dave Brosius]

+1

On 07/20/2016 05:48 PM, Michael Shuler wrote:

I propose the following artifacts for release as 3.8.

sha1: c3ded0551f538f7845602b27d53240cd8129265c
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1123/

The debian packages are available here: http://people.apache.org/~mshuler/

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/oGNH0i (CHANGES.txt)
[2]: http://goo.gl/KjMtUn (NEWS.txt)
[3]: https://goo.gl/TxVLKo (3.8 Test Summary)

Re: [VOTE] Release Apache Cassandra 3.8

[Dave Brosius]

; 2. has the small advantage of keeping the 3.0.x and 3.x
> >>>> versions
> >> released
> >>>> more or less in lockstep).
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko
> >>>>>  >>>
> >>>>> wrote:
> >>>>>
> >>>>>> I still think the issue is minor enough, and with 3.8 being
> >>>>>> extremely delayed, and being a non-odd release, at that,
> >>>>>> we’d be better off just pushing it.
> >>>>>>
> >>>>>> Also, I know we’ve been easy on -1s when voting on
> >>>>>> releases, but I
> >> want
> >>>>> to
> >>>>>> remind people in general that release votes can not be
> >>>>>> vetoed and only require a majority of binding votes,
> >>>>>> http://www.apache.org/foundation/voting.html#ReleaseVotes
> >>>>>>
> >>>>>>
> >>>>>> -- AY
> >>>>>>
> >>>>>> On 21 July 2016 at 08:57:22, Sylvain Lebresne
> >>>>>> (sylv...@datastax.com) wrote:
> >>>>>>
> >>>>>> Sorry but I'm (binding) -1 on this because of
> >>>>>> https://issues.apache.org/jira/browse/CASSANDRA-12236.
> >>>>>>
> >>>>>> I disagree that knowingly releasing a version that will
> >>>>>> temporarily
> >>>> break
> >>>>>> in-flight queries during upgrade, even if it's for a very
> >>>>>> short
> >>>>> time-frame
> >>>>>> until re-connection, is ok. I'll note in particular that in
> >>>>>> the test report, there is 74! failures in the upgrade tests
> >>>>>> (for reference the
> >>>> 3.7
> >>>>>> test report had only 2 upgrade tests failure both with open
> >>>>>> tickets).
> >>>>> Given
> >>>>>> that we have a known problem during upgrade, I don't really
> >>>>>> buy the
> >> "We
> >>>>> are
> >>>>>> assuming these are due to a recent downsize in instance
> >>>>>> size that
> >> these
> >>>>>> tests run on" and that suggest to me the problem is not too
> >>>>>> minor.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jul 21, 2016 at 6:18 AM, Dave Brosius <
> >>>> dbros...@mebigfatguy.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>>
> >>>>>>> On 07/20/2016 05:48 PM, Michael Shuler wrote:
> >>>>>>>
> >>>>>>>> I propose the following artifacts for release as 3.8.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> sha1: c3ded0551f538f7845602b27d53240cd8129265c Git:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
> >>
> >>>>>>>> Artifacts:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>
https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/
> >>
> >>>>>>>> Staging repository:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>
https://repository.apache.org/content/repositories/orgapachecassandra-1123/
> >>
> >>>>>>>>
> >>>>>>>> The debian packages are available here:
> >>>>>>>> http://people.apache.org/~mshuler/
> >>>>>>>>
> >>>>>>>> The vote will be open for 72 hours (longer if needed).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [1]: http://goo.gl/oGNH0i (CHANGES.txt) [2]:
> >>>>>>>> http://goo.gl/KjMtUn (NEWS.txt) [3]:
> >>>>>>>> https://goo.gl/TxVLKo (3.8 Test Summary)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -- Jonathan Ellis Project Chair, Apache Cassandra co-founder,
> >>>>> http://www.datastax.com @spyced
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
>
>


--
http://twitter.com/tjake

Re: Would like to contribute to Apache/Cassandra wiki

[Dave Brosius]

try now


On 08/10/2016 12:13 PM, Danielle Blake wrote:

Hi,
I would like to contribute to https://wiki.apache.org/
cassandra/ThirdPartySupport
I would like to get the Company I work for, OpenCredo
, on this page.

Username: Danielle Blake

Kind regards,

Danielle Blake

Marketing Executive

M. +44 (0) 7403 565 785

T.  +44 (0) 207 928 9200

Opencredo.com . Twitter  . LinkedIn


OpenCredo Ltd -- Excellence in Enterprise Application Development

Registered Office:  5-11 Lavington St, London SE1 0NZ

Registered in UK. No 3943999

If you have received this e-mail in error please accept our apologies,
destroy it immediately and it immediately and it would be greatly
appreciated if you notified the sender.  It is your responsibility to
protect your system from viruses and any other harmful code or device.
We try to eliminate them from e-mails and attachments; but we accept no
liability for any that remain. We may monitor or access any or all
e-mails sent to us.

Re: Contribution to apache Cassandra wiki

[Dave Brosius]

try now!

---


On 2016-08-14 07:06, Bartek Kowalczyk wrote:

Hi,
here http://wiki.apache.org/cassandra/FrontPage I found information how 
to

contribute, so if it is possible, it is my username: bartekkowalczyk.

I wanted to update class names in
http://wiki.apache.org/cassandra/ArchitectureCommitLog (these are now
longer valid)


Cheers !

Re: A proposal to move away from Jira-centric development

[Dave Brosius]

+1 I would like this.

On 2016-08-16 13:31, Jeremiah D Jordan wrote:

Back to the topic at hand.  First, let us establish that all of this
stuff will be happening “on the mailing lists”, all JIRA updates are
sent to commits@ with the reply-to set to dev@, so “JIRA” is still “on
the list".

Now we just need to decide how we would like to best make use of these
lists.  I propose that we keep dev@ fairly low volume so that people
don’t feel the need to filter it out of their inbox, and thus possibly
miss important discussions.
If someone cares so much about the name of the list where stuff
happens, then I propose we make dev-announce@ and if that happens we
can replace commits@ with dev@ below and dev@ with dev-announce@ and
start forwarding some JIRA stuff to dev@…

In order to keep dev@ low volume (but higher than it currently is, as
it has mostly been “no volume” lately) I propose the following:

Someone has a major feature that they would like to discuss.  (Again
this is just for major features, not every day bug fixes etc)
1. Make a JIRA for the thing you want to discuss (aka post the thing
to commits@)
2. Post link to JIRA with a short description to dev@
3. Have a discussion on the JIRA (aka commits@) about the new thing.
4. If there is some major change/question on the JIRA that people feel
needs some extra discussion/involvement email dev@ with question and
link back to the JIRA
5. Have more discussions on the JIRA (aka commits@) about the new 
thing.

6. If something else comes up go back too step 4.
7. During this process of decision making keep the “Title” and
“Description” fields of the JIRA (aka commits@) up to date with what
is actually happening in the ticket.
8. Once things settle down make sub tasks or follow on tickets for
actually implementing things linked to the initial ticket.

That would keep the dev@ list informed of what is going on in new
feature proposals, and it will keep discussions on JIRA tickets where
they are easily referenced and kept in one place, so it is easy to get
to, and easy for.

-Jeremiah


On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  wrote:

A long time ago, I was a proponent of keeping most development 
discussions

on Jira, where tickets can be self contained and the threadless nature
helps keep discussions from getting sidetracked.

But Cassandra was a lot smaller then, and as we've grown it has become
necessary to separate out the signal (discussions of new features and 
major

changes) from the noise of routine bug reports.

I propose that we take advantage of the dev list to perform that
separation.  Major new features and architectural improvements should 
be
discussed first here, then when consensus on design is achieved, moved 
to

Jira for implementation and review.

I think this will also help with the problem when the initial idea 
proves

to be unworkable and gets revised substantially later after much
discussion.  It can be difficult to figure out what the conclusion 
was, as
review comments start to pile up afterwards.  Having that discussion 
on the

list, and summarizing on Jira, would mitigate this.

--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: A proposal to move away from Jira-centric development

[Dave Brosius]

While i agree with this generally, it's misleading.

It comes across like Datastax is dictating and excluding others from 
participating, or perhaps discouraging others or whatever.


The truth is, whenever someone comes along who is independent, and 
interested in developing Apache Cassandra, they are welcomed, and do 
participate, and do develop, and soon after become Datastax 
employees. Not always of course, but a common pattern. It only makes 
sense for Datastax to hire people who are interested in and capable of 
developing Apache Cassandra. But the truth is a whole lot less sinister 
than the inference.


--dave
[not associated with Datastax]


On 2016-08-16 13:47, Benedict Elliott Smith wrote:
This is a much more useful focusing of the discussion, in my opinion.  
It

seemed to me that city hall was focusing on a very narrow definition of
project health.

I would be the first to say the project need to improve here, but doing 
so
will be challenging;  I'm not sure anyone really knows how to go about 
it.

Which is why we end up in these local minima of discussions about the
minutiae of JIRA replication.

What this project really needs, and the board is chomping at the bit 
about,
is diversity.  The fact is, right now DataStax does 95% of the 
substantive
development on the project, and so they make all the decisions.  As 
such,
their internal community outweighs the Apache community.  I will 
emphasise

clearly for my ex-colleagues, I'm not making any value judgement about
this, just clarifying the crux of the discussion that everyone seems to 
be

dancing around.

The question is, what can be done about it?  The project needs a lot of 
new

highly productive and independent contributors who are capable of
meaningfully shaping project direction.  The problem is we don't know 
how

to achieve that.



On 16 August 2016 at 17:24, Dennis E. Hamilton 


wrote:




> -Original Message-
> From: Eric Stevens [mailto:migh...@gmail.com]
> Sent: Tuesday, August 16, 2016 06:10
> To: dev@cassandra.apache.org
> Subject: Re: A proposal to move away from Jira-centric development
>
> I agree with Benedict that we really shouldn't be getting into a
> legalese
> debate on this subject, however "it didn't happen" has been brought up
> as a
> hammer in this conversation multiple times, and I think it's important
> that
> we put it to rest.  It's pretty clear cut that projects are free to
> disregard this advice.  "It didn't happen" is a motto, not a rule.
[orcmid]



Please read them all, but especially the sections on Community, 
Consensus

Building, and Independence.

Apache projects are expected to govern themselves, PMCs are 
responsible
for it, and PMC Chairs (officers of the foundation) are accountable to 
the

Board on how the project is striving toward maturity.

On occasion, deviations are so notable that there is objection.  It is 
not
that folks run around policing the projects.  But there are occasions 
where

there are concerns that a project has gone astray.

One maturity factor that might not be emphasized enough is
Sustainability.  It is about the transparency of project conduct, the
inclusiveness of operation and visibility, and the ways that growth 
and
turnover are accommodated.  Since we are looking at mottos, "community 
over

code" comes to mind.

Project freedom is a bit like the freedom to drive at 100mph on an
arterial highway.  Occassionally, the infraction becomes worthy of
attention and even a road block and spike strips.

While individual preferences are being discussed here, and I agree it 
is
more pertinent than top-posting versus bottom-posting, what is lacking 
is a
broad discussion on community.  Not incumbents and the 
karma-privileged,

but the overall community and how one sustains a thriving project that
strives for maturity.

Folks who are concerned about managing the mail stream and choosing 
what
matters to them might want to discuss ways of operating lists in 
support of
those concerns.  There are positions here and not enough questions 
about
what might be workable inside of the practices and policies that are 
the

waters Apache projects swim in.

 - Dennis

>
> Per ASF newbie FAQ referenced by someone else earlier [1]:
>
> > The section on ASF Mottos is especially useful as a reminder of the
> way
> things are in most ASF projects. This section includes such gems as:
> > * Put community before code.
> > * Let they that do the work make the decisions.
> > * If it didn't happen on a mailing list, it didn't happen.
> > * Don't feed the trolls.
>
> This is presented as a general guideline and not a hard rule, and as
> Benedict points out even this is preceded by a guideline suggesting that
> developers are free to seek alternatives.
[orcmid]

The alternatives must fit within the overall principles, however.  Not
deviate from or weaken them.  This is not an opening for arbitrary 
conduct.

Re: Contribute to Cassandra Wiki Third Party Support

[Dave Brosius]

Conflict resolved.

thanks for the addition.

--dave

On 2016-08-19 08:43, Danielle Blake wrote:

Hi Michael,

I never recieved an email from Dave. But thanks for letting me know, I 
do

indeed have edit rights now. I have added to the document but an edit
conflict came up so you may need to check it.

Cheers!

Kind regards,

Danielle Blake

Marketing Executive

M. +44 (0) 7403 565 785

T.  +44 (0) 207 928 9200

Opencredo.com . Twitter  . LinkedIn


OpenCredo Ltd -- Excellence in Enterprise Application Development

Registered Office:  5-11 Lavington St, London SE1 0NZ

Registered in UK. No 3943999

If you have received this e-mail in error please accept our apologies,
destroy it immediately and it immediately and it would be greatly
appreciated if you notified the sender.  It is your responsibility to
protect your system from viruses and any other harmful code or device.  
We

try to eliminate them from e-mails and attachments; but we accept no
liability for any that remain. We may monitor or access any or all 
e-mails

sent to us.


On 18 August 2016 at 14:27, Michael Shuler  
wrote:



It looks like Dave replied to your first email that he added your wiki
user to be able to edit pages. Did your login not work properly, or 
did

you get some sort of error editing the wiki?

(cc'ed directly, too)

--
Kind regards,
Michael

On 08/18/2016 08:15 AM, Danielle Blake wrote:
> Hi,
>
> I emailed you last week in regards to contributing to
> https://wiki.apache.org/cassandra/ThirdPartySupport and have not heard a
> response yet.
> I would like to get the Company that I work for, OpenCredo
> , on this page as we are Datastax Certified
> experts.
>
> Username: Danielle Blake
>
> Kind regards,
>
> Danielle Blake
>
> Marketing Executive
>
> M. +44 (0) 7403 565 785
>
> T.  +44 (0) 207 928 9200
>
> Opencredo.com . Twitter  . LinkedIn
> 
>
> OpenCredo Ltd -- Excellence in Enterprise Application Development
>
> Registered Office:  5-11 Lavington St, London SE1 0NZ
>
> Registered in UK. No 3943999
>
> If you have received this e-mail in error please accept our apologies,
> destroy it immediately and it immediately and it would be greatly
> appreciated if you notified the sender.  It is your responsibility to
> protect your system from viruses and any other harmful code or device.
We
> try to eliminate them from e-mails and attachments; but we accept no
> liability for any that remain. We may monitor or access any or all
e-mails
> sent to us.
>

Re: 3.8/3.9 releases/branch freeze, current merge order

[Dave Brosius]

It's basically just removing a tag, nothing more. Completely trivial.

---


On 2016-08-24 15:22, Mark Thomas wrote:

On 24/08/2016 16:44, Aleksey Yeschenko wrote:



Also, cassandra-3.8 branch was removed from the repo, to further 
minimise confusion.


That is the sort of thing I'd expect to see discussed on the dev list
first. Where is that discussion?

Mark

Re: #cassandra-dev IRC logging

[Dave Brosius]

If you wish to unsubscribe, send an email to

mailto://dev-unsubscr...@cassandra.apache.org


On 08/26/2016 04:49 PM, Gvb Subrahmanyam wrote:

Please remove me from - dev@cassandra.apache.org

-Original Message-
From: Jake Farrell [mailto:jfarr...@apache.org]
Sent: Friday, August 26, 2016 4:36 PM
To: dev@cassandra.apache.org
Subject: Re: #cassandra-dev IRC logging

asfbot can log to wilderness for backup, but it does not send out digests.
I've seen a couple of projects starting to test out and use slack/hipchat and 
then use sameroom to connect irc so conversations are not separated and people 
can use their favorite client of choice

-Jake

On Fri, Aug 26, 2016 at 4:20 PM, Edward Capriolo 
wrote:


Yes. I did. My bad.

On Fri, Aug 26, 2016 at 4:07 PM, Jason Brown  wrote:


Ed, did you mean this to post this to the other active thread today,
the one about github pull requests? (just want to make sure I'm
understanding correctly :) )

On Fri, Aug 26, 2016 at 12:28 PM, Edward Capriolo

One thing to watch out for. The way apache-gossip is setup the
PR's get sent to the dev list. However the address is not part of
the list so

the

project owners get an email asking to approve/reject every PR and

comment

on the PR.

This is ok because we have a small quite group but you probably do
not

want

that with the number of SCM changes in the cassandra project.

On Fri, Aug 26, 2016 at 3:05 PM, Jeff Jirsa <

jeff.ji...@crowdstrike.com>

wrote:


+1 to both as well

On 8/26/16, 11:59 AM, "Tyler Hobbs"  wrote:


+1 on doing this and using ASFBot in particular.

On Fri, Aug 26, 2016 at 1:40 PM, Jason Brown


wrote:

@Dave ASFBot looks like a winner. If others are on board with

this,

I

can

work on getting it up and going.

On Fri, Aug 26, 2016 at 11:27 AM, Dave Lester <

dave_les...@apple.com>

wrote:


+1. Check out ASFBot for logging IRC, along with other

integrations.[1]




Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at http://www.techmahindra.com/Disclaimer.html externally 
http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra.

Re: [VOTE] Release Apache Cassandra 3.0.9

[Dave Brosius]

+1


On 09/15/2016 02:57 PM, Jake Luciani wrote:

I propose the following artifacts for release as 3.0.9.

sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.9-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1124/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~jake

The vote will be open for 72 hours (longer if needed).

[1]: https://goo.gl/JKkE05 (CHANGES.txt)
[2]: https://goo.gl/Hi8X71 (NEWS.txt)

Re: Question on assert

[Dave Brosius]

As an aside, C* for some reason heavily uses asserts in unit tests, 
which adds to the "can't see the forest for the trees" problem. I see no 
reason for that. they should all be moved over to junit asserts.



On 09/22/2016 03:52 AM, Benjamin Lerer wrote:

We can spend hours arguing about assert vs exceptions. I have seen it
happen in every company I worked for.
Overall, based on the patches I have reviewed, it seems to me that in
general people are using them only has internal safety checks.
Unfortunatly, the code change and we can miss things.
If anybody think that some SPECIFIC assertions should be replaced by some
real checks, I think the best way to do it is to open a JIRA ticket to
raise the problem.

Re: Review of Cassandra actions

[Dave Brosius]

I take this response (a second time) as a pompous way to trivialize the 
responses of others as to the point of their points being meaningless to 
you. So either explain what this means, or accept the fact that you are 
as Chris is exactly what people are claiming you to be. Abnoxious 
bullies more interested in throwing your weight around and causing 
havoc, destroying a community, rather than actually being motivated by 
improving the ASF.



On 11/05/2016 06:16 PM, Jim Jagielski wrote:

How about a nice game of chess?


On Nov 5, 2016, at 1:15 PM, Aleksey Yeschenko  wrote:

I’m sorry, but this statement is so at odds with common sense that I have to 
call it out.

Of course your position grants your voice extra power. A lot of extra power,
like it or not (I have a feeling you quite like it, though).

In an ideal world, that power would entail corresponding duties:
care and consideration in your actions at least.
Instead, you are being hotheaded, impulsive, antagonising, and immature.

In what possible universe dropping that hammer threat from the ’20% off” email 
thread,
then following up with a Game of Thrones youtube clip is alright?

That kind of behaviour is inappropriate for a board member. Frankly, it 
wouldn’t be
appropriate for a greeter at Walmart. If you don’t see this, we do indeed have 
bigger
problems.

--
AY

On 5 November 2016 at 14:57:13, Jim Jagielski (j...@jagunet.com) wrote:

  
But I love the ability of VP's and Board to simply pretend their positions carried no weight.
  

I would submit that whatever "weight" someone's position may
carry, it is due to *who* they are, and not *what* they are.

If we have people here in the ASF or in PMCs which really think
that titles manner in discussions like this, when one is NOT
speaking ex cathedra, then we have bigger problems. :)

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

[Dave Brosius]

>> We fully intend to "engineer and test the snot out of" the changes 
we are working on as the whole point of us working on them is so we 
*can* run them in production, at our scale.


I'm not sure how the apache team does this. Perhaps individual engineers 
can run some modern version at a company of theirs, altho that seems 
unlikely, but as an Apache org, i just don't see how that happens.


To me it seems like the Apache Cassandra infrastructure itself needs to 
stand up a multinode live instance running some 'real-world' example 
that is getting pounded, so that we can stage feature branches to really 
test them.


Otherwise we will forever be basing versions on the poor test saps who 
decide they are willing to risk all to upgrade to the cutting edge, and 
why, everyone believes in the adage, don't upgrade until at least .6


--dave


On 11/20/2016 09:50 AM, Jason Brown wrote:

Hey all,

One of the goals on my team, when working on large patches, is to get
community feedback on these initiatives before throwing them into prod.
This gets us a wider net of feedback (see Sylvain's continuing excellent
rounds of feedback to my work on CASSANDRA-8457), as well as making sure we
don't go too far off the deep end in terms of straying from the community
version. The latter point is crucial because if we make too many
incompatible changes to, for example, the internode messaging protocol or
the CQL protocol or the sstable file format, and deploy that, it may be
very difficult, if not impossible, to rectify with future, in-development
versions of cassandra.

We fully intend to "engineer and test the snot out of" the changes we are
working on as the whole point of us working on them is so we *can* run them
in production, at our scale. We aren't expecting others in the community to
dog food it for us. There will be a delay between committing something
upstream, and us backporting it to a current version we run in production
and actually deploying it. However, you can be sure that any bugs we find
will be fixed ASAP; we have many users counting on it.

Thanks for listening,

-Jason


On Sat, Nov 19, 2016 at 11:04 AM, Blake Eggleston 
wrote:


I think Ed's just using gossip 2.0 as a hypothetical example. His point is
that we should only commit things when we have a high degree of confidence
that they work correctly, not with the expectation that they don't.


On November 19, 2016 at 10:52:38 AM, Michael Kjellman (
mkjell...@internalcircle.com) wrote:

Jason has asked for review and feedback many times. Maybe be constructive
and review his code instead of just complaining (once again)?

Sent from my iPhone


On Nov 19, 2016, at 1:49 PM, Edward Capriolo 

wrote:

I would say start with a mindset like 'people will run this in

production'

not like 'why would you expect this to work'.

Now how does this logic effect feature develement? Maybe use gossip 2.0

as

an example.

I will play my given debby downer role. I could imagine 1 or 2 dtests and
the logic of 'dont expect it to work' unleash 4.0 onto hords of nubes

with

twitter announce of the release let bugs trickle in.

One could also do something comprehensive like test on clusters of 2 to
1000 nodes. Test with jepsen to see what happens during partitions,

inject

things like jvm pauses and account for behaivor. Log convergence times
after given events.

Take a stand and say look "we engineered and beat the crap out of this
feature. I deployed this release feature at my company and eat my

dogfood.

You are not my crash test dummy."



On Saturday, November 19, 2016, Jeff Jirsa  wrote:

Any proposal to solve the problem you describe?

--
Jeff Jirsa



On Nov 19, 2016, at 8:50 AM, Edward Capriolo 
<;>> wrote:

This is especially relevant if people wish to focus on removing things.

For example, gossip 2.0 sounds great, but seems geared toward huge

clusters

which is not likely a majority of users. For those with a 20 node

cluster

are the indirect benefits woth it?

Also there seems to be a first push to remove things like compact

storage

or thrift. Fine great. But what is the realistic update path for

someone.

If the big players are running 2.1 and maintaining backports, the

average

shop without a dedicated team is going to be stuck saying (great

features

in 4.0 that improve performance, i would probably switch but its not

stable

and we have that one compact storage cf and who knows what is going to
happen performance wise when)

We really need to lose this realease wont be stable for 6 minor

versions

concept.

On Saturday, November 19, 2016, Edward Capriolo 
<;>>

wrote:



On Friday, November 18, 2016, Jeff Jirsa 
<;>

<_e(%7B%7D,'cvml','jeff.ji...@crowdstrike.com <;>');>>

wrote:

We should assume that we’re ditching tick/tock. I’ll post a thread on
4.0-and-beyond here in a few minutes.

The advantage of a prod release every 6 months is fewer incentive to

push

unfinished work into a release.
The disadvantage of a prod release every 6 months

Re: Wiki Contributer

[Dave Brosius]

If your wiki-name was ThomasBrown, then you are added, if not let me 
know what it is.



On 11/22/2016 06:33 PM, Thomas Brown wrote:

Hi,

Could I please be added as a Wiki Contributor

Thanks

Re: Wiki Contributor

[Dave Brosius]

try now


On 11/22/2016 06:38 PM, Thomas Brown wrote:

Hi,

Could I please be added as a Wiki Contributor

Username: Thomas Brown

Thank you!

Re: Wrapping up tick-tock

[Dave Brosius]

The problem with long release cycles is that everything goes in. and you 
have potentially a mish-mash of features, some more done than others, 
causing instability. Quick releases attempt to fix this issue by keeping 
the number of commits down to a manageable size. The problem is that 
that commit list isn't necessarily cohesive and so you really haven't 
solved anything, most likely.


It seems to me, the answer is to move towards feature branches, without 
any concept of release branches. When a feature is truely done, and 
people and tests are happy, you merge it to a newly created release 
branch, and ship it, by itself. In that way the release branch doesn't 
have flotsum/jetsum in it.


This of course stresses the CI environment as now you are going to ask 
to build n branches at once, but not that big of a deal.


---


On 2017-01-10 11:13, Ariel Weisberg wrote:

Hi,

With yearly releases trunk is going to be a mess when it comes time to
cut a release. Cutting releases is when people start caring whether all
the things in the release are in a finished state. It's when the state
of CI finally becomes relevant.

If we wait a year we are going to accumulate a years worth of 
unfinished

stuff in a single release. It's more expensive to context switch back
and then address those issues. If we put out large unstable releases it
means time until the features in the release are usable is pushed back
even further since it takes another 6-12 months for the release to
stabilize. Features introduced at the beginning of the cycle will have
to wait 18-24 months before anyone can benefit from them.

Is the biggest pain point with tick-tock just the elimination of long
term support releases? What is the pain point around release frequency?
Right now people should be using 3.0 unless they need a bleeding edge
feature from 3.X and those people will have to give up something to get
something.

Ariel

On Tue, Jan 10, 2017, at 10:29 AM, Jonathan Haddad wrote:
I don't see why it has to be one extreme (yearly) or another 
(monthly).

When you had originally proposed Tick Tock, you wrote:

"The primary goal is to improve release quality.  Our current major 
“dot

zero” releases require another five or six months to make them stable
enough for production.  This is directly related to how we pile 
features

in
for 9 to 12 months and release all at once.  The interactions between 
the
new features are complex and not always obvious.  2.1 was no 
exception,
despite DataStax hiring a full tme test engineering team specifically 
for

Apache Cassandra."

I agreed with you at the time that the yearly cycle was too long to be
adding features before cutting a release, and still do now.  Instead 
of

elastic banding all the way back to a process which wasn't working
before,
why not try somewhere in the middle?  A release every 6 months (with
monthly bug fixes for a year) gives:

1. long enough time to stabilize (1 year vs 1 month)
2. not so long things sit around untested forever
3. only 2 releases (current and previous) to do bug fix support at any
given time.

Jon

On Tue, Jan 10, 2017 at 6:56 AM Jonathan Ellis  
wrote:


> Hi all,
>
> We’ve had a few threads now about the successes and failures of the
> tick-tock release process and what to do to replace it, but they all died
> out without reaching a robust consensus.
>
> In those threads we saw several reasonable options proposed, but from my
> perspective they all operated in a kind of theoretical fantasy land of
> testing and development resources.  In particular, it takes around a
> person-week of effort to verify that a release is ready.  That is, going
> through all the test suites, inspecting and re-running failing tests to see
> if there is a product problem or a flaky test.
>
> (I agree that in a perfect world this wouldn’t be necessary because your
> test ci is always green, but see my previous framing of the perfect world
> as a fantasy land.  It’s also worth noting that this is a common problem
> for large OSS projects, not necessarily something to beat ourselves up
> over, but in any case, that's our reality right now.)
>
> I submit that any process that assumes a monthly release cadence is not
> realistic from a resourcing standpoint for this validation.  Notably, we
> have struggled to marshal this for 3.10 for two months now.
>
> Therefore, I suggest first that we collectively roll up our sleeves to vet
> 3.10 as the last tick-tock release.  Stick a fork in it, it’s done.  No
> more tick-tock.
>
> I further suggest that in place of tick tock we go back to our old model of
> yearly-ish releases with as-needed bug fix releases on stable branches,
> probably bi-monthly.  This amortizes the release validation problem over a
> longer development period.  And of course we remain free to ramp back up to
> the more rapid cadence envisioned by the other proposals if we increase our
> pool of QA effort or we are able to eliminate flakey tests to the point
> that a long va

Re: Why shaded Datastax java-driver?

[Dave Brosius]

Some of the tools use the driver, and there is some reliance on classes 
for user defined types that come from the driver. I suppose ideally 
these would get split out into a cassandra-common.jar, or such.



"Shaded" in this case means that the jar contains code from netty, but 
the package structure is changed so that there are no conflicts with a 
real netty jar.



On 01/30/2017 11:26 AM, Tomas Repik wrote:

Hello list,
why is datastax java-driver so tightly fixed to the cassandra base?
Is there any reason to have it as a shaded dependency?
And what even a shaded dependency is?

I'd be glad for any response.

Thanks Tomas

Re: Contribute to the Cassandra wiki

[Dave Brosius]

You've been added


On 03/12/2017 07:14 PM, Anthony Grasso wrote:

Hi

My username is AnthonyGrasso and I would like to contribute to the
Cassandra wiki please.

Kind regards,
Anthony

Re: Wish to contribute to Cassandra wiki

[Dave Brosius]

added

---


On 2017-03-14 01:15, RAHUL PANCHAL wrote:

Hi



My username is RahulPanchal. I would like to contribute to the

Cassandra wiki please.



Thanks

Rahul

Re: Contribute to the Cassandra Wiki

[Dave Brosius]

done

---


On 2017-03-17 06:02, Rahul S wrote:

Hi
I would like to contribute to the Cassandra wiki please. My username
is rahul3.

Thanks
Rahul

From Alia to Anushka, Arijit to Armaan, Papon to Pritam, Sonu to
Sukhwinder and Varun to Diljit - the biggest music and Bollywood stars
say Music ko Mirchi ka Salaam! Catch the Royal Stag Mirchi Music
Awards on 19th March at 8 PM on Zee TV.

Re: [VOTE] self-assignment of jira tickets

[Dave Brosius]

+1


On 2017-03-29 09:21, Jason Brown wrote:

Hey all,

Following up my thread from a week or two ago (
https://lists.apache.org/thread.html/0665f40c7213654e99817141972c003a2131aba7a1c63d6765db75c5@%3Cdev.cassandra.apache.org%3E),
I'd like to propose a vote to change to allow any potential contributor 
to
assign a jira to themselves without needing to be added to the 
contributors

group first.

https://issues.apache.org/jira/browse/INFRA-11950 is an example of how 
to

get this done with INFRA.

Vote will be open for 72 hours.

Thanks,

-Jason Brown

Re: Proposal to retroactively mark materialized views experimental

[Dave Brosius]

triggers


On 10/01/2017 11:25 AM, Jeff Jirsa wrote:

Historical examples are anything that you wouldn’t bet your job on for the 
first release:

Udf/uda in 2.2
Incremental repair - would have yanked the flag following 9143
SASI - probably still experimental
Counters - all sorts of correctness issues originally, no longer true since the 
rewrite in 2.1
Vnodes - or at least shuffle
CDC - is the API going to change or is it good as-is?
CQL - we’re on v3, what’s that say about v1?

Basically anything where we can’t definitively say “this feature is going to 
work for you, build your product on it” because companies around the world are 
trying to make that determination on their own, and they don’t have the same 
insight that the active committers have.

The transition out we could define as a fixed number of releases or a dev@ 
vote, I don’t think you’ll find something that applies to all experimental 
features, so being flexible is probably the best bet there





-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Dave Brosius]

I think the reason there's such a kerfuffle around a 'close-to-now' 
freeze date is more of a concern as to when cassandra 5.0 is going to be 
released. I'm assuming if people thought 5.0 was going to be released in 
early 2019 no one would have a problem with setting the freeze date of 
4.0 to _right now_. But most likely people are thinking 5.0~sun explode 
time, and want to jam anything remotely protocol-breaking into 4 that 
they can now. I realize people are reticent about having a quick 
pipeline of .0 releases, which causes multiple release branches to 
support, but it seems that's the only way to actually get them out.



On 04/12/2018 06:45 PM, Jonathan Ellis wrote:

The thing is, good intentions are cheap. And they get cheaper the further
out in the future the point of action gets.

Realistically, the main difference between June and September is we ship
three months later. More, if we manage to land large, destabilizing patches
in the meantime.  I’m very skeptical it will actually result in additional
testing.  In my experience, people start testing once you actually have an
alpha or beta released. And even then they prefer to wait for a dot zero.

We only have about nine years of project history showing this, though.
I’m sure this time  will be different.

On Thu, Apr 12, 2018 at 3:59 PM Ben Bromhead  wrote:


While I would prefer earlier, if Sept 1 gets better buy-in and we can have
broader commitment to testing. I'm super happy with that. As Nate said,
having a solid line to work towards is going to help massively.

On Thu, Apr 12, 2018 at 4:07 PM Nate McCall  wrote:


If we push it to Sept 1 freeze, I'll personally spend a lot of time

testing.

What can I do to help convince the Jun1 folks that Sept1 is acceptable?

I can come around to that. At this point, I really just want us to
have a date we can start talking to/planning around.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

--

Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer




-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Error while running Cassandra CLI

[Dave Brosius]

I'd try these instructions

http://wiki.apache.org/cassandra/HowToDebug



On 08/13/2012 02:43 PM, Jonathan Ellis wrote:

Sounds like a classpath problem.  Perhaps you just need to add the
resources directory to your Eclipse project.

On Wed, Aug 8, 2012 at 6:25 PM, Saurabh Lodha  wrote:

Hi All,

I am interested in contributing to the Cassandra project. As a first step, I 
have setup my development environment based on the instructions over here:
http://wiki.apache.org/cassandra/RunningCassandraInEclipse

My run/debug configuration is using the following class as the main class:
org.apache.cassandra.service.CassandraDaemon

Following is the output on the console on starting cassandra:
  INFO 19:24:15,422 JVM vendor/version: Java HotSpot(TM) 64-Bit Server 
VM/1.6.0_33
  INFO 19:24:15,434 Heap size: 85000192/1065025536
  INFO 19:24:15,434 Classpath: 
/Users/saurabhlodha/Documents/cassandra-trunk/build/classes/main:/Users/saurabhlodha/Documents/cassandra-trunk/build/classes/thrift:/Users/saurabhlodha/Documents/cassandra-trunk/build/test/classes:/Users/saurabhlodha/Documents/cassandra-trunk/test/conf:/Users/saurabhlodha/Documents/cassandra-trunk/lib/antlr-3.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/avro-1.4.0-fixes.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/avro-1.4.0-sources-fixes.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/commons-cli-1.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/commons-codec-1.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/commons-lang-2.6.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/compress-lzf-0.8.4.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/concurrentlinkedhashmap-lru-1.3.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/guava-12.0.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/high-scale-lib-1.1.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/jackson-core-asl-1.9.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/jackson-mapper-asl-1.9.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/jamm-0.2.5.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/jline-1.0.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/json-simple-1.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/libthrift-0.7.0.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/log4j-1.2.16.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/metrics-core-2.0.3.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/netty-3.5.2.Final.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/servlet-api-2.5-20081211.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/slf4j-api-1.6.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/slf4j-log4j12-1.6.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/snakeyaml-1.6.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/snappy-java-1.0.4.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/lib/snaptree-0.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/ant-1.6.5.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/apache-rat-0.6.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/apache-rat-core-0.6.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/apache-rat-tasks-0.6.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/asm-3.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/avro-1.3.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-beanutils-1.7.0.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-beanutils-core-1.8.0.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-cli-1.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-codec-1.4.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-collections-3.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-configuration-1.6.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-digester-1.8.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-el-1.0.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-httpclient-3.0.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-lang-2.4.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-logging-1.1.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-math-2.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/commons-net-1.4.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/core-3.1.1.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/hadoop-core-0.20.203.0.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/hsqldb-1.8.0.10.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/jackson-core-asl-1.4.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/jackson-mapper-asl-1.4.2.jar:/Users/saurabhlodha/Documents/cassandra-trunk/build/lib/jars/jasper-compi

Re: [VOTE] Release Apache Cassandra 1.1.4

[Dave Brosius]

Internal version 51 is definitely Java 7

On 08/13/2012 11:56 PM, Cathy Daw wrote:

I received an error starting the server and Jonathan suggested it may be due to 
having the binary compiled with Java 1.7.

The binary is from 
https://repository.apache.org/content/repositories/orgapachecassandra-134/org/apache/cassandra/apache-cassandra/1.1.4/apache-cassandra-1.1.4-bin.tar.gz

$ ./cassandra
xss =  -ea -javaagent:./../lib/jamm-0.2.5.jar -XX:+UseThreadPriorities 
-XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn200M 
-XX:+HeapDumpOnOutOfMemoryError
Cathy-Daws-MacBook-Pro:bin cathy$ Exception in thread "main" 
java.lang.UnsupportedClassVersionError: org/apache/cassandra/thrift/CassandraDaemon : 
Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)


On Aug 13, 2012, at 4:09 PM, Jonathan Ellis wrote:


I just now added #4494 to CHANGES, but probably not worth re-rolling
for.  +1 from me

On Mon, Aug 13, 2012 at 4:44 PM, Eric Evans  wrote:

There are bug-fixes worthy of a minor release sitting in 1.1, and
Sylvain is taking a holiday, so here's hoping that I remember how all
of this goes.

I propose the following for release as 1.1.4.  Check it over carefully
though, it's entirely possible I missed dotting an I, or crossing a T
somewhere. :)

SHA1: 9dc5608
Git: 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.4-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-134/org/apache/cassandra/apache-cassandra/1.1.4
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-134

The artifacts as well as the debian package are also available here:
http://people.apache.org/~eevans

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/kmyHH (CHANGES.txt)
[2]: http://goo.gl/Dw4mM (NEWS.txt)

--
Eric Evans
Acunu | http://www.acunu.com | @acunu



--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: slf4j

[Dave Brosius]

There are actually 2 arguments the OP is making.. the second, using

{} : {}


over

descriptor + ": " + (System.currentTimeMillis() - start)

is reasonable.


On 11/23/2012 10:18 AM, Jonathan Ellis wrote:

I prefer the concise approach when no evaluation needs to be performed
on the method arguments, but when it does I prefer the explicit
isDebugEnabled check, or else reviewers need to think each time they
see one, "is this a hot code path where we can afford to be sloppy, or
not?"

On Fri, Nov 23, 2012 at 9:14 AM, Stephen Connolly
 wrote:

On 22 November 2012 17:51, Radim Kolar  wrote:


instead of this:

if (logger.isDebugEnabled())
 logger.debug("INDEX LOAD TIME for " + descriptor + ": " +
(System.currentTimeMillis() - start) + " ms.");

do this:
 logger.debug("INDEX LOAD TIME for {} : {} ms.", descriptor,
(System.currentTimeMillis() - start));


Yes, but until/unless the JVM elides the function call because that logger
is not enabled fro debug, you will incur the penalty of new
Object[]{string,new Long(System.currentTimeMillis() - start).

On top of that, when debug is enabled you incur the cost of formatting the
string, including the {} search & replace.

On a long running production system, you are correct that it should
*eventually* be equivalent, and I am not saying one way or the other
whether this should/shouldn't be changed... more just pointing out that
there are consequences to what might appear to be a trivial change... I'll
let the c* devs chime in as to what their strong opinion is in this regard
as they should have more experience handling high loads and I would love to
know which pattern I should be using in my code (FWIW I tend to favour your
approach to the if (debugEnabled) guard... but I always wonder ;-) )

-Stephen



easier to read.

Re: [VOTE] Release Apache Cassandra 1.2.0-beta3

[Dave Brosius]

+1

On 12/03/2012 01:43 PM, Sylvain Lebresne wrote:

So it seems we have a few things to fix before calling it a proper release
candidate, but we still have had quite a bit of changes since beta2 so I
propose the following artifacts for release as 1.2.0-beta3.

sha1: b86f75dcd7041815bb66eb3d1bb2c143f8ba5d58
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.0-beta3-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-108/org/apache/cassandra/apache-cassandra/1.2.0-beta3/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-108/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~slebresne/

Since the artifacts are basically the same ones that for the previous rc1
vote,
the vote will be a short one and will be open for 24 hours (but longer if
needed).

[1]: http://goo.gl/VUWhd (CHANGES.txt)
[2]: http://goo.gl/IGHq3 (NEWS.txt)

Re: Cassandra 1.2

[Dave Brosius]

probably a good idea to put the original issue on jire, anyway.

https://issues.apache.org/jira/browse/CASSANDRA



On 01/05/2013 11:16 AM, Pierre Chalamet wrote:

Hello,

Removing the extra parenthesis around the primary key definition seems to
work as expected:
CREATE TABLE foo2 (a int, b text, c uuid,   PRIMARY KEY (a, b) );
INSERT INTO foo2 (a, b , c ) VALUES (  1 , 'aze',
'4d481800-4c5f-11e1-82e0-3f484de45426');
INSERT INTO foo2 (a, b , c ) VALUES (  1 , 'ert',
'693f5800-8acb-11e3-82e0-3f484de45426');
INSERT INTO foo2 (a, b , c ) VALUES (  1 , 'opl',
'd4815800-2d8d-11e0-82e0-3f484de45426');

localhost> select * from foo where a=1;
+---+-+--+
| a | b   | c|
+===+=+==+
| 1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426 |
+---+-+--+
| 1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426 |
+---+-+--+

localhost> select * from foo2 where a=1;
+---+-+--+
| a | b   | c|
+===+=+==+
| 1 | aze | 4d481800-4c5f-11e1-82e0-3f484de45426 |
+---+-+--+
| 1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426 |
+---+-+--+
| 1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426 |
+---+-+--+

Looks like there is something weird happening when creating the table.

- Pierre

-Original Message-
From: Kais Ahmed [mailto:k...@neteck-fr.com]
Sent: Saturday, January 05, 2013 2:30 PM
To: dev@cassandra.apache.org
Subject: Cassandra 1.2

Hi all,

I create a table in cassandra 1.2, and makes two queries, the second query
gives me a false result, is this normal behavior?



--
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.35.0]

cqlsh:test> CREATE TABLE foo (   a int,   b text,   c uuid,   PRIMARY KEY
((a, b)) );

cqlsh:test> INSERT INTO foo (a, b , c ) VALUES (  1 , 'aze',
'4d481800-4c5f-11e1-82e0-3f484de45426');
cqlsh:test> INSERT INTO foo (a, b , c ) VALUES (  1 , 'ert',
'693f5800-8acb-11e3-82e0-3f484de45426');
cqlsh:test> INSERT INTO foo (a, b , c ) VALUES (  1 , 'opl',
'd4815800-2d8d-11e0-82e0-3f484de45426');


-

cqlsh:test> SELECT * FROM foo;

  a | b   | c
---+-+--
  1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
  1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426
  1 | aze | 4d481800-4c5f-11e1-82e0-3f484de45426


-

cqlsh:test> SELECT * FROM foo where a=1;

  a | b   | c
---+-+--
  1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
  1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426

Re: Cassandra

[Dave Brosius]

Done


On 06/10/2013 05:25 PM, Stephen Blackheath [to Cassandra] wrote:

Hi,

I've developed a CQL protocol client for Haskell and would like to 
advertise it on the


https://wiki.apache.org/cassandra/ClientOptions

page. I've created a user account StephenBlackheath. Could I get page 
edit privileges for that page?


Thanks!

My code is here: http://hackage.haskell.org/package/cassandra-cql
and here: https://github.com/the-real-blackh/cassandra-cql


Steve

Re: wiki bootstrap doc

[Dave Brosius]

fixed, thanks

On 07/12/2013 08:13 PM, Radim Kolar wrote:

http://wiki.apache.org/cassandra/Operations*

*
To bootstrap a node, turn _AutoBootstrap_ on in the configuration 
file, and start it. *


*its called *auto_bootstrap *in config file

Re: cassandra pull request: JDK7 u40 stack size fixes

[Dave Brosius]

Please open a ticket here 
https://issues.apache.org/jira/browse/CASSANDRA and attach a patch 
please.  Currently we don't pull, pull requests.


On 08/08/2013 05:37 PM, jdsumsion wrote:

GitHub user jdsumsion opened a pull request:

 https://github.com/apache/cassandra/pull/18

 JDK7 u40 stack size fixes

 I use Archlinux, and the latest OpenJDK, and run my cassandra via 
@pcmanus's ccm.
 
 When I tried the cassandra-2.0.0 branch via:

 $ ccm create -v git:cassandra-2.0.0
 
 Then when I say:

 $ ccm populate -n3
 $ ccm node1 start -v
 
 I get the following error:

 xss =  -ea 
-javaagent:/home/blah/.ccm/repository/1.2.2/lib/jamm-0.2.5.jar 
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1985M -Xmx1985M 
-Xmn496M -XX:+HeapDumpOnOutOfMemoryError -Xss180k
 
 The stack size specified is too small, Specify at least 228k

 Error starting node node1
 Standard error output is:
 Error: Could not create the Java Virtual Machine.
 Error: A fatal exception has occurred. Program will exit.
 
 I tracked it down to conf/cassandra-env.sh, and changed the -Xss180k => -Xss228k and the node started.


You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/jdsumsion/cassandra jdk7-updates

Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/cassandra/pull/18.patch

Re: Time for a release candidate?

[Dave Brosius]

On 08/11/2013 10:51 PM, Brandon Williams wrote:

On Sun, Aug 11, 2013 at 9:35 PM, Jonathan Ellis  wrote:


We hadn't actually set vnodes to be on by default, which we should do
after having 1.2 default to old single token per node.  Fixed in
CASSANDRA-5869 so let's roll an rc2.



Let's get https://issues.apache.org/jira/browse/CASSANDRA-5856 solved first.

-Brandon



There is a blank README.txt file in the conf/triggers directory. (or 
perhaps written in lemon-ink).

Re: Cassandra project set up error

[Dave Brosius]

Yeah, there's a problem when running c* in IDEs, it doesn't find the 
version to send down to the client.


You can edit the cqlsh file to remove the version parsing at

File "./cqlsh", line 580, in get_connection_versions
self.cass_ver_tuple = tuple(map(int, vers['build'].split('-',
1)[0].split('.')[:3]))





On 08/23/2013 03:50 AM, Nipuni Piyabasi Perera wrote:

Hi,

I am trying to run Cassandra configuration I have set up in IDEA and
connect to it. When I run the "CassandraDaemon" and try to connect using
command ./cqlsh, it gives the following error in the terminal:

Traceback (most recent call last):
   File "./cqlsh", line 2027, in 
 main(*read_options(sys.argv[1:], os.environ))
   File "./cqlsh", line 2013, in main
 display_float_precision=options.float_precision)
   File "./cqlsh", line 486, in __init__
 self.get_connection_versions()
   File "./cqlsh", line 580, in get_connection_versions
 self.cass_ver_tuple = tuple(map(int, vers['build'].split('-',
1)[0].split('.')[:3]))
ValueError: invalid literal for int() with base 10: 'Unknown'


I have checked the port 127.0.0.1:9160 and it is open. But can not connect.

Thanks,
Nipuni


On Fri, Aug 23, 2013 at 5:44 AM, Nipuni Piyabasi Perera <
nipuni880...@gmail.com> wrote:


Hi,

This is fixed after deleting files in the system keysapce.

Thanks,
Nipuni


On Fri, Aug 23, 2013 at 5:33 AM, Nipuni Piyabasi Perera <
nipuni880...@gmail.com> wrote:


Hi,

I could build via generating eclipse files without adding any external
jars. But the error was due to class path to cassandra.yaml file. It worked
when added "file:" at the beginning of the path name.

Now I am getting the following error.

ERROR 00:00:09 Fatal exception during initialization
org.apache.cassandra.exceptions.ConfigurationException: Saved cluster
name MyClusterName != configured name Test Cluster

Thanks,
Nipuni


On Thu, Aug 22, 2013 at 7:39 PM, J.B. Langston wrote:


I have found the easiest way to get Cassandra to build under IDEA is to
use ant to generate the eclipse project files (see
http://wiki.apache.org/cassandra/RunningCassandraInEclipse) and then
import those into IDEA.  Setting it up in IDEA directly is an error-prone
manual process with way too many steps, and some of the instructions refer
to things that have moved or changed names in the latest version of IDEA.

On Aug 22, 2013, at 6:00 AM, Nipuni Piyabasi Perera <
nipuni880...@gmail.com> wrote:


I can't find "storage-conf.xml" file. If "cassandra.yaml" is used

instead,

how should I set the configuration?.

Thanks,
Nipuni


On Thu, Aug 22, 2013 at 2:05 PM, Nipuni Piyabasi Perera <
nipuni880...@gmail.com> wrote:


Hi,

I am trying build Cassandra as an Idea project. following guide [1].

But

when creating the RUN configuration. I have to add several

dependencies

externally (hadoop, pig).
But still there is an error in the class.

org.apache.cassandra.hadoop.AbstractColumnFamilyRecordWriter

error is :

org.apache.hadoop.mapreduce.RecordWriter' clashes with 'write(K, V)'

in

'org.apache.hadoop.mapred.RecordWriter'; overridden method does not

throw

'java.lang.InterruptedException'

Even with the error I could run the application, which then it gives a
configuration error as follows:

ERROR 08:28:04 Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: Cannot locate


/home/nipuni/Desktop/Cassendra/Cassendra_code/cassandra-trunk/conf/cassandra.yaml

Is there any other documentation to set up Cassandra.

[1] http://wiki.apache.org/cassandra/RunningCassandraInIDEA


Thanks,
Nipuni
--
Nipuni Piyabasi Perera
Undergraduate
Department of Computer Science And Engineering
University of Moratuwa
Sri Lanka




--
Nipuni Piyabasi Perera
Undergraduate
Department of Computer Science And Engineering
University of Moratuwa
Sri Lanka




--
Nipuni Piyabasi Perera
Undergraduate
Department of Computer Science And Engineering
University of Moratuwa
Sri Lanka




--
Nipuni Piyabasi Perera
Undergraduate
Department of Computer Science And Engineering
University of Moratuwa
Sri Lanka

Re: Secondary Index Storage

[Dave Brosius]

the location is loaded from the

cassandra.yaml,

specifically the entry

data_file_directories

This is loaded into the class

Config.java

using 3rdparty library snakeyaml


On 08/23/2013 06:34 AM, Nipuni Piyabasi Perera wrote:

Hi,

Ok, so if I want to make it separate and test, where should I refer? From
where the keyspace refer to the location "/var/lib/cassandra/data". I have
debug the code, and could see some variables (e.g jdk location etc) can be
accessed from :

System.getProperty("");

But this does not contain the disk location to keyspace.

Thanks,
Nipuni


On Fri, Aug 23, 2013 at 9:52 AM, Jonathan Ellis  wrote:


Sorry, Aleksey pointed out that the index directory isn't separate from the
"parent" table.  Probably so that we can snapshot them both together, which
is why the separate config in .yaml doesn't make sense either.


On Thu, Aug 22, 2013 at 11:07 PM, Jonathan Ellis 
wrote:


You can already symlink the index directory anywhere you like.  I'm not
convinced that special-casing indexes is a good approach in general vs
looking at performance of all tables.


On Thu, Aug 22, 2013 at 8:16 PM, Nipuni Piyabasi Perera <
nipuni880...@gmail.com> wrote:


Hi,

I need to do a secondary index access improvement with a little
modification to Cassandra. I could see in [1], that the performance of
secondary index querying can be increased via splitting the column

family

data and secondary index data.
Currently Cassandra saves keyspace data and secondary indices data in
"var/lib/cassandra/data/".
According to my understanding the data saves in the
"data_file_directories"
location of conf/cassandra.yaml file. If I can enter new variable into
"cassandra.yaml" file and address it in the place where Cassandra stores
secondary indexes, this can be fixed.

Can anyone give some guidance regarding this improvement.

[1] https://issues.apache.org/jira/browse/CASSANDRA-5502

Thanks,
Nipuni

--
Nipuni Piyabasi Perera
Undergraduate
Department of Computer Science And Engineering
University of Moratuwa
Sri Lanka




--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced




--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: cassandra pull request: Fix cassandra daemon management under debian/ubuntu

[Dave Brosius]

please add an apache jira ticket for this here:

https://issues.apache.org/jira/browse/CASSANDRA



On 09/24/2013 03:41 PM, lra wrote:

GitHub user lra opened a pull request:

 https://github.com/apache/cassandra/pull/21

 Fix cassandra daemon management under debian/ubuntu

 This PR tries to fix 2 problems when installing the package on Ubuntu (and 
I think Debian)
 
 1. `/var/run/cassandra` is missing and the pid file is not created on start, which renders the init script useless

 2. the regexp used to check if cassandra is running does not match the launching 
command line (There is no "-user." in the launch command)

You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/lra/cassandra fix_debian_init_d

Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/cassandra/pull/21.patch

Re: Is row isolation broken?

[Dave Brosius]

see https://issues.apache.org/jira/browse/CASSANDRA-6123


 Break timestamp ties consistently for a given user requests





On 10/02/2013 11:35 PM, Ramon Nogueira wrote:

After reading this: http://aphyr.com/posts/294-call-me-maybe-cassandra

I decided to try to break row isolation myself:
https://github.com/ramonza/cassandra-row-isolation

To run it you just need a single node running on localhost. Tested with
2.0.1.

The test fails very consistently. Row isolation seems to be broken. I would
like to log a ticket as I couldn't find one addressing this issue. I'm also
keen to help out fixing this.

RE: [VOTE] Release Apache Cassandra 2.0.3 (Strike 2)

[Dave Brosius]

 Send that email to dev-unsubscribe@cassandra.apache.orgor click 
belowhttp://tinyurl.com/mjosbft  - Original Message -From: 
"Lowery, Michael" >;michael.low...@hbgusa.com

Re: Proposal: freeze Thrift starting with 2.1.0

[Dave Brosius]

+1,

altho supporting thrift in 2.1 seems overly conservative.

If you are using thrift there probably isn't a reason to upgrade to 2.1, 
in fact doing so will become an increasingly dumb idea as lesser and 
lesser emphasis will be placed on testing with 2.1+. This would allow us 
to greatly simplify the code footprint in 2.1





On 03/11/2014 01:00 PM, Jonathan Ellis wrote:

CQL3 is almost two years old now and has proved to be the better API
that Cassandra needed.  CQL drivers have caught up with and passed the
Thrift ones in terms of features, performance, and usability.  CQL is
easier to learn and more productive than Thrift.

With static columns and LWT batch support [1] landing in 2.0.6, and
UDT in 2.1 [2], I don't know of any use cases for Thrift that can't be
done in CQL.  Contrawise, CQL makes many things easy that are
difficult to impossible in Thrift.  New development is overwhelmingly
done using CQL.

To date we have had an unofficial and poorly defined policy of "add
support for new features to Thrift when that is 'easy.'"  However,
even relatively simple Thrift changes can create subtle complications
for the rest of the server; for instance, allowing Thrift range
tombtones would make filter conversion for CASSANDRA-6506 more
difficult.

Thus, I think it's time to officially close the book on Thrift.  We
will retain it for backwards compatibility, but we will commit to
adding no new features or changes to the Thrift API after 2.1.0.  This
will help send an unambiguous message to users and eliminate any
remaining confusion from supporting two APIs.  If any new use cases
come to light that can be done with Thrift but not CQL, we will commit
to supporting those in CQL.

(To a large degree, this merely formalizes what is already de facto
reality.  Most thrift clients have not even added support for
atomic_batch_mutate and cas from 2.0, and popular clients like
Astyanax are migrating to the native protocol.)

Reasonable?

[1] https://issues.apache.org/jira/browse/CASSANDRA-6561
[2] https://issues.apache.org/jira/browse/CASSANDRA-5590

Re: Proposal: freeze Thrift starting with 2.1.0

[Dave Brosius]

Those concerns of yours came from my post (probably). I'd just like to 
explain. Obviously no one is going to purposely not test thrift as we go 
forward, and hopefully thrift users will gain benefits from future 
releases in terms of performance and the like. The core cassandra devs 
i've worked with have all been fantastic about it and are tremendous 
folks.


However, it's just human behaviour that if a group of devs are focused 
on making (A) better, faster, more feature-full, the less time is spent 
focused on (B). (B) is relegated to did we break (B)?, and hopefully 
some testing is done days before a release is about to go out. This 
maintenance mode thought process isn't something developers are usually 
very good at. So as new releases come out, the better (A) will be, and 
unfortunately, most times (B) gets worse unfortunately. In my experience 
once you decide not to actively develop something it starts rotting 
almost immediately, and it's caveat emptor for folks who want to use it 
going forward. (This is really unrelated to cassandra, but development 
in general). IMO it is better to just make the cut, so that you can 
focus entirely on what the future plan is, and gain significant velocity 
in development because of it.



Of course that is just my opinion, which in this case won't be taken. 
Cassandra will still maintain compatibility for Thrift going forward. 
I'd suggest it would be in the Thrift supporters best interest (even 
more so now) to do early pre-release testing and get involved early.


dave



---


On 2014-03-26 11:15, Chris Burroughs wrote:

FWIW even for new development we have found thrift preferable to CQL.
Others have have a different experience and that's cool.  It's
certinaly made it less intimidating to new users when explaining
Cassandra.

I'm very concerned at the sentiments in this thread about not testing
or upgrading to 2.1 being a "dumb" idea.  The thing we value most from
Cassandra is that it works.  Operability, stability, and robustness
are by far the most important traits.  I can deal with wrapping APIs
and transport layers.  Dealing with untested releases is much more
complicated.

Re: possible content for C* wiki

[Dave Brosius]

Feel free to add it to the WIKI, if you need an account let us know and 
we can add one for you.


Thanks!

---


On 2014-05-09 21:49, Daniel Shelepov wrote:

Hello,



I've recently undertook a study into Cassandra internals.  One of the
reasons was because the available documentation, such as pages like 
this

(http://wiki.apache.org/cassandra/ArchitectureInternals ) weren't very
complete.  One of the outcomes of the study was a blog post about C*
top-level packages (talking about Java here).  If people think it's a 
useful
overview, I could adapt that content to be put on the wiki so other 
people
can find it.  If it's not a good fit, no problem (not trying to be 
pushy

here).  The blog post is this one
http://timefork.com/blog/apache-cassandra-internals .



Regardless of whether it goes into the wiki or not, if someone has
corrections or is otherwise opinionated, I'm happy to hear him out.



Daniel

Re: Refactoring cassandra service package

[Dave Brosius]

This is a relatively stupid comment, but i'm good at that so here goes.

The solution to several of these issues is,

Refactor 1 singleton use case, and post a patch.

1) less classes are involved
2) the review is more likely to be understood by one person
3) less chance for regression
4) marginally more modular code

When that goes well, pick another one.

There still is the issue of

 >> 4. Complicated merges when bugs need to be fixed in older versions.

On 2014-06-03 15:20, Simon Chemouil wrote:

Gary Dusbabek racontait le 03/06/2014 19:59:

This has come up before. Let's face it, removing the singletons is a
tempting proposition.

Several of us have been down the path of trying to do it.

At the end of the day, here's what you'd end up with (absolutely best 
case):


1. Modifying just about every class, sometimes substantially.
2. A huge patch for someone else to review.
3. No performance gains, no bug fixes.  In fact, since so many classes 
have
to be changed, I'd say that the risk of introducing a bug/regression 
is

fairly likely.
4. Complicated merges when bugs need to be fixed in older versions.
5. More modular and testable code.

So far, the positive aspects of 5 have not been able to trump the
challenges presented by 1, 2, 3, and 4.


Thanks for your reply. I understand the reasoning, yet obviously I 
think

your 5th point weighs a lot more than the others, because it also means
more hackable code, and though a huge patch might be scary, seeing so
many static fields is scary as well ;).

We could make the patch more manageable by splitting it in several
patches, one per 'service', and start from the leaves of the dependency
graph (services not using other services), but we'd have to apply the
patches in a specific order. Still, it would make it easier to review.

The 3rd point is I guess usual in the life of an healthy project: 
fixing
the 'technical debt' the project accumulated over the years seems 
almost

as important as fixing bugs and improving performance. While doing it,
we would also port the tests and hopefully introduce new tests to make
sure we didn't introduce bugs, and generally be careful we don't break
anything. Yes, there might be new bugs, probably the kind of bugs that
are already there but lurking because of the initialization order or
relying on specific side-effects, but those already exist and might pop
out any time. Refactoring this code seems, for the most part, to be a
fairly repetitive process and doing it carefully should allow to avoid
most bugs introduced by inattention.

The (4) is an important problem, but merging this would probably mean a
major version bump (e.g, within the 3.0.0 branch), and at some point in
time, older versions will reach their EOL. It seems to me that only bug
fixes are backported, and the patches already have to be adapted for 
the

1.x branch... But unless people give up entirely on the idea of fixing
this, this problem is going to become worse as time goes by.

Cheers,

Simon



Kind Regards,

Gary.




Cheers,

--
Simon


[1]

http://grokbase.com/t/cassandra/dev/107xr48hek/creating-two-instances-in-code

Re: Refactoring cassandra service package

[Dave Brosius]

It also means that problems that are introduced are bisectable, which 
given these changes would be a real benefit.


It also means if the process doesn't go well, you won't hate reviewers 
for life.


On 2014-06-03 17:24, Dave Brosius wrote:

This is a relatively stupid comment, but i'm good at that so here goes.

The solution to several of these issues is,

Refactor 1 singleton use case, and post a patch.

1) less classes are involved
2) the review is more likely to be understood by one person
3) less chance for regression
4) marginally more modular code

When that goes well, pick another one.

There still is the issue of

 >> 4. Complicated merges when bugs need to be fixed in older versions.

On 2014-06-03 15:20, Simon Chemouil wrote:

Gary Dusbabek racontait le 03/06/2014 19:59:

This has come up before. Let's face it, removing the singletons is a
tempting proposition.

Several of us have been down the path of trying to do it.

At the end of the day, here's what you'd end up with (absolutely best 
case):


1. Modifying just about every class, sometimes substantially.
2. A huge patch for someone else to review.
3. No performance gains, no bug fixes.  In fact, since so many 
classes have
to be changed, I'd say that the risk of introducing a bug/regression 
is

fairly likely.
4. Complicated merges when bugs need to be fixed in older versions.
5. More modular and testable code.

So far, the positive aspects of 5 have not been able to trump the
challenges presented by 1, 2, 3, and 4.


Thanks for your reply. I understand the reasoning, yet obviously I 
think
your 5th point weighs a lot more than the others, because it also 
means

more hackable code, and though a huge patch might be scary, seeing so
many static fields is scary as well ;).

We could make the patch more manageable by splitting it in several
patches, one per 'service', and start from the leaves of the 
dependency

graph (services not using other services), but we'd have to apply the
patches in a specific order. Still, it would make it easier to review.

The 3rd point is I guess usual in the life of an healthy project: 
fixing
the 'technical debt' the project accumulated over the years seems 
almost

as important as fixing bugs and improving performance. While doing it,
we would also port the tests and hopefully introduce new tests to make
sure we didn't introduce bugs, and generally be careful we don't break
anything. Yes, there might be new bugs, probably the kind of bugs that
are already there but lurking because of the initialization order or
relying on specific side-effects, but those already exist and might 
pop

out any time. Refactoring this code seems, for the most part, to be a
fairly repetitive process and doing it carefully should allow to avoid
most bugs introduced by inattention.

The (4) is an important problem, but merging this would probably mean 
a
major version bump (e.g, within the 3.0.0 branch), and at some point 
in
time, older versions will reach their EOL. It seems to me that only 
bug
fixes are backported, and the patches already have to be adapted for 
the

1.x branch... But unless people give up entirely on the idea of fixing
this, this problem is going to become worse as time goes by.

Cheers,

Simon



Kind Regards,

Gary.




Cheers,

--
Simon


[1]

http://grokbase.com/t/cassandra/dev/107xr48hek/creating-two-instances-in-code

Re: 3.0 and the Cassandra release process

[Dave Brosius]

It would seem the practical implications of this is that there would be 
significantly more development on branches, with potentially more 
significant delays on merging these branches. This would imply to me 
that more Jenkins servers would need to be set up to handle auto-testing 
of more branches, as if feature work spends more time on external 
branches, it is then likely to be be less tested (even if by accident) 
as less developers would be working on that branch. Only when a feature 
was blessed to make it to the release-tracked branch, would it become 
exposed to the majority of developers/testers, etc doing normal 
running/playing/testing.


This isn't to knock the idea in anyway, just wanted to mention what i 
think the outcome would be.


dave



>
> On Tue, Mar 17, 2015 at 5:06 PM, Jonathan Ellis 
wrote:
> > Cassandra 2.1 was released in September, which means that if we were on
> > track with our stated goal of six month releases, 3.0 would be done
about
> > now.  Instead, we haven't even delivered a beta.  The immediate cause
> this
> > time is blocking for 8099
> > , but the
reality
> is
> > that nobody should really be surprised.  Something always comes up --
> we've
> > averaged about nine months since 1.0, with 2.1 taking an entire year.
> >
> > We could make theory align with reality by acknowledging, "if nine
months
> > is our 'natural' release schedule, then so be it."  But I think we can
do
> > better.
> >
> > Broadly speaking, we have two constituencies with Cassandra releases:
> >
> > First, we have the users who are building or porting an application on
> > Cassandra.  These users want the newest features to make their job
> easier.
> > If 2.1.0 has a few bugs, it's not the end of the world.  They have time
> to
> > wait for 2.1.x to stabilize while they write their code.  They would
like
> > to see us deliver on our six month schedule or even faster.
> >
> > Second, we have the users who have an application in production.  These
> > users, or their bosses, want Cassandra to be as stable as possible.
> > Assuming they deploy on a stable release like 2.0.12, they don't want
to
> > touch it.  They would like to see us release *less* often.  (Because
that
> > means they have to do less upgrades while remaining in our backwards
> > compatibility window.)
> >
> > With our current "big release every X months" model, these users' needs
> are
> > in tension.
> >
> > We discussed this six months ago, and ended up with this:
> >
> > What if we tried a [four month] release cycle, BUT we would guarantee
> that
> >> you could do a rolling upgrade until we bump the supermajor version?
So
> 2.0
> >> could upgrade to 3.0 without having to go through 2.1.  (But to go to
> 3.1
> >> or 4.0 you would have to go through 3.0.)
> >>
> >
> > Crucially, I added
> >
> > Whether this is reasonable depends on how fast we can stabilize
releases.
> >> 2.1.0 will be a good test of this.
> >>
> >
> > Unfortunately, even after DataStax hired half a dozen full-time test
> > engineers, 2.1.0 continued the proud tradition of being unready for
> > production use, with "wait for .5 before upgrading" once again looking
> like
> > a good guideline.
> >
> > I’m starting to think that the entire model of “write a bunch of new
> > features all at once and then try to stabilize it for release” is
broken.
> > We’ve been trying that for years and empirically speaking the evidence
is
> > that it just doesn’t work, either from a stability standpoint or even
> just
> > shipping on time.
> >
> > A big reason that it takes us so long to stabilize new releases now is
> > that, because our major release cycle is so long, it’s super tempting
to
> > slip in “just one” new feature into bugfix releases, and I’m as guilty
of
> > that as anyone.
> >
> > For similar reasons, it’s difficult to do a meaningful freeze with big
> > feature releases.  A look at 3.0 shows why: we have 8099 coming, but we
> > also have significant work done (but not finished) on 6230, 7970, 6696,
> and
> > 6477, all of which are meaningful improvements that address
demonstrated
> > user pain.  So if we keep doing what we’ve been doing, our choices are
to
> > either delay 3.0 further while we finish and stabilize these, or we
wait
> > nine months to a year for the next release.  Either way, one of our
> > constituencies gets disappointed.
> >
> > So, I’d like to try something different.  I think we were on the right
> > track with shorter releases with more compatibility.  But I’d like to
> throw
> > in a twist.  Intel cuts down on risk with a “tick-tock” schedule for
new
> > architectures and process shrinks instead of trying to do both at once.
> We
> > can do something similar here:
> >
> > One month releases.  Period.  If it’s not done, it can wait.
> > *Every other release only accepts bug fixes.*
> >
> > By itself, one-month releases are going to dramatically reduce the
> > complexity of testing and debugg

Accumulo -- in case you missed it

[Dave Brosius]

I'm not sure how this compares to cassandra, or whether there's any 
synergy that can be had, but in case you missed it...


http://wiki.apache.org/incubator/AccumuloProposal

Updated http://wiki.apache.org/cassandra/ThriftExamples for 1.0.0

[Dave Brosius]

I've updated the thrift examples for Java found at

http://wiki.apache.org/cassandra/ThriftExamples

for version 1.0.0 and above, as the api has changed from what was 
presented there.


Hopefully i haven't foobared anything in the sample.

Re: How is Cassandra being used?

[Dave Brosius]

On 11/15/2011 09:01 PM, Jonathan Ellis wrote:

On Tue, Nov 15, 2011 at 7:02 PM, Eric Evans  wrote:

I think this is potentially quite dangerous; There are a lot people
who get very twitchy at the idea of software that Phones Home.  I've
seen this so many times, and in all cases it was for software a lot
less sensitive than a database.

True, but unlike most Home Phoners, ours will be out there in the open
and you can see exactly what it's sending (or not, if you disable it).
  I'm sure there's other examples in the wild of this, but the only one
I can think of is popcorn [1].

More broadly, my sense is that people are getting used to the idea
that it's okay to give away anonymous statistics as part of the price
of "free," although YMMclearlyV. I am, after all, a Windows user. :)


I'm sure you've already considered this though, you're already talking
about anonymity, and transparency, and what I assume is neutrality of
the collection endpoint (can apache actually provide a VM; is that a
thing?).

Yes, they provide Ubuntu or FreeBSD VMs.


  I'm just afraid that we'll scare people off before they can
be properly convinced that it's all on the up-and-up.

How would you propose addressing this?


I'm curious to see what others think, but at the moment I'm hovering
somewhere around a -0 if it were opt-in (off by default).

I'm okay with opt-in if you think that's useful as a first step to
ease the twitchiness you mention, but longer term I think it's only
really useful if it's on by default. There's a lot of research that
shows that people tend to stick with whatever is the path of least
resistance [2], and specifically, my experience with Cassandra users
is exactly that -- one reason we've spent so much effort getting
defaults so good is because almost nobody goes beyond that.

[1] http://popcon.debian.org/
[2] 
http://www.richmondfed.org/publications/research/region_focus/2007/winter/pdf/feature2.pdf



+1 for opt-in, altho perhaps you should think about how to increase 
opt-in rates. I'm afraid having it buried in the yaml will keep folks 
from enabling it, even if they were ok with doing so (if they knew it 
existed). Perhaps prompting (once) on server start up? -- not sure.

Re: How is Cassandra being used?

[Dave Brosius]

On 11/15/2011 09:01 PM, Jonathan Ellis wrote:

On Tue, Nov 15, 2011 at 7:02 PM, Eric Evans  wrote:

I think this is potentially quite dangerous; There are a lot people
who get very twitchy at the idea of software that Phones Home.  I've
seen this so many times, and in all cases it was for software a lot
less sensitive than a database.

True, but unlike most Home Phoners, ours will be out there in the open
and you can see exactly what it's sending (or not, if you disable it).
  I'm sure there's other examples in the wild of this, but the only one
I can think of is popcorn [1].

More broadly, my sense is that people are getting used to the idea
that it's okay to give away anonymous statistics as part of the price
of "free," although YMMclearlyV. I am, after all, a Windows user. :)


I'm sure you've already considered this though, you're already talking
about anonymity, and transparency, and what I assume is neutrality of
the collection endpoint (can apache actually provide a VM; is that a
thing?).

Yes, they provide Ubuntu or FreeBSD VMs.


  I'm just afraid that we'll scare people off before they can
be properly convinced that it's all on the up-and-up.

How would you propose addressing this?


I'm curious to see what others think, but at the moment I'm hovering
somewhere around a -0 if it were opt-in (off by default).

I'm okay with opt-in if you think that's useful as a first step to
ease the twitchiness you mention, but longer term I think it's only
really useful if it's on by default. There's a lot of research that
shows that people tend to stick with whatever is the path of least
resistance [2], and specifically, my experience with Cassandra users
is exactly that -- one reason we've spent so much effort getting
defaults so good is because almost nobody goes beyond that.

[1] http://popcon.debian.org/
[2] 
http://www.richmondfed.org/publications/research/region_focus/2007/winter/pdf/feature2.pdf



+1 for opt-in, altho perhaps you should think about how to increase 
opt-in rates. I'm afraid having it buried in the yaml will keep folks 
from enabling it, even if they were ok with doing so (if they knew it 
existed). Perhaps prompting (once) on server start up? -- not sure.

Re: How is Cassandra being used?

[Dave Brosius]

+1 for an opt-in approach. To get better opt-in rates perhaps prompt for it on 
start (once) rather than hope folks find it buried in the yaml

Eric Evans  wrote:

>On Tue, Nov 15, 2011 at 11:23 PM, 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?
>
>I think this is potentially quite dangerous; There are a lot people
>who get very twitchy at the idea of software that Phones Home.  I've
>seen this so many times, and in all cases it was for software a lot
>less sensitive than a database.
>
>I'm sure you've already considered this though, you're already talking
>about anonymity, and transparency, and what I assume is neutrality of
>the collection endpoint (can apache actually provide a VM; is that a
>thing?).  I'm just afraid that we'll scare people off before they can
>be properly convinced that it's all on the up-and-up.
>
>I'm curious to see what others think, but at the moment I'm hovering
>somewhere around a -0 if it were opt-in (off by default).
>
>-- 
>Eric Evans
>Acunu | http://www.acunu.com | @acunu

Re: Cassandra has moved to Git

[Dave Brosius]

On 12/28/2011 08:54 PM, Eric Evans wrote:

On Wed, Dec 28, 2011 at 6:25 PM, Stephen Connolly
  wrote:

just the question, where do us contributors who are not committers but have
cla's on file (ie already asf committers) push our changes?

To the best of my knowledge, that distinction doesn't matter.  It's up
to the committer to make sure the changes they're pushing are intended
for the ASF.

As to the where people (with or without CLAs) can/should push their
changes, that's part of what needs to be discussed, I guess.




I don't suppose there's anyway a pull request on the github mirror could 
make it back to the apache repo?

Re: Cassandra has moved to Git

[Dave Brosius]

On 12/28/2011 02:55 PM, Eric Evans wrote:

While this is something we had talked about for ages, the actual
switch-over happened rather abruptly, and Cassandra's canonical
repository is now hosted in Git.

For instructions on getting started, see
https://git-wip-us.apache.org.  We've also started putting random
administrivia in the wiki at
http://wiki.apache.org/cassandra/GitTransition.

The Github mirror (http://github.com/apache/cassandra) hasn't been
seeing updates since the move, but that will be fixed at some point.
The important thing is that they share identical histories, so new (or
existing forks) are forward-compatible.

There are a few outstanding items being worked on (CI systems for
example), but if you notice something that's been missed don't
hesitate to speak up.  The website will be updated as soon as SVN is
unlocked.

There are also some matters of work-flow or process that we need to
hashed out.  For example, how do we handle reviews now?  Do we
continue to mandate/recommend/allow rebasing?

Thoughts?


doing

git clone http://git-wip-us.apache.org/repos/asf/cassandra.git cassandra

proceeded as a normal clone until the end when i received

warning: remote HEAD refers to nonexistent ref, unable to checkout.

any ideas what i'm doing wrong?

can we ban this guy from the wiki?

[Dave Brosius]

http://wiki.apache.org/cassandra/Roger%20Mbiama?action=info

Building dependencies for cassandra (hadoop-core)

[Dave Brosius]

Greetings,

   I see that Cassandra has a lib directory full of 3rdparty jars, but 
also uses mvn dependency management.  The only difference it appears to 
me is that the lib directory is missing hadoop-core. So the question is, 
is this lib dir just a legacy that should be removed, or should 
hadoop-core be added to this lib dir, or am I completely confused?


thanks,
dave

FYI Cassandra Git Repo on Apache servers

[Dave Brosius]

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

error: RPC failed; result=22, HTTP code = 417

Obviously most folks do not have this issue.

417 is a server's response to a request that includes an expectation 
header specifying level of service that the server can not fulfill.


After some discover it looks as if the user in question was effected by 
squid  and that was 
injecting the expect header, based on the output from curl -v 
http://git-wip-us.apache.org/repos/asf/cassandra.git


Clones from github for him do not fail, which I infer to mean that the 
github servers are more modern than the apache ones.


Not sure if there is anything that can be done in the apache 
infrastructure to address this.


dave

Re: What's the point of the deviation of java code style in Cassandra?

[Dave Brosius]

 Might want to reviewhttps://issues.apache.org/jira/browse/CASSANDRA-3649when 
in rome... is http://en.wikipedia.org/wiki/When_in_Rome  - Original Message 
-From: "bxqdev" >;bxq...@themailbay.com

extra diffs showing up in update column family

[Dave Brosius]

If a user specifies a Comparator in an update column family (as was from 
a irc user), as


update column family report_by_account_content with comparator=UTF8Type 
and column_metadata = [{ column_name:'meta:account-id', 
validation_class:UTF8Type,index_type:KEYS},{ 
column_name:'meta:filter-hash', validation_class:UTF8Type,index_type:KEYS}];



The comparator value is seen as different because the original 
comparator was the fully qualified name of the 
org.apache.cassandra.db.marshal.UTF8Type, and new one is what is passed 
in UTF8Type. So CFMetaData.diff sees this as a change and does extra 
work because of it.


I'm guessing there are other class name values where this holds true as 
well.


Is this a big enough concern to address?

thanks
dave

Re: [Compile Error] java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory

[Dave Brosius]

You need to add slf4j-api-1.6.1.jar and slf4j-log4j12-1.6.1.jar to your 
class path



You can also look at this page, 
http://wiki.apache.org/cassandra/HowToDebug for another example of 
setting up cassandra for debugging.




On 03/12/2012 09:47 PM, Thushan Ganegedara wrote:

Hi all,
I have followed the instruction presented on
Running cassandra on Eclipse -
http://wiki.apache.org/cassandra/RunningCassandraInEclipse
But when I tried to compile the codebase it presented me with the following
error

java.lang.
NoClassDefFoundError: org/slf4j/LoggerFactory
 at
org.apache.cassandra.service.AbstractCassandraDaemon.(AbstractCassandraDaemon.java:103)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 ... 1 more
Exception in thread "main"

Can anybody help me here?
Thnx a lot

Re: 6 months a more realistic release cycle?

[Dave Brosius]

+1

is there any stats on customer adoption of new versions? I'd wonder if 
people generally move to new versions every 4 months, as that could be 
potentially painful for them as well. Given the amount of questions 
regarding older versions still percolating, i'd guess the answer is 
they'd be ok with it too.




On 04/20/2012 01:57 PM, Jonathan Ellis wrote:

After the 0.7 release we decided to shoot for a fixed four-month
release cycle.  I think now is a good time to re-evaluate this, and
possibly change to target a six month cycle:

- Speaking for DataStax, about half our time is spent on maintenance.
Given this, a 3 month window just isn't much time to work on some of
the larger features we have planned.

- Most of the schedule slip has been in our post-freeze QA period.  A
six month cycle would allow a more realistic 6 or even 8 weeks of QA,
while still expanding the dev window.

- Cassandra has matured enough that there is less low-hanging fruit to
pick; two potential upgrades per year feels better matched to that,
than three.

- The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6
months, respectively.  So in a sense, officially making it a 6-month
cycle would only be acknowledging reality anyway.

Thoughts?