[jira] Resolved: (CASSANDRA-1831) NetworkTopologyStrategy allows mismatched RF resulting in obscure failures
[ https://issues.apache.org/jira/browse/CASSANDRA-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1831. --- Resolution: Duplicate The right fix is to not allow conflicting definitions in the first place. CASSANDRA-1263 is open for this. NetworkTopologyStrategy allows mismatched RF resulting in obscure failures -- Key: CASSANDRA-1831 URL: https://issues.apache.org/jira/browse/CASSANDRA-1831 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 rc 1 Reporter: Peter Schuller On today's 0.7 branch: Creating a keyspace like this (not how to do it in production, but that's not the point): create keyspace MyKeySpace with replication_factor = 2 and placement_strategy = 'org.apache.cassandra.locator.NetworkTopologyStrategy'; This is accepted by Cassandra in spite of there being no strategy options. Describing the keyspace will then give output similar to: Keyspace: MyKeySpace: Replication Strategy: org.apache.cassandra.locator.SimpleStrategy null Attempts to write and read respectively gives the errors included at the bottom of this comment. What happens is that the NTS's getReplicationFactor() returns the sum of RF for each DC. But lacking any replicate placement options for DC:s, the sum will always be 0. The result is that NTS.calculateNaturalEndpoints() yields 0 endpoints thus triggering the assertion failures apparent in the strack traces. This was caused by misconfiguration during testing but should be handled better. What are people's thoughts on the set of changes that would constitute a proper fix? Is there a reason for NTS to ever conclude that RF is different than that of the CF def? If not, I would say that one fix is to make the NTS bail early if the calculated RF adding up the DC placements does not match the configured RF for the column family. (I'll submit a patch if people agree.) Beyond that, what else, if anything should be done? Should the creation fail due to the RF being inconsistent with strategy options? Is it correct that code assumes that naturalEndPoints will never return fewer nodes than RF? It seems natural to me that the natural endpoint count should always match RF, unless the total number of nodes in the cluster is lacking. But this gets complicated with NTS since the requirement is suddenly that you have enough in each DC. This probably relates to previous discussions on whether or not to allow an RF which is higher than the number of nodes in a cluster. In this case, we failed hard because we got exactly 0 endpoints and triggered assertions. In other cases we might have gotten say 1, in which case we may have successfully been able to read and write as if we had a lower RF even though the column family RF was set to 2. This seems dangerous. ERROR [pool-1-thread-2] 2010-12-07 11:18:40,638 Cassandra.java (line 3044) Internal error processing batch_mutate java.lang.AssertionError: invalid response count 1 for replication factor 0 at org.apache.cassandra.service.WriteResponseHandler.determineBlockFor(WriteResponseHandler.java:98) at org.apache.cassandra.service.WriteResponseHandler.init(WriteResponseHandler.java:48) at org.apache.cassandra.service.WriteResponseHandler.create(WriteResponseHandler.java:61) at org.apache.cassandra.locator.AbstractReplicationStrategy.getWriteResponseHandler(AbstractReplicationStrategy.java:125) at org.apache.cassandra.locator.NetworkTopologyStrategy.getWriteResponseHandler(NetworkTopologyStrategy.java:166) at org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:114) at org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:446) at org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:419) at org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.process(Cassandra.java:3036) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2555) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ERROR [pool-1-thread-3] 2010-12-07 11:18:50,474 Cassandra.java (line 2876) Internal error processing get_range_slices java.lang.AssertionError at org.apache.cassandra.service.RangeSliceResponseResolver.init(RangeSliceResponseResolver.java:53) at org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:450) at
[jira] Commented: (CASSANDRA-1072) Increment counters
[ https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968822#action_12968822 ] Kelvin Kakugawa commented on CASSANDRA-1072: Ah, I see. Good point. Let me work that out. We'll need to support SC mutation, as well, which CounterUpdate doesn't support. Increment counters -- Key: CASSANDRA-1072 URL: https://issues.apache.org/jira/browse/CASSANDRA-1072 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Johan Oskarsson Assignee: Kelvin Kakugawa Attachments: CASSANDRA-1072.120610.patch, CASSANDRA-1072.patch, increment_test.py, Partitionedcountersdesigndoc.pdf Break out the increment counters out of CASSANDRA-580. Classes are shared between the two features but without the plain version vector code the changeset becomes smaller and more manageable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-2.txt This code is now DIAMONDS. :: per-CF compaction and cleanup added. :: Massive cleanup of NodeCmd code. :: flush and repair now operate without being given a keyspace (i.e. all keyspaces will be flushed/repaired). More specifically, flush|repair|compact|cleanup all run through the same code-path. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1072) Increment counters
[ https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968832#action_12968832 ] Kelvin Kakugawa commented on CASSANDRA-1072: So, the challenge is that I mirrored the mutation interface for counters. I have two proposals that I'd like your opinion on: a) add an optional uuid field to CounterColumn, or b) add an optional uuid field to CounterMutation that covers the whole mutation. (b) is not very fine-grained. However, if a batch_add call fails, the client should retry the whole batch mutation. ntm, uuids are specific to a given counter, so there won't be any fear of collisions across keys. Although, if a batch mutation were to update the same key twice (w/in its update_map), the mutation will have to be collapsed at some point. note: if we go w/ (a), then CounterUpdate should be refactored out into just a CounterColumn. Increment counters -- Key: CASSANDRA-1072 URL: https://issues.apache.org/jira/browse/CASSANDRA-1072 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Johan Oskarsson Assignee: Kelvin Kakugawa Attachments: CASSANDRA-1072.120610.patch, CASSANDRA-1072.patch, increment_test.py, Partitionedcountersdesigndoc.pdf Break out the increment counters out of CASSANDRA-580. Classes are shared between the two features but without the plain version vector code the changeset becomes smaller and more manageable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1832) mx4j does not load
[
https://issues.apache.org/jira/browse/CASSANDRA-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968833#action_12968833
]
Rustam Aliyev commented on CASSANDRA-1832:
--
I did a bit more tests and here are some results which might help:
1. JMX port set to 9090 in cassandra-env.sh
2. On the machine where another service running on 8080 we get exception above
3. On the machine where no service running on 8080 we don't get any exception
and MX4J runs on port 9090
Seems like something checks for port 8080 even though it is configured to run
on 9090.
mx4j does not load
--
Key: CASSANDRA-1832
URL: https://issues.apache.org/jira/browse/CASSANDRA-1832
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Environment: CentOS 5.5
Reporter: Rustam Aliyev
Priority: Minor
Fix For: 0.7.0
Adding mx4j-tools.jar (latest) to the library causes following exception:
{code}
WARN 20:22:25,123 Could not start register mbean in JMX
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cassandra.utils.Mx4jTool.maybeLoad(Mx4jTool.java:67)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:169)
at
org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:55)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:216)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:134)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at
mx4j.tools.adaptor.PlainAdaptorServerSocketFactory.createServerSocket(PlainAdaptorServerSocketFactory.java:24)
at
mx4j.tools.adaptor.http.HttpAdaptor.createServerSocket(HttpAdaptor.java:672)
at mx4j.tools.adaptor.http.HttpAdaptor.start(HttpAdaptor.java:478)
... 9 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1706) CQL deletes (aka DELETE)
[
https://issues.apache.org/jira/browse/CASSANDRA-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-1706:
--
Attachment: v1-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt
CQL deletes (aka DELETE)
Key: CASSANDRA-1706
URL: https://issues.apache.org/jira/browse/CASSANDRA-1706
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments: v1-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for data removal.
This corresponds to the following RPC methods:
* remove()
* batch_mutate() (deleting, not updating)
* truncate() (?)
My thoughts on the syntax are that it can probably closely mirror a subset of
`SELECT':
{code:SQL}
DELETE (FROM)? CF [USING CONSISTENCY.LVL] WHERE EXPRESSION
{code}
Optionally, you could support a form that makes the `WHERE' clause optional,
statements without the clause would be interpreted as a column family
truncation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1706) CQL deletes (aka DELETE)
[
https://issues.apache.org/jira/browse/CASSANDRA-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-1706:
--
Assignee: Eric Evans
CQL deletes (aka DELETE)
Key: CASSANDRA-1706
URL: https://issues.apache.org/jira/browse/CASSANDRA-1706
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments: v1-0001-CASSANDRA-1706-CQL-DELETE-w-functional-tests.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for data removal.
This corresponds to the following RPC methods:
* remove()
* batch_mutate() (deleting, not updating)
* truncate() (?)
My thoughts on the syntax are that it can probably closely mirror a subset of
`SELECT':
{code:SQL}
DELETE (FROM)? CF [USING CONSISTENCY.LVL] WHERE EXPRESSION
{code}
Optionally, you could support a form that makes the `WHERE' clause optional,
statements without the clause would be interpreted as a column family
truncation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: (was: 1812-2.txt) Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-2.txt Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1812: -- Attachment: 1812-3.txt I need to better enforce that the system keyspace should not be cleaned up. Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-3.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1718) cassandra should chdir / when daemonizing
[
https://issues.apache.org/jira/browse/CASSANDRA-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968843#action_12968843
]
Eric Evans commented on CASSANDRA-1718:
---
Huh. I thought jsvc was doing this (and I want to say that it _was_ at some
point). It really seems like it ought to be.
bq. If there are concerns about Cassandra having an ongoing ability to open
filenames relative to its original working directory, then it should be
sufficient just to do a cd / in the initscript before starting Cassandra.
That case, at least, is particularly important.
We should consider it a bug if anything here relies on relative paths (and I
don't think it does).
cassandra should chdir / when daemonizing
-
Key: CASSANDRA-1718
URL: https://issues.apache.org/jira/browse/CASSANDRA-1718
Project: Cassandra
Issue Type: Bug
Components: Packaging
Environment: Debian squeeze, Cassandra 0.7.0-beta3 and trunk
(r1032649)
Reporter: paul cannon
Assignee: Eric Evans
Priority: Minor
Fix For: 0.7.1
Common practice when daemonizing is to cd / to avoid pinning a filesystem.
For example, if the oper happens to start Cassandra (by itself, or with a
manual jsvc invocation, or with the initscript) in /mnt/usb-storage, and
there is something mounted there, then the oper will not be able to unmount
the usb device that was mounted at that location, since the cassandra process
has it open as its cwd.
evidence that this isn't being done already:
{noformat}
~% sudo lsof -p 9775 | awk '$4==cwd'
jsvc9775 cassandra cwdDIR8,1 4096 147675
/home/paul/packages/cassandra/trunk
{noformat}
(That instance was invoked using the Debian initscript.)
Obviously chdir(/) isn't necessary when not daemonizing, although it
shouldn't hurt either.
If there are concerns about Cassandra having an ongoing ability to open
filenames relative to its original working directory, then it should be
sufficient just to do a cd / in the initscript before starting Cassandra.
That case, at least, is particularly important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Update of LiveSchemaUpdates by JonHe rmes
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The LiveSchemaUpdates page has been changed by JonHermes.
http://wiki.apache.org/cassandra/LiveSchemaUpdates?action=diffrev1=13rev2=14
--
{{{
$ cat schema.txt
/* Create a new keyspace */
- create keyspace Keyspace1 with replication_factor = 3 and placement_strategy
= 'org.apache.cassandra.locator.RackUnawareStrategy'
+ create keyspace Keyspace1 with replication_factor = 3 and placement_strategy
= 'org.apache.cassandra.locator.RackUnawareStrategy';
/* Switch to the new keyspace */
- use Keyspace1
+ use Keyspace1;
/* Create new column families */
- create column family Standard1 with column_type = 'Standard' and comparator =
'BytesType'
+ create column family Standard1 with column_type = 'Standard' and comparator =
'BytesType';
- create column family Standard2 with column_type = 'Standard' and comparator =
'UTF8Type' and rows_cached = 1
+ create column family Standard2 with column_type = 'Standard' and comparator =
'UTF8Type' and rows_cached = 1;
$ bin/cassandra-cli --host localhost --batch schema.txt
}}}
=== Existing Cluster (Upgrade from 0.6) ===
[jira] Created: (CASSANDRA-1833) clustertool get_endpoints needs key as String, not ByteBuffer
clustertool get_endpoints needs key as String, not ByteBuffer - Key: CASSANDRA-1833 URL: https://issues.apache.org/jira/browse/CASSANDRA-1833 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.0 rc 1, 0.7 beta 3, 0.7 beta 2, 0.7 beta 1, 0.7.0 rc 2, 0.7.1, 0.7.0 Environment: all environments Reporter: Kelvin Kakugawa Assignee: Kelvin Kakugawa Fix For: 0.7.0 rc 2, 0.7.1, 0.7.0, 0.7.0 rc 1, 0.7 beta 3, 0.7 beta 2, 0.7 beta 1 java RMI does not serialize ByteBuffer; revert clustertool to use String for key -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1833) clustertool get_endpoints needs key as String, not ByteBuffer
[ https://issues.apache.org/jira/browse/CASSANDRA-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Kakugawa updated CASSANDRA-1833: --- Attachment: CASSANDRA-1833.patch replace ByteBuffer w/ String clustertool get_endpoints needs key as String, not ByteBuffer - Key: CASSANDRA-1833 URL: https://issues.apache.org/jira/browse/CASSANDRA-1833 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7 beta 1, 0.7 beta 2, 0.7 beta 3, 0.7.0 rc 1, 0.7.0 rc 2, 0.7.1, 0.7.0 Environment: all environments Reporter: Kelvin Kakugawa Assignee: Kelvin Kakugawa Fix For: 0.7 beta 1, 0.7 beta 2, 0.7 beta 3, 0.7.0 rc 1, 0.7.0 rc 2, 0.7.1, 0.7.0 Attachments: CASSANDRA-1833.patch java RMI does not serialize ByteBuffer; revert clustertool to use String for key -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1555) Considerations for larger bloom filters
[ https://issues.apache.org/jira/browse/CASSANDRA-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968861#action_12968861 ] Ryan King commented on CASSANDRA-1555: -- Stu's last patch is incorporated (in spirit, I took a slightly different appraoch) in my latest. Considerations for larger bloom filters --- Key: CASSANDRA-1555 URL: https://issues.apache.org/jira/browse/CASSANDRA-1555 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Ryan King Fix For: 0.8 Attachments: 1555_v5.txt, addendum-to-1555.txt, cassandra-1555.tgz, CASSANDRA-1555v2.patch, CASSANDRA-1555v3.patch.gz, CASSANDRA-1555v4.patch.gz To (optimally) support SSTables larger than 143 million keys, we need to support bloom filters larger than 2^31 bits, which java.util.BitSet can't handle directly. A few options: * Switch to a BitSet class which supports 2^31 * 64 bits (Lucene's OpenBitSet) * Partition the java.util.BitSet behind our current BloomFilter ** Straightforward bit partitioning: bit N is in bitset N // 2^31 ** Separate equally sized complete bloom filters for member ranges, which can be used independently or OR'd together under memory pressure. All of these options require new approaches to serialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1823) move init script from contrib/redhat to redhat/
[ https://issues.apache.org/jira/browse/CASSANDRA-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey updated CASSANDRA-1823: --- Attachment: 0001-Move-init-script-out-of-contrib.patch Moved the init script and updated package with a redhat specific cassandra.in.sh. move init script from contrib/redhat to redhat/ --- Key: CASSANDRA-1823 URL: https://issues.apache.org/jira/browse/CASSANDRA-1823 Project: Cassandra Issue Type: Sub-task Components: Contrib, Packaging Reporter: Jonathan Ellis Assignee: Nick Bailey Priority: Minor Fix For: 0.8 Attachments: 0001-Move-init-script-out-of-contrib.patch (and update spec file for new location) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1823) move init script from contrib/redhat to redhat/
[ https://issues.apache.org/jira/browse/CASSANDRA-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-1823. - Resolution: Fixed Committed. move init script from contrib/redhat to redhat/ --- Key: CASSANDRA-1823 URL: https://issues.apache.org/jira/browse/CASSANDRA-1823 Project: Cassandra Issue Type: Sub-task Components: Contrib, Packaging Reporter: Jonathan Ellis Assignee: Nick Bailey Priority: Minor Fix For: 0.8 Attachments: 0001-Move-init-script-out-of-contrib.patch (and update spec file for new location) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1043201 - in /cassandra: branches/cassandra-0.7/src/java/org/apache/cassandra/tools/ trunk/src/java/org/apache/cassandra/tools/
Author: brandonwilliams
Date: Tue Dec 7 21:06:53 2010
New Revision: 1043201
URL: http://svn.apache.org/viewvc?rev=1043201view=rev
Log:
nodetool can display compaction stats. Patch by Edward Capriolo, reviewed by
brandonwilliams for CASSANDRA-1763
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeCmd.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
cassandra/trunk/src/java/org/apache/cassandra/tools/NodeCmd.java
cassandra/trunk/src/java/org/apache/cassandra/tools/NodeProbe.java
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeCmd.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeCmd.java?rev=1043201r1=1043200r2=1043201view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeCmd.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeCmd.java
Tue Dec 7 21:06:53 2010
@@ -37,6 +37,7 @@ import org.apache.cassandra.cache.JMXIns
import org.apache.cassandra.concurrent.IExecutorMBean;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.db.ColumnFamilyStoreMBean;
+import org.apache.cassandra.db.CompactionManagerMBean;
import org.apache.cassandra.dht.Token;
import org.apache.cassandra.net.MessagingServiceMBean;
@@ -75,7 +76,7 @@ public class NodeCmd {
clearsnapshot, tpstats, flush, drain, repair, decommission,
move, loadbalance, removetoken [status|force]|[token], +
setcachecapacity [keyspace] [cfname] [keycachecapacity]
[rowcachecapacity], +
getcompactionthreshold [keyspace] [cfname],
setcompactionthreshold [cfname] [minthreshold] [maxthreshold], +
-netstats [host], cfhistograms keyspace column_family);
+netstats [host], cfhistograms keyspace column_family,
compactionstats);
String usage = String.format(java %s --host arg command%n,
NodeCmd.class.getName());
hf.printHelp(usage, , options, header);
}
@@ -247,7 +248,17 @@ public class NodeCmd {
completed += n;
outs.printf(%-25s%10s%10s%15s%n, Responses, n/a, pending,
completed);
}
-
+
+public void printCompactionStats(PrintStream outs)
+{
+CompactionManagerMBean cm = probe.getCompactionManagerProxy();
+outs.println(compaction type: + (cm.getCompactionType() == null ?
n/a : cm.getCompactionType()));
+outs.println(column family: + (cm.getColumnFamilyInProgress() ==
null ? n/a : cm.getColumnFamilyInProgress()));
+outs.println(bytes compacted: + (cm.getBytesCompacted() == null ?
n/a : cm.getBytesCompacted()));
+outs.println(bytes total in progress: +
(cm.getBytesTotalInProgress() == null ? n/a : cm.getBytesTotalInProgress() ));
+outs.println(pending tasks: + cm.getPendingTasks());
+}
+
public void printColumnFamilyStats(PrintStream outs)
{
Map String, List ColumnFamilyStoreMBean cfstoreMap = new HashMap
String, List ColumnFamilyStoreMBean();
@@ -493,6 +504,10 @@ public class NodeCmd {
System.exit(3);
}
}
+else if (cmdName.equals(compactionstats))
+{
+nodeCmd.printCompactionStats(System.out);
+}
else if (cmdName.equals(cfstats))
{
nodeCmd.printColumnFamilyStats(System.out);
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java?rev=1043201r1=1043200r2=1043201view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
Tue Dec 7 21:06:53 2010
@@ -45,6 +45,8 @@ import org.apache.cassandra.cache.JMXIns
import org.apache.cassandra.concurrent.IExecutorMBean;
import org.apache.cassandra.config.ConfigurationException;
import org.apache.cassandra.db.ColumnFamilyStoreMBean;
+import org.apache.cassandra.db.CompactionManager;
+import org.apache.cassandra.db.CompactionManagerMBean;
import org.apache.cassandra.dht.IPartitioner;
import org.apache.cassandra.dht.Token;
import org.apache.cassandra.locator.IEndpointSnitch;
@@ -72,6 +74,7 @@ public class NodeProbe
private JMXConnector jmxc;
private MBeanServerConnection mbeanServerConn;
+private CompactionManagerMBean compactionProxy;
private StorageServiceMBean ssProxy;
private MemoryMXBean memProxy;
private RuntimeMXBean runtimeProxy;
@@ -121,6 +124,8 @@ public class NodeProbe
ssProxy =
svn commit: r1043202 - /cassandra/trunk/contrib/redhat/
Author: jbellis Date: Tue Dec 7 21:07:56 2010 New Revision: 1043202 URL: http://svn.apache.org/viewvc?rev=1043202view=rev Log: r/m empty contrib/redhat dir Removed: cassandra/trunk/contrib/redhat/
[jira] Commented: (CASSANDRA-1832) mx4j does not load
[
https://issues.apache.org/jira/browse/CASSANDRA-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969018#action_12969018
]
Ran Tavory commented on CASSANDRA-1832:
---
I think there's a confusion.
There are two ports in business, one is the JMX port (default is 8080) and one
is the MX4J port (default 8081)
If the JMX port is used when cassandra starts you see the following exception,
which is different from what's pasted in this bug report:
apache-cassandra-0.7.0-rc1 $ bin/cassandra -f
Error: Exception thrown by the agent : java.rmi.server.ExportException: Port
already in use: 8080; nested exception is:
java.net.BindException: Address already in use
If mx4j's port, by default 8081, is used, then you see the report from above,
which btw isn't fatal, the server operates correctly but without mx4j.
WARN 20:22:25,123 Could not start register mbean in JMX
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cassandra.utils.Mx4jTool.maybeLoad(Mx4jTool.java:67)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:169)
at
org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:55)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:216)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:134)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at
mx4j.tools.adaptor.PlainAdaptorServerSocketFactory.createServerSocket(PlainAdaptorServerSocketFactory.java:24)
at
mx4j.tools.adaptor.http.HttpAdaptor.createServerSocket(HttpAdaptor.java:672)
at mx4j.tools.adaptor.http.HttpAdaptor.start(HttpAdaptor.java:478)
... 9 more
So the problem in this case. I believe was that mx4j's port was bound to a
different process.
To control the port used by mx4j use -Dmx4jport=8082. See
https://issues.apache.org/jira/browse/CASSANDRA-1068 for more details.
I think this is not a bug and recommend to close it as such.
I will, however, attach a patch for trunk to make this more obvious and add
-Dmx4jport=8081 to conf/cassandra-env.sh
mx4j does not load
--
Key: CASSANDRA-1832
URL: https://issues.apache.org/jira/browse/CASSANDRA-1832
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Environment: CentOS 5.5
Reporter: Rustam Aliyev
Priority: Minor
Fix For: 0.7.0
Adding mx4j-tools.jar (latest) to the library causes following exception:
{code}
WARN 20:22:25,123 Could not start register mbean in JMX
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cassandra.utils.Mx4jTool.maybeLoad(Mx4jTool.java:67)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:169)
at
org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:55)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:216)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:134)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at
mx4j.tools.adaptor.PlainAdaptorServerSocketFactory.createServerSocket(PlainAdaptorServerSocketFactory.java:24)
at
mx4j.tools.adaptor.http.HttpAdaptor.createServerSocket(HttpAdaptor.java:672)
at mx4j.tools.adaptor.http.HttpAdaptor.start(HttpAdaptor.java:478)
... 9 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1832) mx4j does not load
[
https://issues.apache.org/jira/browse/CASSANDRA-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tavory updated CASSANDRA-1832:
--
Attachment: CASSANDRA-1832.patch
Patch that adds the variables MX4J_ADDRESS and MX4J_PORT to
conf/cassandra-env.sh make configuration for mx4j obvious.
mx4j does not load
--
Key: CASSANDRA-1832
URL: https://issues.apache.org/jira/browse/CASSANDRA-1832
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Environment: CentOS 5.5
Reporter: Rustam Aliyev
Priority: Minor
Fix For: 0.7.0
Attachments: CASSANDRA-1832.patch
Adding mx4j-tools.jar (latest) to the library causes following exception:
{code}
WARN 20:22:25,123 Could not start register mbean in JMX
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cassandra.utils.Mx4jTool.maybeLoad(Mx4jTool.java:67)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:169)
at
org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:55)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:216)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:134)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at
mx4j.tools.adaptor.PlainAdaptorServerSocketFactory.createServerSocket(PlainAdaptorServerSocketFactory.java:24)
at
mx4j.tools.adaptor.http.HttpAdaptor.createServerSocket(HttpAdaptor.java:672)
at mx4j.tools.adaptor.http.HttpAdaptor.start(HttpAdaptor.java:478)
... 9 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1832) mx4j does not load
[
https://issues.apache.org/jira/browse/CASSANDRA-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969035#action_12969035
]
Rustam Aliyev commented on CASSANDRA-1832:
--
You right Ran, I checked this machine again and I have another service
listening on 8081.
For some reason I thought that MX4J uses same port.
With config options we can close it now.
mx4j does not load
--
Key: CASSANDRA-1832
URL: https://issues.apache.org/jira/browse/CASSANDRA-1832
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Environment: CentOS 5.5
Reporter: Rustam Aliyev
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.0
Attachments: CASSANDRA-1832.patch
Adding mx4j-tools.jar (latest) to the library causes following exception:
{code}
WARN 20:22:25,123 Could not start register mbean in JMX
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cassandra.utils.Mx4jTool.maybeLoad(Mx4jTool.java:67)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:169)
at
org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:55)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:216)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:134)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at
mx4j.tools.adaptor.PlainAdaptorServerSocketFactory.createServerSocket(PlainAdaptorServerSocketFactory.java:24)
at
mx4j.tools.adaptor.http.HttpAdaptor.createServerSocket(HttpAdaptor.java:672)
at mx4j.tools.adaptor.http.HttpAdaptor.start(HttpAdaptor.java:478)
... 9 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1083) Improvement to CompactionManger's submitMinorIfNeeded
[
https://issues.apache.org/jira/browse/CASSANDRA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969043#action_12969043
]
Tyler Hobbs commented on CASSANDRA-1083:
One nice thing about this strategy is that in steady state, you're compacting
about 1/target of your total SSTable data by size. This gives you a much
smoother (and tunable) impact from compaction. Recompaction of recently
compacted data shouldn't be any more frequent than with the current strategy;
this is especially true since there would no longer be cascading compactions.
Minor nitpick -- compactions happen after every min_compaction_threshold - 1
thresholds, so a default of 5 instead of 4 might be a good idea.
I think this should be easy to code up. Jonathan, do you want to me to go
ahead with this?
Improvement to CompactionManger's submitMinorIfNeeded
-
Key: CASSANDRA-1083
URL: https://issues.apache.org/jira/browse/CASSANDRA-1083
Project: Cassandra
Issue Type: Improvement
Reporter: Ryan King
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 0.7.1
Attachments: 1083-configurable-compaction-thresholds.patch,
compaction_simulation.rb
We've discovered that we are unable to tune compaction the way we want for
our production cluster. I think the current algorithm doesn't do this as well
as it could, since it doesn't sort the sstables by size before doing the
bucketing, which means the tuning parameters have unpredictable results.
I looked at CASSANDRA-792, but it seems like overkill. Here's an alternative
proposal:
config operations:
minimumCompactionThreshold
maximumCompactionThreshold
targetSSTableCount
The first two would mean what they currently mean: the bounds on how many
sstables to compact in one compaction operation. The 3rd is a target for how
many SSTables you'd like to have.
Pseudo code algorithm for determining whether or not to do a minor compaction:
{noformat}
if sstables.length + minimumCompactionThreshold -1 targetSSTableCount
sort sstables from smallest to largest
compact the up to maximumCompactionThreshold smallest tables
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1083) Improvement to CompactionManger's submitMinorIfNeeded
[
https://issues.apache.org/jira/browse/CASSANDRA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969043#action_12969043
]
Tyler Hobbs edited comment on CASSANDRA-1083 at 12/7/10 5:18 PM:
-
One nice thing about this strategy is that in steady state, you're compacting
about 1/target of your total SSTable data by size. This gives you a much
smoother (and tunable) impact from compaction. Recompaction of recently
compacted data shouldn't be any more frequent than with the current strategy;
this is especially true since there would no longer be cascading compactions.
Minor nitpick -- compactions happen after every min_compaction_threshold - 1
flushes, so a default of 5 instead of 4 might be a good idea.
I think this should be easy to code up. Jonathan, do you want to me to go
ahead with this?
was (Author: thobbs):
One nice thing about this strategy is that in steady state, you're
compacting about 1/target of your total SSTable data by size. This gives you a
much smoother (and tunable) impact from compaction. Recompaction of recently
compacted data shouldn't be any more frequent than with the current strategy;
this is especially true since there would no longer be cascading compactions.
Minor nitpick -- compactions happen after every min_compaction_threshold - 1
thresholds, so a default of 5 instead of 4 might be a good idea.
I think this should be easy to code up. Jonathan, do you want to me to go
ahead with this?
Improvement to CompactionManger's submitMinorIfNeeded
-
Key: CASSANDRA-1083
URL: https://issues.apache.org/jira/browse/CASSANDRA-1083
Project: Cassandra
Issue Type: Improvement
Reporter: Ryan King
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 0.7.1
Attachments: 1083-configurable-compaction-thresholds.patch,
compaction_simulation.rb
We've discovered that we are unable to tune compaction the way we want for
our production cluster. I think the current algorithm doesn't do this as well
as it could, since it doesn't sort the sstables by size before doing the
bucketing, which means the tuning parameters have unpredictable results.
I looked at CASSANDRA-792, but it seems like overkill. Here's an alternative
proposal:
config operations:
minimumCompactionThreshold
maximumCompactionThreshold
targetSSTableCount
The first two would mean what they currently mean: the bounds on how many
sstables to compact in one compaction operation. The 3rd is a target for how
many SSTables you'd like to have.
Pseudo code algorithm for determining whether or not to do a minor compaction:
{noformat}
if sstables.length + minimumCompactionThreshold -1 targetSSTableCount
sort sstables from smallest to largest
compact the up to maximumCompactionThreshold smallest tables
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1814) validation is inefficient
[ https://issues.apache.org/jira/browse/CASSANDRA-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969064#action_12969064 ] Gary Dusbabek commented on CASSANDRA-1814: -- Some of the validations (integer, bytes) just become noops. Most just needed to verify field length. Utf8 was tricky. Instead of using a CharsetDecoder (which would have generated garbage), I looked for a validation algorithm that operated on the raw bytes. validation is inefficient - Key: CASSANDRA-1814 URL: https://issues.apache.org/jira/browse/CASSANDRA-1814 Project: Cassandra Issue Type: Improvement Affects Versions: 0.7.0 rc 1 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Attachments: v1-0001-type-validations-that-generate-less-garbage.txt We do all validation by simply calling AbstractType.getString(). This generates garbage needlessly and has a lot of overhead. A simpler interface would be to make AbstractType.validate abstract and have the child classes implement it in an intelligent and efficient way. EDIT: Somewhat related: It looks like we're attempting to validate column names in ThriftValidation.validateColumns(). Is this intentional? Nevermind that part. I get it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1072) Increment counters
[ https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Kakugawa updated CASSANDRA-1072: --- Attachment: CASSANDRA-1072.120710.patch api update: replace CounterUpdate w/ CounterColumn (allow optional uuid field to be added to CounterColumn) Increment counters -- Key: CASSANDRA-1072 URL: https://issues.apache.org/jira/browse/CASSANDRA-1072 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Johan Oskarsson Assignee: Kelvin Kakugawa Attachments: CASSANDRA-1072.120710.patch, CASSANDRA-1072.patch, increment_test.py, Partitionedcountersdesigndoc.pdf Break out the increment counters out of CASSANDRA-580. Classes are shared between the two features but without the plain version vector code the changeset becomes smaller and more manageable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite: org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite: org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time until
the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1833) clustertool get_endpoints needs key as String, not ByteBuffer
[ https://issues.apache.org/jira/browse/CASSANDRA-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Kakugawa updated CASSANDRA-1833: --- Attachment: CASSANDRA-1833.120710.patch modified to use byte[] (like beta-2) clustertool get_endpoints needs key as String, not ByteBuffer - Key: CASSANDRA-1833 URL: https://issues.apache.org/jira/browse/CASSANDRA-1833 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7 beta 3 Environment: all environments Reporter: Kelvin Kakugawa Assignee: Kelvin Kakugawa Priority: Trivial Fix For: 0.7.0 Attachments: CASSANDRA-1833.120710.patch java RMI does not serialize ByteBuffer; revert clustertool to use String for key -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1833) clustertool get_endpoints needs key as String, not ByteBuffer
[ https://issues.apache.org/jira/browse/CASSANDRA-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Kakugawa updated CASSANDRA-1833: --- Attachment: (was: CASSANDRA-1833.patch) clustertool get_endpoints needs key as String, not ByteBuffer - Key: CASSANDRA-1833 URL: https://issues.apache.org/jira/browse/CASSANDRA-1833 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7 beta 3 Environment: all environments Reporter: Kelvin Kakugawa Assignee: Kelvin Kakugawa Priority: Trivial Fix For: 0.7.0 Attachments: CASSANDRA-1833.120710.patch java RMI does not serialize ByteBuffer; revert clustertool to use String for key -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
[
https://issues.apache.org/jira/browse/CASSANDRA-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969078#action_12969078
]
Eric Evans commented on CASSANDRA-1834:
---
a bisect suggests it was introduced here:
https://svn.apache.org/viewvc?view=revisionrevision=1041951
reads at ConsistencyLevel 1 throwUnavailableException immediately if
insufficient live nodes exist
patch by jbellis and tjake for CASSANDRA-1803
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1814) validation is inefficient
[ https://issues.apache.org/jira/browse/CASSANDRA-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969102#action_12969102 ] Jonathan Ellis commented on CASSANDRA-1814: --- How confident are you about the UTF8 code? Do we dare commit for 0.7.0? 0.7.1? Or leave it 0.8 only? validation is inefficient - Key: CASSANDRA-1814 URL: https://issues.apache.org/jira/browse/CASSANDRA-1814 Project: Cassandra Issue Type: Improvement Affects Versions: 0.7.0 rc 1 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Attachments: v1-0001-type-validations-that-generate-less-garbage.txt We do all validation by simply calling AbstractType.getString(). This generates garbage needlessly and has a lot of overhead. A simpler interface would be to make AbstractType.validate abstract and have the child classes implement it in an intelligent and efficient way. EDIT: Somewhat related: It looks like we're attempting to validate column names in ThriftValidation.validateColumns(). Is this intentional? Nevermind that part. I get it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1043256 - /cassandra/branches/cassandra-0.7/contrib/word_count/src/WordCount.java
Author: jbellis
Date: Wed Dec 8 00:55:29 2010
New Revision: 1043256
URL: http://svn.apache.org/viewvc?rev=1043256view=rev
Log:
clean up and comment reducer code
patch by jbellis
Modified:
cassandra/branches/cassandra-0.7/contrib/word_count/src/WordCount.java
Modified: cassandra/branches/cassandra-0.7/contrib/word_count/src/WordCount.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/word_count/src/WordCount.java?rev=1043256r1=1043255r2=1043256view=diff
==
--- cassandra/branches/cassandra-0.7/contrib/word_count/src/WordCount.java
(original)
+++ cassandra/branches/cassandra-0.7/contrib/word_count/src/WordCount.java Wed
Dec 8 00:55:29 2010
@@ -49,6 +49,9 @@ import org.apache.hadoop.util.ToolRunner
* text containing a sequence of words.
*
* For each word, we output the total number of occurrences across all texts.
+ *
+ * When outputting to Cassandra, we write the word counts as a {word, count}
column/value pair,
+ * with a row key equal to the name of the source column we read the words
from.
*/
public class WordCount extends Configured implements Tool
{
@@ -74,11 +77,17 @@ public class WordCount extends Configure
{
private final static IntWritable one = new IntWritable(1);
private Text word = new Text();
-private ByteBuffer columnName;
+private ByteBuffer sourceColumn;
+
+protected void setup(org.apache.hadoop.mapreduce.Mapper.Context
context)
+throws IOException, InterruptedException
+{
+sourceColumn =
ByteBuffer.wrap(context.getConfiguration().get(CONF_COLUMN_NAME).getBytes());
+}
public void map(ByteBuffer key, SortedMapByteBuffer, IColumn
columns, Context context) throws IOException, InterruptedException
{
-IColumn column = columns.get(columnName);
+IColumn column = columns.get(sourceColumn);
if (column == null)
return;
String value = ByteBufferUtil.string(column.value());
@@ -91,78 +100,48 @@ public class WordCount extends Configure
context.write(word, one);
}
}
-
-protected void setup(org.apache.hadoop.mapreduce.Mapper.Context
context)
-throws IOException, InterruptedException
-{
-this.columnName =
ByteBuffer.wrap(context.getConfiguration().get(CONF_COLUMN_NAME).getBytes());
-}
-
}
public static class ReducerToFilesystem extends ReducerText, IntWritable,
Text, IntWritable
{
-private IntWritable result = new IntWritable();
-
public void reduce(Text key, IterableIntWritable values, Context
context) throws IOException, InterruptedException
{
int sum = 0;
for (IntWritable val : values)
-{
sum += val.get();
-}
-
-result.set(sum);
-context.write(key, result);
+context.write(key, new IntWritable(sum));
}
}
public static class ReducerToCassandra extends ReducerText, IntWritable,
ByteBuffer, ListMutation
{
-private ListMutation results = new ArrayListMutation();
-private String columnName;
-
-public void reduce(Text key, IterableIntWritable values, Context
context) throws IOException, InterruptedException
-{
-int sum = 0;
-for (IntWritable val : values)
-{
-sum += val.get();
-}
-
-results.add(getMutation(key, sum));
-context.write(ByteBuffer.wrap(columnName.getBytes()), results);
-results.clear();
-}
+private ByteBuffer outputKey;
protected void setup(org.apache.hadoop.mapreduce.Reducer.Context
context)
-throws IOException, InterruptedException
+throws IOException, InterruptedException
{
-this.columnName = context.getConfiguration().get(CONF_COLUMN_NAME);
+outputKey =
ByteBuffer.wrap(context.getConfiguration().get(CONF_COLUMN_NAME).getBytes());
}
-private static Mutation getMutation(Text key, int sum)
+public void reduce(Text word, IterableIntWritable values, Context
context) throws IOException, InterruptedException
{
-Mutation m = new Mutation();
-m.column_or_supercolumn = getCoSC(key, sum);
-return m;
+int sum = 0;
+for (IntWritable val : values)
+sum += val.get();
+context.write(outputKey,
Collections.singletonList(getMutation(word, sum)));
}
-private static ColumnOrSuperColumn getCoSC(Text key, int sum)
+private static Mutation getMutation(Text word, int sum)
{
-// Have to convert both the key and the sum to ByteBuffers
-// for the generalized output
[jira] Resolved: (CASSANDRA-1833) clustertool get_endpoints needs key as String, not ByteBuffer
[ https://issues.apache.org/jira/browse/CASSANDRA-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1833. --- Resolution: Fixed Reviewer: jbellis committed, w/ addition of hexToBytes for nodeprobe clustertool get_endpoints needs key as String, not ByteBuffer - Key: CASSANDRA-1833 URL: https://issues.apache.org/jira/browse/CASSANDRA-1833 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7 beta 3 Environment: all environments Reporter: Kelvin Kakugawa Assignee: Kelvin Kakugawa Priority: Trivial Fix For: 0.7.0 Attachments: CASSANDRA-1833.120710.patch java RMI does not serialize ByteBuffer; revert clustertool to use String for key -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1043258 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/service/StorageService.java src/java/org/apache/cassandra/service/StorageServiceMBean.java src/ja
Author: jbellis
Date: Wed Dec 8 00:59:43 2010
New Revision: 1043258
URL: http://svn.apache.org/viewvc?rev=1043258view=rev
Log:
expose getNaturalEndpoints in StorageServiceMBean taking byte[] key; RMI cannot
serialize ByteBuffer
patch by Kelvin Kakugawa; reviewed by jbellis for CASSANDRA-1833
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageServiceMBean.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1043258r1=1043257r2=1043258view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Wed Dec 8 00:59:43 2010
@@ -1,3 +1,7 @@
+dev
+ * expose getNaturalEndpoints in StorageServiceMBean taking byte[]
+ key; RMI cannot serialize ByteBuffer (CASSANDRA-1833)
+
0.7.0-rc2
* fix live-column-count of slice ranges including tombstoned supercolumn
with live subcolumn (CASSANDRA-1591)
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java?rev=1043258r1=1043257r2=1043258view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
Wed Dec 8 00:59:43 2010
@@ -1400,6 +1400,11 @@ public class StorageService implements I
return getNaturalEndpoints(table, partitioner_.getToken(key));
}
+public ListInetAddress getNaturalEndpoints(String table, byte[] key)
+{
+return getNaturalEndpoints(table, ByteBuffer.wrap(key));
+}
+
/**
* This method returns the N endpoints that are responsible for storing the
* specified key i.e for replication.
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageServiceMBean.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageServiceMBean.java?rev=1043258r1=1043257r2=1043258view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageServiceMBean.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageServiceMBean.java
Wed Dec 8 00:59:43 2010
@@ -128,7 +128,7 @@ public interface StorageServiceMBean
* @param key - key for which we need to find the endpoint return value -
* the endpoint responsible for this key
*/
-public ListInetAddress getNaturalEndpoints(String table, ByteBuffer key);
+public ListInetAddress getNaturalEndpoints(String table, byte[] key);
/**
* Forces major compaction (all sstable files compacted)
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java?rev=1043258r1=1043257r2=1043258view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/tools/NodeProbe.java
Wed Dec 8 00:59:43 2010
@@ -401,8 +401,7 @@ public class NodeProbe
public ListInetAddress getEndpoints(String keyspace, String key)
{
-// FIXME: string key
-return ssProxy.getNaturalEndpoints(keyspace,
ByteBuffer.wrap(key.getBytes(UTF_8)));
+return ssProxy.getNaturalEndpoints(keyspace,
FBUtilities.hexToBytes(key));
}
public SetInetAddress getStreamDestinations()
[jira] Commented: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
[
https://issues.apache.org/jira/browse/CASSANDRA-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969108#action_12969108
]
Jonathan Ellis commented on CASSANDRA-1834:
---
usually when i've seen vm exited abnormally there is something in the log or
on stdout, can we get the subprocess stdout from hudson?
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1043259 - /cassandra/branches/cassandra-0.7/conf/cassandra-env.sh
Author: jbellis Date: Wed Dec 8 01:00:56 2010 New Revision: 1043259 URL: http://svn.apache.org/viewvc?rev=1043259view=rev Log: add sample mx4j options to cassandra-env.sh patch by Ran Tavory; reviewed by jbellis for CASSANDRA-1832 Modified: cassandra/branches/cassandra-0.7/conf/cassandra-env.sh Modified: cassandra/branches/cassandra-0.7/conf/cassandra-env.sh URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/conf/cassandra-env.sh?rev=1043259r1=1043258r2=1043259view=diff == --- cassandra/branches/cassandra-0.7/conf/cassandra-env.sh (original) +++ cassandra/branches/cassandra-0.7/conf/cassandra-env.sh Wed Dec 8 01:00:56 2010 @@ -47,6 +47,12 @@ fi # JMX connections. JMX_PORT=8080 +# To use mx4j, an HTML interface for JMX, add mx4j-tools.jar to the lib/ directory. +# By default mx4j listens on 0.0.0.0:8081. Uncomment the following lines to control +# its listen address and port. +#MX4J_ADDRESS=-Dmx4jaddress=0.0.0.0 +#MX4J_PORT=-Dmx4jport=8081 + # Here we create the arguments that will get passed to the jvm when # starting cassandra. @@ -112,3 +118,5 @@ JVM_OPTS=$JVM_OPTS -Djava.net.preferIPv JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=false JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false +JVM_OPTS=$JVM_OPTS $MX4J_ADDRESS +JVM_OPTS=$JVM_OPTS $MX4J_PORT
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure of cassandra-trunk on ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/844 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: Build Source Stamp: [branch cassandra/trunk] 1043262 Blamelist: jbellis BUILD FAILED: failed compile sincerely, -The Buildbot
[jira] Reopened: (CASSANDRA-1808) Duplicate JVM_OPTS set in RPM
[ https://issues.apache.org/jira/browse/CASSANDRA-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reopened CASSANDRA-1808: --- Assignee: Nick Bailey Duplicate JVM_OPTS set in RPM - Key: CASSANDRA-1808 URL: https://issues.apache.org/jira/browse/CASSANDRA-1808 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.7.0 rc 1 Environment: CentOS 5.4 and RPM found here: http://rpm.riptano.com/EL/6/x86_64/cassandra07-0.7.0-0rc1.el6.noarch.rpm Reporter: Thor Carpenter Assignee: Nick Bailey Priority: Minor After installing 0.7RC1 RPM on CentOS and starting the cassandra service I am confused by the presence of duplicate and conflicting JVM params. There seem to be multiple places where JVM_OPTS are set. Executing find on clean install reveals multiple files that set JVM_OPTS. According to the mailing list, the correct file is cassandra-env.sh although which one is unclear. It would be less confusing if this redundancy was removed. For Reference: find / -name cassandra*.sh /etc/cassandra/cassandra-env.sh /usr/share/cassandra/conf/cassandra-env.sh /usr/share/cassandra/cassandra.in.sh ps aux | grep cassandra 100 8881 51.5 54.0 620988 135616 ? Sl 21:55 0:02 /usr/bin/java -Xdebug *-Xms128M -Xmx1G* -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 *-Xms122M -Xmx122M* -XX:+HeapDumpOnOutOfMemoryError -Xss128k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dlog4j.configuration=log4j-server.properties -Dcassandra-pidfile=/var/run/cassandra/cassandra.pid -cp /etc/cassandra:/usr/share/cassandra/antlr-3.1.3.jar:/usr/share/cassandra/apache-cassandra-0.7.0-rc1-SNAPSHOT.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/avro-1.4.0-fixes.jar:/usr/share/cassandra/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/commons-cli-1.1.jar:/usr/share/cassandra/commons-codec-1.2.jar:/usr/share/cassandra/commons-collections-3.2.1.jar:/usr/share/cassandra/commons-lang-2.4.jar:/usr/share/cassandra/concurrentlinkedhashmap-lru-1.1.jar:/usr/share/cassandra/guava-r05.jar:/usr/share/cassandra/high-scale-lib.jar:/usr/share/cassandra/jackson-core-asl-1.4.0.jar:/usr/share/cassandra/jackson-mapper-asl-1.4.0.jar:/usr/share/cassandra/jetty-6.1.21.jar:/usr/share/cassandra/jetty-util-6.1.21.jar:/usr/share/cassandra/jline-0.9.94.jar:/usr/share/cassandra/json-simple-1.1.jar:/usr/share/cassandra/jug-2.0.0.jar:/usr/share/cassandra/libthrift-0.5.jar:/usr/share/cassandra/log4j-1.2.16.jar:/usr/share/cassandra/servlet-api-2.5-20081211.jar:/usr/share/cassandra/slf4j-api-1.6.1.jar:/usr/share/cassandra/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/snakeyaml-1.6.jar org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1043268 - /cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/tools/NodeCmd.java
Author: jbellis
Date: Wed Dec 8 01:16:36 2010
New Revision: 1043268
URL: http://svn.apache.org/viewvc?rev=1043268view=rev
Log:
correct usage parameters for flush, repair
patch by jbellis
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/tools/NodeCmd.java
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/tools/NodeCmd.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/tools/NodeCmd.java?rev=1043268r1=1043267r2=1043268view=diff
==
---
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/tools/NodeCmd.java
(original)
+++
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/tools/NodeCmd.java
Wed Dec 8 01:16:36 2010
@@ -75,13 +75,13 @@ public class NodeCmd {
+ info%n
+ cfstats%n
+ tpstats%n
- + flush%n
+ drain%n
+ decommission%n
+ move new token%n
+ loadbalance%n
+ removetoken token%n
- + repair|cleanup|compact [keyspace]
[columfamilies]%n
+ + flush|repair keyspace
[columnfamilies]%n
+ + cleanup|compact [keyspace]
[columfamilies]%n
+ setcachecapacity keyspace cfname
keycachecapacity rowcachecapacity%n
+ getcompactionthreshold%n
+ setcompactionthreshold [minthreshold]
([maxthreshold])%n
[jira] Commented: (CASSANDRA-1812) Allow per-CF compaction, repair, and cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969120#action_12969120 ] Jonathan Ellis commented on CASSANDRA-1812: --- needs rebase (probably due to CASSANDRA-1763) Allow per-CF compaction, repair, and cleanup Key: CASSANDRA-1812 URL: https://issues.apache.org/jira/browse/CASSANDRA-1812 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.6.8 Reporter: Tyler Hobbs Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9, 0.7.0 Attachments: 1812-2.txt, 1812-3.txt, 1812-all.txt, 1812-compact-2.txt, 1812-compact.txt It should be a pretty simple change to allow compaction, cleanup, or repair of only one CF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1811) Cleanup smallest CFs first
[ https://issues.apache.org/jira/browse/CASSANDRA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1811: -- Attachment: 1811-v2.txt Isn't it a lot simpler to (a) just sort a List instead of going through a TreeSet and (b) base it on columnFamilyStores.values() instead of metadata + get for each one? v2 attached. Cleanup smallest CFs first -- Key: CASSANDRA-1811 URL: https://issues.apache.org/jira/browse/CASSANDRA-1811 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.6.8 Reporter: Paul Querna Assignee: Jon Hermes Priority: Minor Fix For: 0.6.9 Attachments: 1811-v2.txt, 1811.txt When running a cleanup, it would be an advantage to anti-compact the smallest SSTables first, so that free disk space is gradually increased, so that larger sstables later on are more likely to successfully anti-compact. In 0.6, currently Table.forceCleanup() just iterates the list of CFs in whatever order they come from tableMetadata.getColumnFamilies, which is just a keySet(). The code should be changed to sort the CFs, smallest first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
[
https://issues.apache.org/jira/browse/CASSANDRA-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969129#action_12969129
]
Eric Evans commented on CASSANDRA-1834:
---
Is this not it?
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/console
That's everything that I see when it fails on me locally.
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1835) null error creating CF from cli
null error creating CF from cli
-
Key: CASSANDRA-1835
URL: https://issues.apache.org/jira/browse/CASSANDRA-1835
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0 rc 1
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.0
This fails with only null as the failure message:
{code}
create column family test1 with column_type = 'Super' and comparator =
'LongType' and column_metadata=[{column_name:a,validation_class:LongType}];
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1043274 - /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliUserHelp.java
Author: jbellis
Date: Wed Dec 8 01:41:46 2010
New Revision: 1043274
URL: http://svn.apache.org/viewvc?rev=1043274view=rev
Log:
fix create column family example in cli help
patch by jbellis
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliUserHelp.java
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliUserHelp.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliUserHelp.java?rev=1043274r1=1043273r2=1043274view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliUserHelp.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliUserHelp.java
Wed Dec 8 01:41:46 2010
@@ -181,8 +181,8 @@ public class CliUserHelp {
state.out.println(create column family Bar with column_type =
'Super' and comparator = 'AsciiType');
state.out.println( and rows_cached = 1;);
state.out.println(create column family Baz with comparator =
'LongType' and rows_cached = 1;);
-state.out.print(create column family Foo with
comparator=LongType and column_metadata=);
-state.out.print([{ column_name:Test,
validation_class:IntegerType, index_type:0, index_name:IdxName);
+state.out.print(create column family Foo with
comparator=UTF8Type and column_metadata=);
+state.out.print([{ column_name:test,
validation_class:IntegerType, index_type:0, index_name:TextIdx);
state.out.println(}, { column_name:'other name',
validation_class:LongType }];);
break;
[jira] Commented: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
[
https://issues.apache.org/jira/browse/CASSANDRA-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969134#action_12969134
]
Jonathan Ellis commented on CASSANDRA-1834:
---
that's the console of the junit jvm, not the console of the jvm it forked to
run the test
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1043292 - in /cassandra/trunk/redhat: cassandra cassandra.in.sh
Author: brandonwilliams Date: Wed Dec 8 03:49:56 2010 New Revision: 1043292 URL: http://svn.apache.org/viewvc?rev=1043292view=rev Log: Forgotten files from CASSANDRA-1823 Added: cassandra/trunk/redhat/cassandra cassandra/trunk/redhat/cassandra.in.sh Added: cassandra/trunk/redhat/cassandra URL: http://svn.apache.org/viewvc/cassandra/trunk/redhat/cassandra?rev=1043292view=auto == --- cassandra/trunk/redhat/cassandra (added) +++ cassandra/trunk/redhat/cassandra Wed Dec 8 03:49:56 2010 @@ -0,0 +1,48 @@ +#!/bin/bash +# +# /etc/init.d/cassandra +# +# Startup script for Cassandra +# +# chkconfig: 2345 20 80 +# description: Starts and stops Cassandra + +. /etc/rc.d/init.d/functions + +export JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/ +export CASSANDRA_HOME=/usr/share/cassandra/ +export CASSANDRA_INCLUDE=/usr/share/cassandra/cassandra.in.sh +export CASSANDRA_CONF=/etc/cassandra/conf +export CASSANDRA_OWNR=cassandra +log_file=/var/log/cassandra/cassandra.log +pid_file=/var/run/cassandra/cassandra.pid +CASSANDRA_PROG=/usr/sbin/cassandra + + +case $1 in +start) +# Cassandra startup +echo -n Starting Cassandra: +su $CASSANDRA_OWNR -c $CASSANDRA_PROG -p $pid_file $log_file 21 +echo OK +;; +stop) +# Cassandra shutdown +echo -n Shutdown Cassandra: +su $CASSANDRA_OWNR -c kill `cat $pid_file` +echo OK +;; +reload|restart) +$0 stop +$0 start +;; +status) +status -p $pid_file cassandra +;; +*) +echo Usage: `basename $0` start|stop|status|restart|reload +exit 1 +esac + +exit 0 + Added: cassandra/trunk/redhat/cassandra.in.sh URL: http://svn.apache.org/viewvc/cassandra/trunk/redhat/cassandra.in.sh?rev=1043292view=auto == --- cassandra/trunk/redhat/cassandra.in.sh (added) +++ cassandra/trunk/redhat/cassandra.in.sh Wed Dec 8 03:49:56 2010 @@ -0,0 +1,10 @@ + +# The directory where Cassandra's configs live (required) +CASSANDRA_CONF=/etc/cassandra/conf + +# The java classpath (required) +CLASSPATH=$CLASSPATH:$CASSANDRA_CONF + +for jar in /usr/share/cassandra/lib/*.jar; do +CLASSPATH=$CLASSPATH:$jar +done
[jira] Commented: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
[
https://issues.apache.org/jira/browse/CASSANDRA-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969175#action_12969175
]
Eric Evans commented on CASSANDRA-1834:
---
{noformat}
org.apache.cassandra.config.ConfigurationException: Found system table files,
but they couldn't be loaded. Did you change the partitioner?
at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:236)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:105)
at
org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:55)
at
org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:183)
at
org.apache.cassandra.service.EmbeddedCassandraService.init(EmbeddedCassandraService.java:72)
at
org.apache.cassandra.service.EmbeddedCassandraServiceTest.setup(EmbeddedCassandraServiceTest.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:422)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:931)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:785
{noformat}
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1808) Duplicate JVM_OPTS set in RPM
[ https://issues.apache.org/jira/browse/CASSANDRA-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969196#action_12969196 ] Jonathan Ellis commented on CASSANDRA-1808: --- so... there is a problem, but not w/ the spec file? Duplicate JVM_OPTS set in RPM - Key: CASSANDRA-1808 URL: https://issues.apache.org/jira/browse/CASSANDRA-1808 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.7.0 rc 1 Environment: CentOS 5.4 and RPM found here: http://rpm.riptano.com/EL/6/x86_64/cassandra07-0.7.0-0rc1.el6.noarch.rpm Reporter: Thor Carpenter Assignee: Nick Bailey Priority: Minor After installing 0.7RC1 RPM on CentOS and starting the cassandra service I am confused by the presence of duplicate and conflicting JVM params. There seem to be multiple places where JVM_OPTS are set. Executing find on clean install reveals multiple files that set JVM_OPTS. According to the mailing list, the correct file is cassandra-env.sh although which one is unclear. It would be less confusing if this redundancy was removed. For Reference: find / -name cassandra*.sh /etc/cassandra/cassandra-env.sh /usr/share/cassandra/conf/cassandra-env.sh /usr/share/cassandra/cassandra.in.sh ps aux | grep cassandra 100 8881 51.5 54.0 620988 135616 ? Sl 21:55 0:02 /usr/bin/java -Xdebug *-Xms128M -Xmx1G* -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 *-Xms122M -Xmx122M* -XX:+HeapDumpOnOutOfMemoryError -Xss128k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dlog4j.configuration=log4j-server.properties -Dcassandra-pidfile=/var/run/cassandra/cassandra.pid -cp /etc/cassandra:/usr/share/cassandra/antlr-3.1.3.jar:/usr/share/cassandra/apache-cassandra-0.7.0-rc1-SNAPSHOT.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/avro-1.4.0-fixes.jar:/usr/share/cassandra/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/commons-cli-1.1.jar:/usr/share/cassandra/commons-codec-1.2.jar:/usr/share/cassandra/commons-collections-3.2.1.jar:/usr/share/cassandra/commons-lang-2.4.jar:/usr/share/cassandra/concurrentlinkedhashmap-lru-1.1.jar:/usr/share/cassandra/guava-r05.jar:/usr/share/cassandra/high-scale-lib.jar:/usr/share/cassandra/jackson-core-asl-1.4.0.jar:/usr/share/cassandra/jackson-mapper-asl-1.4.0.jar:/usr/share/cassandra/jetty-6.1.21.jar:/usr/share/cassandra/jetty-util-6.1.21.jar:/usr/share/cassandra/jline-0.9.94.jar:/usr/share/cassandra/json-simple-1.1.jar:/usr/share/cassandra/jug-2.0.0.jar:/usr/share/cassandra/libthrift-0.5.jar:/usr/share/cassandra/log4j-1.2.16.jar:/usr/share/cassandra/servlet-api-2.5-20081211.jar:/usr/share/cassandra/slf4j-api-1.6.1.jar:/usr/share/cassandra/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/snakeyaml-1.6.jar org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
[
https://issues.apache.org/jira/browse/CASSANDRA-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969198#action_12969198
]
Jonathan Ellis commented on CASSANDRA-1834:
---
I bet having ECST extend CleanupHelper will clear that up
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1808) Duplicate JVM_OPTS set in RPM
[ https://issues.apache.org/jira/browse/CASSANDRA-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1808. --- Resolution: Not A Problem ah, it means that the rpm Thor is using was generated with an older spec file. Duplicate JVM_OPTS set in RPM - Key: CASSANDRA-1808 URL: https://issues.apache.org/jira/browse/CASSANDRA-1808 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.7.0 rc 1 Environment: CentOS 5.4 and RPM found here: http://rpm.riptano.com/EL/6/x86_64/cassandra07-0.7.0-0rc1.el6.noarch.rpm Reporter: Thor Carpenter Assignee: Nick Bailey Priority: Minor After installing 0.7RC1 RPM on CentOS and starting the cassandra service I am confused by the presence of duplicate and conflicting JVM params. There seem to be multiple places where JVM_OPTS are set. Executing find on clean install reveals multiple files that set JVM_OPTS. According to the mailing list, the correct file is cassandra-env.sh although which one is unclear. It would be less confusing if this redundancy was removed. For Reference: find / -name cassandra*.sh /etc/cassandra/cassandra-env.sh /usr/share/cassandra/conf/cassandra-env.sh /usr/share/cassandra/cassandra.in.sh ps aux | grep cassandra 100 8881 51.5 54.0 620988 135616 ? Sl 21:55 0:02 /usr/bin/java -Xdebug *-Xms128M -Xmx1G* -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 *-Xms122M -Xmx122M* -XX:+HeapDumpOnOutOfMemoryError -Xss128k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dlog4j.configuration=log4j-server.properties -Dcassandra-pidfile=/var/run/cassandra/cassandra.pid -cp /etc/cassandra:/usr/share/cassandra/antlr-3.1.3.jar:/usr/share/cassandra/apache-cassandra-0.7.0-rc1-SNAPSHOT.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/avro-1.4.0-fixes.jar:/usr/share/cassandra/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/commons-cli-1.1.jar:/usr/share/cassandra/commons-codec-1.2.jar:/usr/share/cassandra/commons-collections-3.2.1.jar:/usr/share/cassandra/commons-lang-2.4.jar:/usr/share/cassandra/concurrentlinkedhashmap-lru-1.1.jar:/usr/share/cassandra/guava-r05.jar:/usr/share/cassandra/high-scale-lib.jar:/usr/share/cassandra/jackson-core-asl-1.4.0.jar:/usr/share/cassandra/jackson-mapper-asl-1.4.0.jar:/usr/share/cassandra/jetty-6.1.21.jar:/usr/share/cassandra/jetty-util-6.1.21.jar:/usr/share/cassandra/jline-0.9.94.jar:/usr/share/cassandra/json-simple-1.1.jar:/usr/share/cassandra/jug-2.0.0.jar:/usr/share/cassandra/libthrift-0.5.jar:/usr/share/cassandra/log4j-1.2.16.jar:/usr/share/cassandra/servlet-api-2.5-20081211.jar:/usr/share/cassandra/slf4j-api-1.6.1.jar:/usr/share/cassandra/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/snakeyaml-1.6.jar org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Trivial Update of CassandraCli by ew amsley
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The CassandraCli page has been changed by ewamsley. The comment on this change is: fixed typo. http://wiki.apache.org/cassandra/CassandraCli?action=diffrev1=20rev2=21 -- Value inserted. }}} - In the example above we authenticated to 'Keyspace1' and created a record in the `Standard1` column family using the key `jsmith`. This record has three columns, `first`, `last`, and `age`. Each of these commands is the equivalent to an `insert()` using the [[API|Thrift API]]. + In the example above we authenticated to 'Keyspace1' and created a record in the `Standard2` column family using the key `jsmith`. This record has three columns, `first`, `last`, and `age`. Each of these commands is the equivalent to an `insert()` using the [[API|Thrift API]]. In API version 2.1.0 the example would go like the following due to changes in the API.
[jira] Commented: (CASSANDRA-1834) hudson test failure: Forked Java VM exited abnormally.
[
https://issues.apache.org/jira/browse/CASSANDRA-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969218#action_12969218
]
T Jake Luciani commented on CASSANDRA-1834:
---
When this happens to me I normally do remove the build/test dir to resolve
(some kind of corruption)
hudson test failure: Forked Java VM exited abnormally.
Key: CASSANDRA-1834
URL: https://issues.apache.org/jira/browse/CASSANDRA-1834
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Eric Evans
https://hudson.apache.org/hudson/view/A-F/view/Cassandra/job/Cassandra-0.7/56/
{noformat}
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Testsuite:
org.apache.cassandra.service.EmbeddedCassandraServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.service.EmbeddedCassandraServiceTest:BeforeFirstTest:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.service.EmbeddedCassandraServiceTest
FAILED (crashed)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1791) Return name of snapshot directory after creating it
[ https://issues.apache.org/jira/browse/CASSANDRA-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey updated CASSANDRA-1791: --- Attachment: 0001-Use-same-timestamp-for-full-snapshots-and-return-sna.patch Modified the code slightly so a full node snapshot uses the same timestamp for all keyspaces. The code can't return the full path since it is different for each keyspace but the directory name under snapshots/ should suffice. Return name of snapshot directory after creating it --- Key: CASSANDRA-1791 URL: https://issues.apache.org/jira/browse/CASSANDRA-1791 Project: Cassandra Issue Type: New Feature Components: Core Environment: Debian Squeeze Reporter: paul cannon Assignee: Nick Bailey Priority: Minor Fix For: 0.7.1 Attachments: 0001-Use-same-timestamp-for-full-snapshots-and-return-sna.patch When making a snapshot, the new directory is created with a timestamp and, optionally, a user-supplied tag. For the sake of automated snapshot-creating tools, it would be helpful to know unequivocally what the new snapshot directory was named (otherwise, the tool must search for a directory similar what it expects the name to be, which could be both error-prone and maybe susceptible to attack). Recommend making takeSnapshot and takeAllSnapshot return a string, which is the base component of the new snapshot's directory name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
