[jira] [Commented] (CASSANDRA-4140) Build stress classes in a location that allows tools/stress/bin/stress to find them
[ https://issues.apache.org/jira/browse/CASSANDRA-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255119#comment-13255119 ] Nick Bailey commented on CASSANDRA-4140: My only wish with the new version is that we add the executable flag to the permissions of tools/bin/stress[d]. Besides that looks good for linux, haven't tried out the .bat files. Build stress classes in a location that allows tools/stress/bin/stress to find them --- Key: CASSANDRA-4140 URL: https://issues.apache.org/jira/browse/CASSANDRA-4140 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Nick Bailey Assignee: Vijay Priority: Trivial Fix For: 1.2 Attachments: 0001-CASSANDRA-4140-v2.patch, 0001-CASSANDRA-4140.patch Right now its hard to run stress from a checkout of trunk. You need to do 'ant artifacts' and then run the stress tool in the generated artifacts. A discussion on irc came up with the proposal to just move stress to the main jar, but the stress/stressd bash scripts in bin/, and drop the tools directory altogether. It will be easier for users to find that way and will make running stress from a checkout much easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4140) Build stress classes in a location that allows tools/stress/bin/stress to find them
[ https://issues.apache.org/jira/browse/CASSANDRA-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255131#comment-13255131 ] Nick Bailey commented on CASSANDRA-4140: My mistake, looks like 'patch -p1 patch_File' won't keep permissions. 'git apply patch_file' works fine though. Build stress classes in a location that allows tools/stress/bin/stress to find them --- Key: CASSANDRA-4140 URL: https://issues.apache.org/jira/browse/CASSANDRA-4140 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Nick Bailey Assignee: Vijay Priority: Trivial Fix For: 1.2 Attachments: 0001-CASSANDRA-4140-v2.patch, 0001-CASSANDRA-4140.patch Right now its hard to run stress from a checkout of trunk. You need to do 'ant artifacts' and then run the stress tool in the generated artifacts. A discussion on irc came up with the proposal to just move stress to the main jar, but the stress/stressd bash scripts in bin/, and drop the tools directory altogether. It will be easier for users to find that way and will make running stress from a checkout much easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4140) Build stress classes in a location that allows tools/stress/bin/stress to find them
[ https://issues.apache.org/jira/browse/CASSANDRA-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252549#comment-13252549 ] Nick Bailey commented on CASSANDRA-4140: +1 on these changes from me. Jonathan, maybe you could port the same changes to stress.bat since you run on windows? Build stress classes in a location that allows tools/stress/bin/stress to find them --- Key: CASSANDRA-4140 URL: https://issues.apache.org/jira/browse/CASSANDRA-4140 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Nick Bailey Assignee: Vijay Priority: Trivial Fix For: 1.2 Attachments: 0001-CASSANDRA-4140.patch Right now its hard to run stress from a checkout of trunk. You need to do 'ant artifacts' and then run the stress tool in the generated artifacts. A discussion on irc came up with the proposal to just move stress to the main jar, but the stress/stressd bash scripts in bin/, and drop the tools directory altogether. It will be easier for users to find that way and will make running stress from a checkout much easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4140) Move stress to main jar
[ https://issues.apache.org/jira/browse/CASSANDRA-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252029#comment-13252029 ] Nick Bailey commented on CASSANDRA-4140: bq. Wow, that's a definition of hard I'm unfamiliar with. Hmm maybe I should have gone with confusing :). Plus I'm lazy. I don't want to wait for artifacts to build the javadoc AND then make build/dist/tools/stress/bin/stress executable so I can run it. C'mon, two whole extra steps!!?? Really though fixing that ^ was the spirit of this ticket. Moving stress was just a suggestion from irc. I would be fine if 'ant stress-build' put the built files in a place where tools/stress/bin/stress can find them. Having said that I do think moving things like you mentioned into tools makes them less 'discoverable'. And moving stress would make it more 'discoverable'. Move stress to main jar --- Key: CASSANDRA-4140 URL: https://issues.apache.org/jira/browse/CASSANDRA-4140 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Nick Bailey Priority: Trivial Fix For: 1.2 Right now its hard to run stress from a checkout of trunk. You need to do 'ant artifacts' and then run the stress tool in the generated artifacts. A discussion on irc came up with the proposal to just move stress to the main jar, but the stress/stressd bash scripts in bin/, and drop the tools directory altogether. It will be easier for users to find that way and will make running stress from a checkout much easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4092) Allow getting a simple Token-node map over thrift
[
https://issues.apache.org/jira/browse/CASSANDRA-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250191#comment-13250191
]
Nick Bailey commented on CASSANDRA-4092:
actually Sam, can you rebase on the 1.1 branch? This applies to trunk but since
we are targeting for the 1.1 releases rather than 1.2 we need to rebase for
that.
Allow getting a simple Token-node map over thrift
--
Key: CASSANDRA-4092
URL: https://issues.apache.org/jira/browse/CASSANDRA-4092
Project: Cassandra
Issue Type: Improvement
Reporter: Nick Bailey
Assignee: Sam Tunnicliffe
Fix For: 1.1.1
Attachments:
v1-0001-CASSANDRA-4092-New-thrift-call-to-get-simple-token-nod.txt,
v1-0002-CASSANDRA-4092-New-generated-java-following-change-to-.txt,
v2-0001-CASSANDRA-4092-New-thrift-call-to-get-simple-token-nod.txt,
v2-0002-CASSANDRA-4092-New-generated-java-following-change-to-.txt
Right now the thrift describe_ring call is intended to be used to determine
ownership for a keyspace. It can also (and often is) be used by clients to
just get a view of what the ring looks like. Since it requires a keyspace as
an argument though, it can sometimes be impossible to see what the ring looks
like. For example, in a 2 DC/2 node ring where keyspace X exists only dc1.
The results of 'describe_ring X' would look something like (with tokens 0 and
10):
{noformat}
{[0,10]: [node0], [10,0]: [node0]}
{noformat}
This is indicating that node0 owns everything for that keyspace since it only
exists in 1 datacenter. From this output though it is impossible to tell
which token (0 or 10) node0 owns, as well as what the other node in the
cluster is.
There are two options here.
* Allow running describe_ring with no parameters to get a view of token-ip
without taking replication into consideration.
* Add a new thrift call to achieve this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4092) Allow getting a simple Token-node map over thrift
[
https://issues.apache.org/jira/browse/CASSANDRA-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247711#comment-13247711
]
Nick Bailey commented on CASSANDRA-4092:
* You used tabs instead of spaces in a few places.
* Bikeshedding suggestion: what about 'describe_token_map'?
Besides that it looks good. I can't seem to get the system tests to run, but
it's something acting up on my system.
Allow getting a simple Token-node map over thrift
--
Key: CASSANDRA-4092
URL: https://issues.apache.org/jira/browse/CASSANDRA-4092
Project: Cassandra
Issue Type: Improvement
Reporter: Nick Bailey
Assignee: Sam Tunnicliffe
Fix For: 1.1.1
Attachments:
v1-0001-CASSANDRA-4092-New-thrift-call-to-get-simple-token-nod.txt,
v1-0002-CASSANDRA-4092-New-generated-java-following-change-to-.txt
Right now the thrift describe_ring call is intended to be used to determine
ownership for a keyspace. It can also (and often is) be used by clients to
just get a view of what the ring looks like. Since it requires a keyspace as
an argument though, it can sometimes be impossible to see what the ring looks
like. For example, in a 2 DC/2 node ring where keyspace X exists only dc1.
The results of 'describe_ring X' would look something like (with tokens 0 and
10):
{noformat}
{[0,10]: [node0], [10,0]: [node0]}
{noformat}
This is indicating that node0 owns everything for that keyspace since it only
exists in 1 datacenter. From this output though it is impossible to tell
which token (0 or 10) node0 owns, as well as what the other node in the
cluster is.
There are two options here.
* Allow running describe_ring with no parameters to get a view of token-ip
without taking replication into consideration.
* Add a new thrift call to achieve this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4085) create keyspace via cassandra cli fails
[ https://issues.apache.org/jira/browse/CASSANDRA-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238904#comment-13238904 ] Nick Bailey commented on CASSANDRA-4085: Also, you should be able to workaround by modifying the cassandra-cli.bat file to include cassandra.yaml on the classpath when starting the cli. create keyspace via cassandra cli fails --- Key: CASSANDRA-4085 URL: https://issues.apache.org/jira/browse/CASSANDRA-4085 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.8 Environment: Windows 7 x64, Java 7 x64 Reporter: Frank Hsueh create keyspace should work. it doesn't. e.g.: cassandra-cli.bat -h localhost -p 9160 Starting Cassandra Client Connected to: Test Cluster on localhost/9160 Welcome to Cassandra CLI version 1.0.8 Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit. [default@unknown] create keyspace DEMO; log4j:WARN No appenders could be found for logger (org.apache.cassandra.config.DatabaseDescriptor). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Cannot locate cassandra.yaml Fatal configuration error; unable to start server. See log for stacktrace. disclaimer: first time bug writer for cassandra so I might not have gotten the various fields right. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4067) Report lifetime compaction throughput
[ https://issues.apache.org/jira/browse/CASSANDRA-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236983#comment-13236983 ] Nick Bailey commented on CASSANDRA-4067: +1 Report lifetime compaction throughput - Key: CASSANDRA-4067 URL: https://issues.apache.org/jira/browse/CASSANDRA-4067 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Trivial Labels: compaction Fix For: 1.1.0 Attachments: 0001-Track-and-expose-lifetime-bytes-compacted.txt, 0002-Track-and-expose-total-compactions.txt Would be useful to be able to monitor total compaction throughput without having to poll frequently enough to make sure we get every CompactionInfo object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4067) Report lifetime compaction throughput
[ https://issues.apache.org/jira/browse/CASSANDRA-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235671#comment-13235671 ] Nick Bailey commented on CASSANDRA-4067: I mentioned this offline, but is there any reason we shouldn't go ahead and expose total number of compactions completed as well? Report lifetime compaction throughput - Key: CASSANDRA-4067 URL: https://issues.apache.org/jira/browse/CASSANDRA-4067 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Trivial Labels: compaction Fix For: 1.1.0 Attachments: 4067.txt Would be useful to be able to monitor total compaction throughput without having to poll frequently enough to make sure we get every CompactionInfo object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4063) Expose nodetool cfhistograms for secondary index CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233132#comment-13233132
]
Nick Bailey commented on CASSANDRA-4063:
+1
Expose nodetool cfhistograms for secondary index CFs
Key: CASSANDRA-4063
URL: https://issues.apache.org/jira/browse/CASSANDRA-4063
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Tyler Hobbs
Assignee: Brandon Williams
Priority: Minor
Labels: jmx
Attachments: 4063.txt
With the ObjectName that NodeProbe uses, the JMX query can only match mbeans
with type ColumnFamilies. Secondary index CFs have a type of
IndexColumnFamilies, so the query won't match them.
The [ObjectName
documentation|http://docs.oracle.com/javase/6/docs/api/javax/management/ObjectName.html]
indicates that you can use wildcards, which would be the perfect solution if
it actually worked. I'm not sure if it's some quoted vs non-quoted pattern
issue, or if it's particular to the {{newMBeanProxy()}} method, but I could
not get wildcards to match the secondary index CFs. Explicitly setting the
type field to IndexColumnFamilies did work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3810) reconsider rack awareness
[
https://issues.apache.org/jira/browse/CASSANDRA-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196238#comment-13196238
]
Nick Bailey commented on CASSANDRA-3810:
I would be in favor of removing the current concept of rack awareness and
better documenting the way to achieve distribution among racks. I don't know of
any situations where the current implementation is useful.
As far as preventing hotspots, I think ultimately the best solution would be
solving the problem in a way that user's don't have to care about ordering
racks in the ring. That solution would probably involve some pretty big changes
though and I'm not sure how feasible it would be to actually implement.
I'm not sure about the approach of refusing to bootstrap or select tokens that
introduce a rack imbalance. I'd rather see nodetool get fixed so that
imbalances can easily be seen and changing the documentation around racks so
that the solution is apparent.
reconsider rack awareness
-
Key: CASSANDRA-3810
URL: https://issues.apache.org/jira/browse/CASSANDRA-3810
Project: Cassandra
Issue Type: Task
Reporter: Peter Schuller
Assignee: Peter Schuller
Priority: Minor
We believed we wanted to be rack aware because we want to ensure that loosing
a rack only affects a single replica of any given row key.
When using rack awareness, the first problem you encounter immediately if you
aren't careful is that you induce hotspots as a result of rack aware replica
selection. Using the format {{rackname-nodename}}, consider a part of the
ring that looks like this:
{code}
...
r1-n1
r1-n2
r1-n3
r2-n1
r3-n1
r4-n1
...
{code}
Due to the rack awareness, {{r2-n1}} will be the second replica for all data
whose primary replica is on {{r1-n1}}, {{r1-n2}} and {{r1-n3}} since they
would all be forced to skip over any identical racks.
The way we end up allocating nodes in a cluster is to satisfy this criteria:
* Any node in rack {{r}} in a cluster of a replication factor of {{rf}}, must
not have another node in {{r}} within {{rf-1}} steps in the ring in either
direction.
Any violation of this criteria implies the induction of hotspots due to rack
awareness.
The realization however, that I had a few days ago, is that *the
rackawareness is not actually changing replica placement* when using this
ring topology. In other words, *the way you have to use* rack awareness is to
construct the ring such that *the rack awareness is a NOOP*.
So, questions:
* Is there any non-hotspot inducing use-case where rack awareness can be used
(used in the sense that it actually changes the placement relative to
non-awareness) effectively without satisfying the criteria above?
* Is it misleading and counter-productive to teach people (via documentation
for example) to rely on rack awareness in their rings instead of just giving
them the rule above for ring topology?
* Would it be a better service to the user to provide an easy way to *ensure*
that the ring topology adheres to this criteria (such as refusing to
bootstrap a new node if rack awareness is requested, and taking it into
consideration on automatic token selection (does anyone use that?)), than to
silently generate hotspots by altering the replication strategy? (The
silence problem is magnified by the fact that {{nodetool ring}} doesn't
reflect this; so the user must take into account both the RF *and* the racks
when interpreting {{nodetool ring}} output.)
FWIW, internally we just go with the criteria outlined above, and we have a
separate tool which will print the *actual* ownership percentage of a node in
the ring (based on the thrift {{describe_ring}} call). Any ring that has node
selections that causes a violation of the criteria is effectively a
bug/mis-configured ring, so only in the event of mistakes are we using the
rack awareness (using the definition of use above).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3744) Nodetool.bat double quotes classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193552#comment-13193552 ] Nick Bailey commented on CASSANDRA-3744: lgtm. Tested all tools with a space in the classpath. Nodetool.bat double quotes classpath Key: CASSANDRA-3744 URL: https://issues.apache.org/jira/browse/CASSANDRA-3744 Project: Cassandra Issue Type: Bug Components: Tools Environment: Windows Reporter: Nick Bailey Assignee: Nick Bailey Priority: Minor Fix For: 1.0.8 Attachments: 0001-Don-t-double-quote-classpath.patch, 3744-v2.txt Windows sucks and double quoting things breaks stuff. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3744) Nodetool.bat double quotes classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187324#comment-13187324
]
Nick Bailey commented on CASSANDRA-3744:
Right we want to quote the classpath but it is currently getting double quoted
which breaks things on windows. When we loop over the jars in the lib dir and
call the ':append' block we pass each jar quoted. Then later we quote the
entire classpath again when we call java. So we end up with:
{noformat}
jar1;jar2;jar3
{noformat}
That will actually break if any of those jars have spaces in the path.
Nodetool.bat double quotes classpath
Key: CASSANDRA-3744
URL: https://issues.apache.org/jira/browse/CASSANDRA-3744
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Windows
Reporter: Nick Bailey
Assignee: Nick Bailey
Priority: Minor
Fix For: 1.0.8
Attachments: 0001-Don-t-double-quote-classpath.patch
Windows sucks and double quoting things breaks stuff.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3658) Fix smallish problems find by FindBugs
[ https://issues.apache.org/jira/browse/CASSANDRA-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176320#comment-13176320 ] Nick Bailey commented on CASSANDRA-3658: This breaks a bunch of jmx stuff. A fair amount of jmx methods return Token objects so they need to be serializable. I plan on doing CASSANDRA-2805 for 1.1, but jmx will be broken in trunk until I get that done unless that specific patch is reverted. Fix smallish problems find by FindBugs -- Key: CASSANDRA-3658 URL: https://issues.apache.org/jira/browse/CASSANDRA-3658 Project: Cassandra Issue Type: Bug Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: fingbugs Fix For: 1.1 Attachments: 0001-Respect-Future-semantic.patch, 0002-Avoid-race-when-reloading-snitch-file.patch, 0003-use-static-inner-class-when-possible.patch, 0004-Remove-dead-code.patch, 0005-Protect-against-signed-byte-extension.patch, 0006-Add-hashCode-method-when-equals-is-overriden.patch, 0007-Inverse-argument-of-compare-instead-of-negating-to-a.patch, 0008-stop-pretending-Token-is-Serializable-LocalToken-is-.patch, 0009-remove-useless-assert-that-is-always-true.patch, 0010-Add-equals-and-hashCode-to-Expiring-column.patch I've just run (the newly released) FindBugs 2 out of curiosity. Attaching a number of patches related to issue raised by it. There is nothing major at all so all patches are against trunk. I've tried keep each issue to it's own patch with a self describing title. It far from covers all FindBugs alerts, but it's a picky tool so I've tried to address only what felt at least vaguely useful. Those are still mostly nits (only patch 2 is probably an actual bug). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175058#comment-13175058 ] Nick Bailey commented on CASSANDRA-3507: Personally I think the user experience is significantly decreased if users have to download/build/install a separate project in order to actually interact with cassandra once it's running. The first thing a user is going to do after starting cassandra is try and figure out how to insert/retrieve data. Requiring that they download a different project in order to do that seems unnecessarily confusing. Proposal: separate cqlsh from CQL drivers - Key: CASSANDRA-3507 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507 Project: Cassandra Issue Type: Improvement Components: Packaging, Tools Affects Versions: 1.0.3 Environment: Debian-based systems Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cql, cqlsh Fix For: 1.0.7 Whereas: * It has been shown to be very desirable to decouple the release cycles of Cassandra from the various client CQL drivers, and * It is also desirable to include a good interactive CQL client with releases of Cassandra, and * It is not desirable for Cassandra releases to depend on 3rd-party software which is neither bundled with Cassandra nor readily available for every target platform, but * Any good interactive CQL client will require a CQL driver; Therefore, be it resolved that: * cqlsh will not use an official or supported CQL driver, but will include its own private CQL driver, not intended for use by anything else, and * the Cassandra project will still recommend installing and using a proper CQL driver for client software. To ease maintenance, the private CQL driver included with cqlsh may very well be created by copying the python CQL driver from one directory into another, but the user shouldn't rely on this. Maybe we even ought to take some minor steps to discourage its use for other purposes. Thoughts? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175079#comment-13175079 ] Nick Bailey commented on CASSANDRA-3507: Thats only valid for users that install using a package. If you go to www.cassandra.apache.org you see a big download button for the binary tarball. Even the debian repositories we host are only mentioned if you wade into the wiki. The majority of users who just want to try cassandra are just going to go to the website and click the download button. Proposal: separate cqlsh from CQL drivers - Key: CASSANDRA-3507 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507 Project: Cassandra Issue Type: Improvement Components: Packaging, Tools Affects Versions: 1.0.3 Environment: Debian-based systems Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cql, cqlsh Fix For: 1.1 Whereas: * It has been shown to be very desirable to decouple the release cycles of Cassandra from the various client CQL drivers, and * It is also desirable to include a good interactive CQL client with releases of Cassandra, and * It is not desirable for Cassandra releases to depend on 3rd-party software which is neither bundled with Cassandra nor readily available for every target platform, but * Any good interactive CQL client will require a CQL driver; Therefore, be it resolved that: * cqlsh will not use an official or supported CQL driver, but will include its own private CQL driver, not intended for use by anything else, and * the Cassandra project will still recommend installing and using a proper CQL driver for client software. To ease maintenance, the private CQL driver included with cqlsh may very well be created by copying the python CQL driver from one directory into another, but the user shouldn't rely on this. Maybe we even ought to take some minor steps to discourage its use for other purposes. Thoughts? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175102#comment-13175102 ] Nick Bailey commented on CASSANDRA-3507: Fixing the download page will make this less of an issue, but short of removing a link to the binary/source tarball downloads of cassandra, some people are still going to download those. It seems to me that having a basic way of interacting with the database is an essential piece of the software. This solution seems like we are saying that including that piece is too difficult so we'll push the complexity to users. Anyway that's my two cents. I'll leave it at that if I'm outvoted here. Proposal: separate cqlsh from CQL drivers - Key: CASSANDRA-3507 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507 Project: Cassandra Issue Type: Improvement Components: Packaging, Tools Affects Versions: 1.0.3 Environment: Debian-based systems Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cql, cqlsh Fix For: 1.1 Whereas: * It has been shown to be very desirable to decouple the release cycles of Cassandra from the various client CQL drivers, and * It is also desirable to include a good interactive CQL client with releases of Cassandra, and * It is not desirable for Cassandra releases to depend on 3rd-party software which is neither bundled with Cassandra nor readily available for every target platform, but * Any good interactive CQL client will require a CQL driver; Therefore, be it resolved that: * cqlsh will not use an official or supported CQL driver, but will include its own private CQL driver, not intended for use by anything else, and * the Cassandra project will still recommend installing and using a proper CQL driver for client software. To ease maintenance, the private CQL driver included with cqlsh may very well be created by copying the python CQL driver from one directory into another, but the user shouldn't rely on this. Maybe we even ought to take some minor steps to discourage its use for other purposes. Thoughts? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3501) Move allows you to move to tokens 2**127
[ https://issues.apache.org/jira/browse/CASSANDRA-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13153196#comment-13153196 ] Nick Bailey commented on CASSANDRA-3501: +1 Move allows you to move to tokens 2**127 -- Key: CASSANDRA-3501 URL: https://issues.apache.org/jira/browse/CASSANDRA-3501 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Nick Bailey Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0.4 Attachments: 3501-v2.txt, 3501.txt Currently you can move to tokens greater than what should be the max token in RP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3433) Describe ring is broken
[ https://issues.apache.org/jira/browse/CASSANDRA-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140472#comment-13140472 ] Nick Bailey commented on CASSANDRA-3433: Didn't change the thrift version number in that patch. Assuming it is committed, that should also be bumped. Describe ring is broken --- Key: CASSANDRA-3433 URL: https://issues.apache.org/jira/browse/CASSANDRA-3433 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.1 Reporter: Nick Bailey Fix For: 1.0.2 Attachments: 0001-Don-t-use-rpc-address-for-endpoints-field-of-describ.patch CASSANDRA-2882 broke describe_ring by causing the 'endpoints' field to contain the rpc address rather than the listen address. the rpc_address belongs in the 'rpc_endpoints' field. Hence the name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3283) node is sending streams to itself during move operation
[ https://issues.apache.org/jira/browse/CASSANDRA-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132776#comment-13132776 ] Nick Bailey commented on CASSANDRA-3283: Jackson, I think there is a bigger problem here. The fact that the node that is bootstrapping is in the list of possible endpoints at all is a problem. Not sure if this has always been broken or was broken recently but I'll dig a little deeper here. node is sending streams to itself during move operation --- Key: CASSANDRA-3283 URL: https://issues.apache.org/jira/browse/CASSANDRA-3283 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.6 Environment: linux debian stable (squeeze), cassandra 0.8.6, java 6 Update 26 Reporter: Zenek Kraweznik Assignee: Jackson Chung Priority: Minor Fix For: 1.0.1 I'm moving node 10.10.10.231 from 113427455640312821154458202477256070485 to 0. ring: Address DC RackStatus State LoadOwns Token 127605887595351923798765477786913079296 10.10.10.232 datacenter1 rack1 Up Normal 148.7 GB50.00% 42535295865117307932921825928971026432 10.10.10.233 datacenter1 rack1 Up Normal 156.77 GB 25.00% 85070591730234615865843651857942052864 10.10.10.231 datacenter1 rack1 Up Moving 188.75 GB 16.67% 113427455640312821154458202477256070485 10.10.10.234 datacenter1 rack1 Up Normal 94.89 GB8.33% 127605887595351923798765477786913079296 netstats from node1: Streaming to: /10.10.10.234 /var/lib/cassandra/data/testdb2/ChangeLog-g-30-Data.db sections=2 progress=0/6859992288 - 0% /var/lib/cassandra/data/testdb2/ChangeLogIndex-g-10-Data.db sections=1 progress=0/15286 - 0% /var/lib/cassandra/data/testdb/ChangeLogIndex-g-48-Data.db sections=1 progress=0/90 - 0% /var/lib/cassandra/data/testdb/Testcoll-g-107-Data.db sections=2 progress=0/5276 - 0% /var/lib/cassandra/data/testdb/Testcoll2-g-74-Data.db sections=2 progress=0/470 - 0% /var/lib/cassandra/data/testdb/ChangeLogIndex-g-47-Data.db sections=1 progress=0/1156 - 0% /var/lib/cassandra/data/testdb/Testcoll-g-106-Data.db sections=2 progress=0/329027714 - 0% /var/lib/cassandra/data/testdb/ChangeLog-g-61-Data.db sections=2 progress=0/30212596 - 0% /var/lib/cassandra/data/testdb3/Testcoll2-g-42-Data.db sections=2 progress=0/774117 - 0% /var/lib/cassandra/data/testdb3/ChangeLogIndex-g-10-Data.db sections=1 progress=0/90 - 0% Streaming to: /10.10.10.231 /var/lib/cassandra/data/testdb2/Testcoll-g-30-Data.db sections=2 progress=39059456000/87950308260 - 44% /var/lib/cassandra/data/testdb2/ChangeLog-g-30-Data.db sections=2 progress=0/7806077255 - 0% /var/lib/cassandra/data/testdb2/ChangeLogIndex-g-10-Data.db sections=1 progress=0/15286 - 0% /var/lib/cassandra/data/testdb3/Testcoll2-g-42-Data.db sections=2 progress=0/784033 - 0% /var/lib/cassandra/data/testdb3/ChangeLogIndex-g-10-Data.db sections=1 progress=0/90 - 0% /var/lib/cassandra/data/testdb/ChangeLogIndex-g-48-Data.db sections=1 progress=0/90 - 0% /var/lib/cassandra/data/testdb/Testcoll-g-107-Data.db sections=2 progress=0/10499 - 0% /var/lib/cassandra/data/testdb/Testcoll2-g-74-Data.db sections=2 progress=0/1042 - 0% /var/lib/cassandra/data/testdb/ChangeLogIndex-g-47-Data.db sections=1 progress=0/1156 - 0% /var/lib/cassandra/data/testdb/Testcoll-g-106-Data.db sections=2 progress=0/329965993 - 0% /var/lib/cassandra/data/testdb/ChangeLog-g-61-Data.db sections=2 progress=0/24633913 - 0% Streaming from: /10.10.10.231 testdb: /var/lib/cassandra/data/testdb/ChangeLogIndex-g-47-Data.db sections=1 progress=0/1156 - 0% testdb: /var/lib/cassandra/data/testdb/ChangeLogIndex-g-48-Data.db sections=1 progress=0/90 - 0% testdb: /var/lib/cassandra/data/testdb/ChangeLog-g-61-Data.db sections=2 progress=0/24633913 - 0% testdb3: /var/lib/cassandra/data/testdb3/Testcoll2-g-42-Data.db sections=2 progress=0/784033 - 0% testdb: /var/lib/cassandra/data/testdb/Testcoll2-g-74-Data.db sections=2 progress=0/1042 - 0% testdb3: /var/lib/cassandra/data/testdb3/ChangeLogIndex-g-10-Data.db sections=1 progress=0/90 - 0% testdb2: /var/lib/cassandra/data/testdb2/ChangeLog-g-30-Data.db sections=2 progress=0/7806077255 - 0% testdb2: /var/lib/cassandra/data/testdb2/ChangeLogIndex-g-10-Data.db sections=1 progress=0/15286 - 0% testdb: /var/lib/cassandra/data/testdb/Testcoll-g-106-Data.db sections=2 progress=0/329965993 - 0% testdb2:
[jira] [Commented] (CASSANDRA-2805) Clean up mbeans that return Internal Cassandra types
[ https://issues.apache.org/jira/browse/CASSANDRA-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125332#comment-13125332 ] Nick Bailey commented on CASSANDRA-2805: Obviously I didn't get this done before the 1.0 freeze. And of course, this breaks between 0.8 and 1.0 since the serial version of CompactionInfo changes. Can we target this for 1.0.1? Clean up mbeans that return Internal Cassandra types Key: CASSANDRA-2805 URL: https://issues.apache.org/jira/browse/CASSANDRA-2805 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Nick Bailey Assignee: Gaurav Sharma Priority: Minor Labels: lhf Fix For: 1.1 We need to clean up wherever we return internal cassandra objects over jmx. Namely CompactionInfo objects as well as Tokens. There may be a few other examples. This is bad for two reasons 1. You have to load the cassandra jar when querying these mbeans, which sucks. 2. Stuff breaks between versions when things are moved. For example, CASSANDRA-1610 moves the compaction related classes around. Any code querying those jmx mbeans in 0.8.0 is now broken in 0.8.2. (assuming those moves stay in the 0.8 branch) For things like CompactionInfo we should just expose more mbean methods or serialize to something standard like json. I'd like to target this for 0.8.2. Since we've already broken compatibility between 0.8.0 and 0.8.1, I'd say just fix this everywhere now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2805) Clean up mbeans that return Internal Cassandra types
[ https://issues.apache.org/jira/browse/CASSANDRA-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125534#comment-13125534 ] Nick Bailey commented on CASSANDRA-2805: I agree my main argument though is that we have a history of doing it unknowingly. Especially something like this where any update the the CompactionInfo requires updating the serialization version and then breaks compatibility. I suppose I can live with this in 1.1 and a 'let's try really really really hard not to break compatibility in the 1.0.x releases. Clean up mbeans that return Internal Cassandra types Key: CASSANDRA-2805 URL: https://issues.apache.org/jira/browse/CASSANDRA-2805 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Nick Bailey Assignee: Gaurav Sharma Priority: Minor Labels: lhf Fix For: 1.1 We need to clean up wherever we return internal cassandra objects over jmx. Namely CompactionInfo objects as well as Tokens. There may be a few other examples. This is bad for two reasons 1. You have to load the cassandra jar when querying these mbeans, which sucks. 2. Stuff breaks between versions when things are moved. For example, CASSANDRA-1610 moves the compaction related classes around. Any code querying those jmx mbeans in 0.8.0 is now broken in 0.8.2. (assuming those moves stay in the 0.8 branch) For things like CompactionInfo we should just expose more mbean methods or serialize to something standard like json. I'd like to target this for 0.8.2. Since we've already broken compatibility between 0.8.0 and 0.8.1, I'd say just fix this everywhere now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
