[jira] Commented: (CASSANDRA-1472) Add bitmap secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984595#action_12984595 ] Stu Hood commented on CASSANDRA-1472: - So. I don't want this one to get stale, but 674 is a higher priority for me this week. tjake: were you planning to implement a file format for use here? > Add bitmap secondary indexes > > > Key: CASSANDRA-1472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1472 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Stu Hood >Assignee: Stu Hood > Fix For: 0.7.1 > > Attachments: 0.7-1472-v5.tgz, 0.7-1472-v6.tgz, > 0001-CASSANDRA-1472-rebased-to-0.7-branch.txt, > 0019-Rename-bugfixes-and-fileclose.txt, 1472-v3.tgz, 1472-v4.tgz, > 1472-v5.tgz, anatomy.png, v4-bench-c32.txt > > > Bitmap indexes are a very efficient structure for dealing with immutable > data. We can take advantage of the fact that SSTables are immutable by > attaching them directly to SSTables as a new component (supported by > CASSANDRA-1471). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1968) Increase JVM young generation size
[ https://issues.apache.org/jira/browse/CASSANDRA-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984584#action_12984584 ] Todd Lipcon commented on CASSANDRA-1968: Cool, thanks. You may be interested in HBASE-3455 - probably applies to Cassandra as well. Feel free to jump in if you have thoughts. > Increase JVM young generation size > -- > > Key: CASSANDRA-1968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1968 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 0.7.0 >Reporter: Brandon Williams >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1968.txt, 1968_v2.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > Increasing the young generation size has a profound effect on performance and > cpu utilization. We should set it explicitly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1968) Increase JVM young generation size
[
https://issues.apache.org/jira/browse/CASSANDRA-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984580#action_12984580
]
Jonathan Ellis commented on CASSANDRA-1968:
---
Yes, I meant young gen.
An insert-heavy workload will have more of the young gen survive since we have
to keep data around in memtables until flush. With a read-heavy load almost
all of it is discarded. Here are some ParNew collections with about a 1.5G
young gen, mTT=1, serving mostly reads:
{code}
49527.273: [GC 49527.274: [ParNew
Desired survivor size 107347968 bytes, new threshold 1 (max 1)
- age 1: 15782840 bytes, 15782840 total
: 1696530K->21789K(1887488K), 0.0737280 secs] 6279370K->4617936K(12373248K),
0.0745280 secs] [Times: user=0.41 sys=0.00, real=0.07 secs]
Total time for which application threads were stopped: 0.1053180 seconds
49534.739: [GC 49534.739: [ParNew
Desired survivor size 107347968 bytes, new threshold 1 (max 1)
- age 1: 14990096 bytes, 14990096 total
: 1699613K->18988K(1887488K), 0.0777830 secs] 6295760K->4629494K(12373248K),
0.0786270 secs]
{code}
> Increase JVM young generation size
> --
>
> Key: CASSANDRA-1968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1968
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 0.7.1
>
> Attachments: 1968.txt, 1968_v2.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Increasing the young generation size has a profound effect on performance and
> cpu utilization. We should set it explicitly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1777) The describe_host API method is misleading in that it returns the interface associated with gossip traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984561#action_12984561 ] Eric Evans commented on CASSANDRA-1777: --- I don't see how you could build a non-Java routing-aware client without replicating the partitioner and replica placement client-side. Ick. > The describe_host API method is misleading in that it returns the interface > associated with gossip traffic > -- > > Key: CASSANDRA-1777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1777 > Project: Cassandra > Issue Type: Bug >Reporter: Nate McCall >Assignee: Brandon Williams > Fix For: 0.8 > > Attachments: 1777.txt > > Original Estimate: 16h > Remaining Estimate: 16h > > If the hardware is configured to use separate interfaces for thrift and > gossip, the gossip interface will be returned, given the results come out of > the ReplicationStrategy eventually. > I understand the approach, but given this is on the API, it effective > worthless in situations of host auto discovery via describe_ring from a > client. I actually see this as the primary use case of this method - why else > would I care about the gossip iface from the client perspective? It's current > form should be relegated to JMX only. > At the same time, we should add port information as well. > describe_splits probably has similar issues. > I see the potential cart-before-horse issues here and that this will probably > be non-trivial to fix, but I think "give me a set of all the hosts to which I > can talk" is pretty important from a client perspective. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2023) fix regression in 1968 (young gen sizing logic)
[ https://issues.apache.org/jira/browse/CASSANDRA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984549#action_12984549 ] Jonathan Ellis commented on CASSANDRA-2023: --- bq. automatic newsize calculation in the face of a manually specified MAX_HEAP_SIZE was problematic. Either one has to duplicate JVM parsing of MAX_HEAP_SIZE or ask the user to set MAX_HEAP_SIZE_IN_MB (or similar) instead. I would rather say "if you manually specify MAX_HEAP_SIZE, you must also specify HEAP_NEWSIZE." > fix regression in 1968 (young gen sizing logic) > --- > > Key: CASSANDRA-2023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2023 > Project: Cassandra > Issue Type: Bug >Reporter: Peter Schuller >Assignee: Peter Schuller > Attachments: 2023.txt > > > 1968 introduced a regression (there was still cleanup to do). In particular > it broke when an explicit MAX_HEAP_SIZE was set. Attaching *draft* patch > (needs more testing). > Allowing automatic newsize calculation in the face of a manually specified > MAX_HEAP_SIZE was problematic. Either one has to duplicate JVM parsing of > MAX_HEAP_SIZE or ask the user to set MAX_HEAP_SIZE_IN_MB (or similar) instead. > In this patch (consider it a draft) i opted for the latter + picking up > MAX_HEAP_SIZE for backwards compatibility (but with the effect that it > disables new size calculation). I tried to make it slightly more posixly > correct, but as usual no guarantees given that I have no posix shell to test > it on. > I'm not really happy about the shell acrobatics and my confidence that there > is not some left-over issue is not high. Should we just not worry about > MAX_HEAP_SIZE compatibility and remove all that compatibility cruft? Plenty > of acrobatics left still, but it would remove the more hideous parts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2023) fix regression in 1968 (young gen sizing logic)
[ https://issues.apache.org/jira/browse/CASSANDRA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Schuller updated CASSANDRA-2023: -- Attachment: 2023.txt > fix regression in 1968 (young gen sizing logic) > --- > > Key: CASSANDRA-2023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2023 > Project: Cassandra > Issue Type: Bug >Reporter: Peter Schuller >Assignee: Peter Schuller > Attachments: 2023.txt > > > 1968 introduced a regression (there was still cleanup to do). In particular > it broke when an explicit MAX_HEAP_SIZE was set. Attaching *draft* patch > (needs more testing). > Allowing automatic newsize calculation in the face of a manually specified > MAX_HEAP_SIZE was problematic. Either one has to duplicate JVM parsing of > MAX_HEAP_SIZE or ask the user to set MAX_HEAP_SIZE_IN_MB (or similar) instead. > In this patch (consider it a draft) i opted for the latter + picking up > MAX_HEAP_SIZE for backwards compatibility (but with the effect that it > disables new size calculation). I tried to make it slightly more posixly > correct, but as usual no guarantees given that I have no posix shell to test > it on. > I'm not really happy about the shell acrobatics and my confidence that there > is not some left-over issue is not high. Should we just not worry about > MAX_HEAP_SIZE compatibility and remove all that compatibility cruft? Plenty > of acrobatics left still, but it would remove the more hideous parts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2023) fix regression in 1968 (young gen sizing logic)
fix regression in 1968 (young gen sizing logic) --- Key: CASSANDRA-2023 URL: https://issues.apache.org/jira/browse/CASSANDRA-2023 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Assignee: Peter Schuller Attachments: 2023.txt 1968 introduced a regression (there was still cleanup to do). In particular it broke when an explicit MAX_HEAP_SIZE was set. Attaching *draft* patch (needs more testing). Allowing automatic newsize calculation in the face of a manually specified MAX_HEAP_SIZE was problematic. Either one has to duplicate JVM parsing of MAX_HEAP_SIZE or ask the user to set MAX_HEAP_SIZE_IN_MB (or similar) instead. In this patch (consider it a draft) i opted for the latter + picking up MAX_HEAP_SIZE for backwards compatibility (but with the effect that it disables new size calculation). I tried to make it slightly more posixly correct, but as usual no guarantees given that I have no posix shell to test it on. I'm not really happy about the shell acrobatics and my confidence that there is not some left-over issue is not high. Should we just not worry about MAX_HEAP_SIZE compatibility and remove all that compatibility cruft? Plenty of acrobatics left still, but it would remove the more hideous parts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1936) Fit partitioned counter directly into CounterColumn.value
[ https://issues.apache.org/jira/browse/CASSANDRA-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984506#action_12984506 ] Kelvin Kakugawa commented on CASSANDRA-1936: Found a regression via distributed tests. No time to dig in, right now, but I'll get you more info when I do. It's in the CounterContext : merge logic. There's a bad interaction w/ ByteBuffers, like it's trying to merge a badly formatted context. > Fit partitioned counter directly into CounterColumn.value > -- > > Key: CASSANDRA-1936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1936 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 0.8 > > Attachments: > 0001-Put-partitioned-counter-directly-in-column-value.patch, > 1936-ALT-0001-lazily-materialize-value.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > The current implementation of CounterColumn keeps both the partitioned > counter and the total value of the counter (that is, the sum of the parts of > the partitioned counter). > This waste space and this requires the code to keep both representation in > sync. This ticket propose to remove the total value from the representation > and to only calculate it when returning the value to the client. > NOTE: this breaks the on-disk file format (for counters) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1459) Allow modification of HintedHandoff configuration to be changed on the fly per node.
[ https://issues.apache.org/jira/browse/CASSANDRA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984483#action_12984483 ] Hudson commented on CASSANDRA-1459: --- Integrated in Cassandra-0.7 #187 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/187/]) Add a configurable maximum amount of time to hint for a dead host. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-1459 > Allow modification of HintedHandoff configuration to be changed on the fly > per node. > > > Key: CASSANDRA-1459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1459 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: N/A >Reporter: Jeff Davey >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1459-v2.txt, 1459.txt > > Original Estimate: 6h > Remaining Estimate: 6h > > If there is an extended downtime of a node, allow Hinted Handoff to be > disabled specifically for that node rather than having to decommission it. > If a node will be down for an extended period, it would be useful > to be able to disable HH for it until it returns, without having to > reconfigure and restart nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1970) Message version resolution
[ https://issues.apache.org/jira/browse/CASSANDRA-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1970: -- Attachment: 1970.txt Here is a sketch of what the inferring approach would look like. > Message version resolution > -- > > Key: CASSANDRA-1970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1970 > Project: Cassandra > Issue Type: Sub-task >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.8 > > Attachments: 1970.txt > > > When a new new node (version N) contacts an old node (version N-1) for the > first time, the old node will not understand the message. One resolution > mechanism would be for the old node to "bounce" the message back to the > sender. The sender would then respond by translating the message to the > appropriate version and resending it. > For this to work, 0.7.1 will need to have the "bounce" feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1777) The describe_host API method is misleading in that it returns the interface associated with gossip traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984466#action_12984466 ] Ryan King commented on CASSANDRA-1777: -- Unless you have a dns server that can understand cassandra membership, RRDNS is actually a rough way to do this. I'd prefer to supply something for clients that works correctly. > The describe_host API method is misleading in that it returns the interface > associated with gossip traffic > -- > > Key: CASSANDRA-1777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1777 > Project: Cassandra > Issue Type: Bug >Reporter: Nate McCall >Assignee: Brandon Williams > Fix For: 0.8 > > Attachments: 1777.txt > > Original Estimate: 16h > Remaining Estimate: 16h > > If the hardware is configured to use separate interfaces for thrift and > gossip, the gossip interface will be returned, given the results come out of > the ReplicationStrategy eventually. > I understand the approach, but given this is on the API, it effective > worthless in situations of host auto discovery via describe_ring from a > client. I actually see this as the primary use case of this method - why else > would I care about the gossip iface from the client perspective? It's current > form should be relegated to JMX only. > At the same time, we should add port information as well. > describe_splits probably has similar issues. > I see the potential cart-before-horse issues here and that this will probably > be non-trivial to fix, but I think "give me a set of all the hosts to which I > can talk" is pretty important from a client perspective. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1968) Increase JVM young generation size
[ https://issues.apache.org/jira/browse/CASSANDRA-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984456#action_12984456 ] Todd Lipcon commented on CASSANDRA-1968: By 1G heap you mean 1G young gen? = 1G/second/core collection rate? How much data of the 1G young gen is live generally? > Increase JVM young generation size > -- > > Key: CASSANDRA-1968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1968 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 0.7.0 >Reporter: Brandon Williams >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1968.txt, 1968_v2.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > Increasing the young generation size has a profound effect on performance and > cpu utilization. We should set it explicitly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1061560 - /cassandra/branches/cassandra-0.7/conf/cassandra.yaml
Author: jbellis Date: Thu Jan 20 23:00:03 2011 New Revision: 1061560 URL: http://svn.apache.org/viewvc?rev=1061560&view=rev Log: set out-of-the-box hint window to one hour Modified: cassandra/branches/cassandra-0.7/conf/cassandra.yaml Modified: cassandra/branches/cassandra-0.7/conf/cassandra.yaml URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/conf/cassandra.yaml?rev=1061560&r1=1061559&r2=1061560&view=diff == --- cassandra/branches/cassandra-0.7/conf/cassandra.yaml (original) +++ cassandra/branches/cassandra-0.7/conf/cassandra.yaml Thu Jan 20 23:00:03 2011 @@ -33,8 +33,7 @@ auto_bootstrap: false hinted_handoff_enabled: true # this defines the maximum amount of time a dead host will have hints # generated. After it has been dead this long, hints will be dropped. -# Maximum is approximately 50 days -max_hint_window_in_ms: 2147483647 +max_hint_window_in_ms: 360 # one hour # authentication backend, implementing IAuthenticator; used to identify users authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
[jira] Commented: (CASSANDRA-1968) Increase JVM young generation size
[ https://issues.apache.org/jira/browse/CASSANDRA-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984450#action_12984450 ] Jonathan Ellis commented on CASSANDRA-1968: --- bq. What young gen collection rates are you seeing with 100M/core? About 100ms for a 1G heap on 8 cores with a maxTenuringThreshold of 15. IIRC it's about half that with mTT=1. > Increase JVM young generation size > -- > > Key: CASSANDRA-1968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1968 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 0.7.0 >Reporter: Brandon Williams >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1968.txt, 1968_v2.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > Increasing the young generation size has a profound effect on performance and > cpu utilization. We should set it explicitly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1061557 - in /cassandra/branches/cassandra-0.7: conf/ src/java/org/apache/cassandra/config/ src/java/org/apache/cassandra/gms/ src/java/org/apache/cassandra/locator/ src/java/org/apache/c
Author: brandonwilliams
Date: Thu Jan 20 22:53:11 2011
New Revision: 1061557
URL: http://svn.apache.org/viewvc?rev=1061557&view=rev
Log:
Add a configurable maximum amount of time to hint for a dead host.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-1459
Modified:
cassandra/branches/cassandra-0.7/conf/cassandra.yaml
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/Config.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/gms/Gossiper.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageProxy.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageProxyMBean.java
Modified: cassandra/branches/cassandra-0.7/conf/cassandra.yaml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/conf/cassandra.yaml?rev=1061557&r1=1061556&r2=1061557&view=diff
==
--- cassandra/branches/cassandra-0.7/conf/cassandra.yaml (original)
+++ cassandra/branches/cassandra-0.7/conf/cassandra.yaml Thu Jan 20 22:53:11
2011
@@ -31,6 +31,10 @@ auto_bootstrap: false
# See http://wiki.apache.org/cassandra/HintedHandoff
hinted_handoff_enabled: true
+# this defines the maximum amount of time a dead host will have hints
+# generated. After it has been dead this long, hints will be dropped.
+# Maximum is approximately 50 days
+max_hint_window_in_ms: 2147483647
# authentication backend, implementing IAuthenticator; used to identify users
authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/Config.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/Config.java?rev=1061557&r1=1061556&r2=1061557&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/Config.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/Config.java
Thu Jan 20 22:53:11 2011
@@ -34,6 +34,7 @@ public class Config
public Boolean auto_bootstrap = false;
public Boolean hinted_handoff_enabled = true;
+public Integer max_hint_window_in_ms = Integer.MAX_VALUE;
public String[] seeds;
public DiskAccessMode disk_access_mode = DiskAccessMode.auto;
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/DatabaseDescriptor.java?rev=1061557&r1=1061556&r2=1061557&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
Thu Jan 20 22:53:11 2011
@@ -1079,6 +1079,11 @@ public classDatabaseDescriptor
return conf.hinted_handoff_enabled;
}
+public static int getMaxHintWindow()
+{
+return conf.max_hint_window_in_ms;
+}
+
public static AbstractType getValueValidator(String keyspace, String cf,
ByteBuffer column)
{
return getCFMetaData(keyspace, cf).getValueValidator(column);
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/gms/Gossiper.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/gms/Gossiper.java?rev=1061557&r1=1061556&r2=1061557&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/gms/Gossiper.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/gms/Gossiper.java
Thu Jan 20 22:53:11 2011
@@ -128,7 +128,7 @@ public class Gossiper implements IFailur
private Set liveEndpoints_ = new
ConcurrentSkipListSet(inetcomparator);
/* unreachable member set */
-private Set unreachableEndpoints_ = new
ConcurrentSkipListSet(inetcomparator);
+private Map unreachableEndpoints_ = new
ConcurrentHashMap();
/* initial seeds for joining the cluster */
private Set seeds_ = new
ConcurrentSkipListSet(inetcomparator);
@@ -179,7 +179,16 @@ public class Gossiper implements IFailur
public Set getUnreachableMembers()
{
-return new HashSet(unreachableEndpoints_);
+return unreachableEndpoints_.keySet();
+}
+
+public long getEndpointDowntime(InetAddress ep)
+{
+Long downtime = unreachableEndpoints_.get(ep);
+if (dow
[jira] Commented: (CASSANDRA-1459) Allow modification of HintedHandoff configuration to be changed on the fly per node.
[ https://issues.apache.org/jira/browse/CASSANDRA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984448#action_12984448 ] Jonathan Ellis commented on CASSANDRA-1459: --- shouldHint can be simplified to return Gossiper.instance.getEndpointDowntime(ep) <= maxHintWindow; +1 w/ that change > Allow modification of HintedHandoff configuration to be changed on the fly > per node. > > > Key: CASSANDRA-1459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1459 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: N/A >Reporter: Jeff Davey >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1459-v2.txt, 1459.txt > > Original Estimate: 6h > Remaining Estimate: 6h > > If there is an extended downtime of a node, allow Hinted Handoff to be > disabled specifically for that node rather than having to decommission it. > If a node will be down for an extended period, it would be useful > to be able to disable HH for it until it returns, without having to > reconfigure and restart nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1968) Increase JVM young generation size
[ https://issues.apache.org/jira/browse/CASSANDRA-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984445#action_12984445 ] Todd Lipcon commented on CASSANDRA-1968: What young gen collection rates are you seeing with 100M/core? Over in HBase land we've found young gen of that size to pause way too long. > Increase JVM young generation size > -- > > Key: CASSANDRA-1968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1968 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 0.7.0 >Reporter: Brandon Williams >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1968.txt, 1968_v2.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > Increasing the young generation size has a profound effect on performance and > cpu utilization. We should set it explicitly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1459) Allow modification of HintedHandoff configuration to be changed on the fly per node.
[ https://issues.apache.org/jira/browse/CASSANDRA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-1459: Attachment: 1459-v2.txt Window check moved to ARS.getHintedEndpoints > Allow modification of HintedHandoff configuration to be changed on the fly > per node. > > > Key: CASSANDRA-1459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1459 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: N/A >Reporter: Jeff Davey >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1459-v2.txt, 1459.txt > > Original Estimate: 6h > Remaining Estimate: 6h > > If there is an extended downtime of a node, allow Hinted Handoff to be > disabled specifically for that node rather than having to decommission it. > If a node will be down for an extended period, it would be useful > to be able to disable HH for it until it returns, without having to > reconfigure and restart nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1705) CQL writes (aka UPDATE)
[
https://issues.apache.org/jira/browse/CASSANDRA-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved CASSANDRA-1705.
---
Resolution: Fixed
Assignee: Eric Evans
I believe this to be complete at this point.
> CQL writes (aka UPDATE)
> ---
>
> Key: CASSANDRA-1705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1705
> 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: CASSANDRA-1705.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> CQL specification and implementation for data manipulation.
> This corresponds to the following RPC methods:
> * insert()
> * batch_mutate() (writes, not deletes)
> The initial check-in to trunk/ uses a syntax that looks like:
> {code:SQL}
> UPDATE [USING CONSISTENCY.] WITH ROW(, COLUMN(,
> )[, COLUMN(...)])[ AND ROW(...)];
> {code}
> Where:
> * is the column family name.
> * Rows are a parenthesized expressions with comma separated arguments for a
> key and one or more columns.
> * Columns are a parenthesized expressions with comma separated arguments for
> the name and value (timestamp is inaccessible).
> What is still undone:
> * Complete test coverage
> And of course, all of this is still very much open to further discussion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (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 resolved CASSANDRA-1706.
---
Resolution: Fixed
Assignee: Eric Evans
I believe this to be complete at this point.
> 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: v2-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)? [USING CONSISTENCY.] WHERE
> {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] Resolved: (CASSANDRA-1704) CQL reads (aka SELECT)
[
https://issues.apache.org/jira/browse/CASSANDRA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved CASSANDRA-1704.
---
Resolution: Fixed
Assignee: Eric Evans
I believe this to be complete at this point.
> CQL reads (aka SELECT)
> --
>
> Key: CASSANDRA-1704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1704
> 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:
> v3-0001-CASSANDRA-1704.-doc-update-for-proposed-SELECT.txt,
> v3-0002-refactor-CQL-SELECT-to-be-more-SQLish.txt,
> v3-0003-make-avro-exception-factory-methods-public.txt,
> v3-0004-wrap-AvroRemoteExceptions-in-CQLExcpetions.txt,
> v3-0005-backfill-missing-system-tests.txt,
> v3-0006-add-support-for-index-scans.txt,
> v3-0007-support-empty-unset-where-clause.txt,
> v3-0008-SELECT-COUNT-.-FROM-support.txt
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Data access specification and implementation for CQL.
> This corresponds to the following RPC methods:
> * get()
> * get_slice()
> * get_count()
> * multiget_slice()
> * multiget_count()
> * get_range_slices()
> * get_indexed_slices()
> The initial check-in to trunk/ uses a syntax that looks like:
> {code:SQL}
> SELECT (FROM)? [USING CONSISTENCY.] WHERE [ROWLIMIT X]
> [COLLIMIT Y] [ASC|DESC]
> {code}
> Where:
> * is the column family name.
> * consists of relations chained by the AND keyword.
> * corresponds to one of the enum values in the RPC interface(s).
> What is still undone:
> * Support for indexes
> * Counts
> * Complete test coverage
> And of course, all of this is still very much open to further discussion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Deleted: (CASSANDRA-1854) CQL Data Definition Language
[ https://issues.apache.org/jira/browse/CASSANDRA-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans deleted CASSANDRA-1854: -- > CQL Data Definition Language > > > Key: CASSANDRA-1854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1854 > Project: Cassandra > Issue Type: Sub-task >Reporter: Eric Evans >Priority: Minor > Original Estimate: 0h > Remaining Estimate: 0h > > Data Definition Language specification and implementation for CQL. > This corresponds to the following RPC methods: > * system_update_keyspace() > * system_update_column_family() > * system_drop_keyspace() > * system_drop_column_family() > * system_add_keyspace() > * system_add_column_family -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1709) CQL keyspace and column family management
[ https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans reassigned CASSANDRA-1709: - Assignee: Eric Evans > CQL keyspace and column family management > - > > Key: CASSANDRA-1709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1709 > 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-1709-allow-underscores-in-IDENT.txt, > v1-0002-CQL-keyspace-creation.txt, > v1-0003-update-doco-for-CREATE-KEYSPACE.txt, > v1-0004-log-CQL-statement-type.txt > > Original Estimate: 0h > Remaining Estimate: 0h > > CQL specification and implementation for schema management. > This corresponds to the following RPC methods: > * system_add_column_family() > * system_add_keyspace() > * system_drop_keyspace() > * system_update_keyspace() > * system_update_columnfamily() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (CASSANDRA-1940) Twisted driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans deleted CASSANDRA-1940: -- > Twisted driver for CQL > -- > > Key: CASSANDRA-1940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1940 > Project: Cassandra > Issue Type: Sub-task >Reporter: Eric Evans >Assignee: Brandon Williams >Priority: Minor > Original Estimate: 0h > Remaining Estimate: 0h > > In-tree CQL drivers should be reasonably consistent with one another > (wherever possible/practical), and implement a minimum of: > • Query compression > • Keyspace assignment on connection > • Connection pooling / load-balancing > The goal is not to supplant the idiomatic libraries, but to provide a > consistent, stable base for them to build upon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2022) Twisted driver for CQL
Twisted driver for CQL -- Key: CASSANDRA-2022 URL: https://issues.apache.org/jira/browse/CASSANDRA-2022 Project: Cassandra Issue Type: Bug Components: API Reporter: Eric Evans Assignee: Brandon Williams Priority: Minor In-tree CQL drivers should be reasonably consistent with one another (wherever possible/practical), and implement a minimum of: • Query compression • Keyspace assignment on connection • Connection pooling / load-balancing The goal is not to supplant the idiomatic libraries, but to provide a consistent, stable base for them to build upon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984428#action_12984428 ] Hudson commented on CASSANDRA-1934: --- Integrated in Cassandra-0.7 #186 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/186/]) Update token metadata for NORMAL state when endpoint has not changed. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-1934 > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: (was: v1-0004-build-changes-to-run-serialization-tests.txt) > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: (was: v1-0006-bounce-messages-from-newer-versions.txt) > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: (was: v1-0005-0.7-message-serialization-test-binaries.txt) > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: (was: v1-0001-ICompactSerializerTest-assures-serialization-assumptio.txt) > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: v1-0003-Serialization-tests.txt, > v1-0004-build-changes-to-run-serialization-tests.txt, > v1-0005-0.7-message-serialization-test-binaries.txt, > v1-0006-bounce-messages-from-newer-versions.txt, > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: (was: v1-0003-Serialization-tests.txt) > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: v1-0004-build-changes-to-run-serialization-tests.txt, > v1-0005-0.7-message-serialization-test-binaries.txt, > v1-0006-bounce-messages-from-newer-versions.txt, > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984427#action_12984427 ] Gary Dusbabek commented on CASSANDRA-1923: -- rebased v2. > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: v1-0003-Serialization-tests.txt, > v1-0004-build-changes-to-run-serialization-tests.txt, > v1-0005-0.7-message-serialization-test-binaries.txt, > v1-0006-bounce-messages-from-newer-versions.txt, > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: (was: v2-0007-revert-when-trunk-catches-up.txt) > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: v1-0003-Serialization-tests.txt, > v1-0004-build-changes-to-run-serialization-tests.txt, > v1-0005-0.7-message-serialization-test-binaries.txt, > v1-0006-bounce-messages-from-newer-versions.txt, > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: (was: v1-0002-remove-unused-constructor-in-EstimatedHistogram.txt) > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: v1-0003-Serialization-tests.txt, > v1-0004-build-changes-to-run-serialization-tests.txt, > v1-0005-0.7-message-serialization-test-binaries.txt, > v1-0006-bounce-messages-from-newer-versions.txt, > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
[ https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-1923: - Attachment: v2-0007-revert-when-trunk-catches-up.txt v2-0006-bounce-messages-from-newer-versions.txt v2-0005-0.7-message-serialization-test-binaries.txt v2-0004-build-changes-to-run-serialization-tests.txt v2-0003-Serialization-tests.txt v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt > unit tests that validate that message serialization isn't broken in the > current version. > > > Key: CASSANDRA-1923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1923 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: v1-0003-Serialization-tests.txt, > v1-0004-build-changes-to-run-serialization-tests.txt, > v1-0005-0.7-message-serialization-test-binaries.txt, > v1-0006-bounce-messages-from-newer-versions.txt, > v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, > v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, > v2-0003-Serialization-tests.txt, > v2-0004-build-changes-to-run-serialization-tests.txt, > v2-0005-0.7-message-serialization-test-binaries.txt, > v2-0006-bounce-messages-from-newer-versions.txt > > > There are two components to this. First, code that will generate the > serialized messages. Second, code that will attempt to read the serialized > messages. > My plan is to commit this to 0.7.1 with generated serialized messages. Then > I will merge that into trunk sans the generation code. A similar process > will need to take place when we branch trunk to create 0.8, etc. On second > thought, maybe it makes sense to keep the generation code and let it morph as > the message formats change. > If the tests ever break in the 0.7 branch, that means we've created a message > incompatibility regression that needs to be fixed. If the tests ever break > in trunk (post CASSANDRA-1015), it means that something in trunk has changed > message serialization compatibility that will need to be restored (via > whatever process is used for 1015). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1459) Allow modification of HintedHandoff configuration to be changed on the fly per node.
[ https://issues.apache.org/jira/browse/CASSANDRA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984421#action_12984421 ] Jonathan Ellis commented on CASSANDRA-1459: --- can we put the window check in getHintedEndpoints so we're not adding hints only to remove them later? > Allow modification of HintedHandoff configuration to be changed on the fly > per node. > > > Key: CASSANDRA-1459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1459 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: N/A >Reporter: Jeff Davey >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1459.txt > > Original Estimate: 6h > Remaining Estimate: 6h > > If there is an extended downtime of a node, allow Hinted Handoff to be > disabled specifically for that node rather than having to decommission it. > If a node will be down for an extended period, it would be useful > to be able to disable HH for it until it returns, without having to > reconfigure and restart nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1061534 - /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
Author: brandonwilliams
Date: Thu Jan 20 21:36:49 2011
New Revision: 1061534
URL: http://svn.apache.org/viewvc?rev=1061534&view=rev
Log:
Update token metadata for NORMAL state when endpoint has not changed.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-1934
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
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=1061534&r1=1061533&r2=1061534&view=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
Thu Jan 20 21:36:49 2011
@@ -632,7 +632,9 @@ public class StorageService implements I
}
else if (endpoint.equals(currentOwner))
{
-// nothing to do
+// set state back to normal, since the node may have tried to
leave, but failed and is now back up
+// no need to persist, token/ip did not change
+tokenMetadata_.updateNormalToken(token, endpoint);
}
else if (Gossiper.instance.compareEndpointStartup(endpoint,
currentOwner) > 0)
{
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984417#action_12984417 ] Jonathan Ellis commented on CASSANDRA-1934: --- (renamed currentNode to currentOwner so I can remember the difference in the future.) > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1061525 - /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
Author: jbellis
Date: Thu Jan 20 21:31:26 2011
New Revision: 1061525
URL: http://svn.apache.org/viewvc?rev=1061525&view=rev
Log:
s/currentNode/currentOwner/
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/StorageService.java
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=1061525&r1=1061524&r2=1061525&view=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
Thu Jan 20 21:31:26 2011
@@ -622,22 +622,22 @@ public class StorageService implements I
logger_.info("Node " + endpoint + " state jump to normal");
// we don't want to update if this node is responsible for the token
and it has a later startup time than endpoint.
-InetAddress currentNode = tokenMetadata_.getEndpoint(token);
-if (currentNode == null)
+InetAddress currentOwner = tokenMetadata_.getEndpoint(token);
+if (currentOwner == null)
{
logger_.debug("New node " + endpoint + " at token " + token);
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
}
-else if (endpoint.equals(currentNode))
+else if (endpoint.equals(currentOwner))
{
// nothing to do
}
-else if (Gossiper.instance.compareEndpointStartup(endpoint,
currentNode) > 0)
+else if (Gossiper.instance.compareEndpointStartup(endpoint,
currentOwner) > 0)
{
logger_.info(String.format("Nodes %s and %s have the same token
%s. %s is the new owner",
- endpoint, currentNode, token,
endpoint));
+ endpoint, currentOwner, token,
endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
@@ -645,7 +645,7 @@ public class StorageService implements I
else
{
logger_.info(String.format("Nodes %s and %s have the same token
%s. Ignoring %s",
- endpoint, currentNode, token,
endpoint));
+ endpoint, currentOwner, token,
endpoint));
}
if (pieces.length > 2)
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984415#action_12984415 ] Jonathan Ellis commented on CASSANDRA-1934: --- +1 > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-2012) handshake protocol version during connection setup.
[ https://issues.apache.org/jira/browse/CASSANDRA-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek resolved CASSANDRA-2012. -- Resolution: Fixed I'm going to stick with the "bounce" approach outlined in 1970. > handshake protocol version during connection setup. > --- > > Key: CASSANDRA-2012 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2012 > Project: Cassandra > Issue Type: New Feature >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek > Fix For: 0.7.1 > > Attachments: 0002-node-sends-version-message-at-startup.patch > > > Really this is for 0.7.2. > CASSANDRA-2011 created verb padding so that 0.7.1 nodes don't blow up as > 0.7.2 nodes are brought up and start exchanging their version information. > This is related to CASSANDRA-1015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984416#action_12984416 ] Brandon Williams commented on CASSANDRA-1934: - Yes it will. endpoint is the node entering the ring, currentNode is the node that currently has the token passed in (which in this case will be endpoint's token also), but does not mean 'my address' to the node making the evaluation. Thus, if we see the same endpoint and token, we do nothing in the current code, causing the state to never get updated. > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984414#action_12984414 ] Jonathan Ellis commented on CASSANDRA-1934: --- bq. I still don't get it - endpoint.equals(currentNode) will never be true on the other nodes. I was thinking that currentNode == localAddress but that is not the case. It makes more sense now! :) > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-2018) drop messages from the future.
[ https://issues.apache.org/jira/browse/CASSANDRA-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek resolved CASSANDRA-2018. -- Resolution: Invalid Not needed yet. > drop messages from the future. > -- > > Key: CASSANDRA-2018 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2018 > Project: Cassandra > Issue Type: Improvement >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: > 0001-drop-aggressively-terminate-connection-when-messages.patch > > > drop messages from newer versions. > No matter how CASSANDRA-1015, it will be important for older versions to > ignore messages from the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984411#action_12984411 ] Jonathan Ellis commented on CASSANDRA-1934: --- I still don't get it -- endpoint.equals(currentNode) will never be true on the other nodes. > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1709) CQL keyspace and column family management
[
https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984408#action_12984408
]
Eric Evans commented on CASSANDRA-1709:
---
The attached patches add {{CREATE KEYSPACE}}, with a system test, and updated
documentation. There is more to come on this issue, but this part stands alone
and could go in at any time.
> CQL keyspace and column family management
> -
>
> Key: CASSANDRA-1709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1709
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Affects Versions: 0.8
>Reporter: Eric Evans
>Priority: Minor
> Fix For: 0.8
>
> Attachments: v1-0001-CASSANDRA-1709-allow-underscores-in-IDENT.txt,
> v1-0002-CQL-keyspace-creation.txt,
> v1-0003-update-doco-for-CREATE-KEYSPACE.txt,
> v1-0004-log-CQL-statement-type.txt
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> CQL specification and implementation for schema management.
> This corresponds to the following RPC methods:
> * system_add_column_family()
> * system_add_keyspace()
> * system_drop_keyspace()
> * system_update_keyspace()
> * system_update_columnfamily()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1709) CQL keyspace and column family management
[ https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-1709: -- Attachment: v1-0004-log-CQL-statement-type.txt v1-0003-update-doco-for-CREATE-KEYSPACE.txt v1-0002-CQL-keyspace-creation.txt v1-0001-CASSANDRA-1709-allow-underscores-in-IDENT.txt > CQL keyspace and column family management > - > > Key: CASSANDRA-1709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1709 > Project: Cassandra > Issue Type: Sub-task > Components: API >Affects Versions: 0.8 >Reporter: Eric Evans >Priority: Minor > Fix For: 0.8 > > Attachments: v1-0001-CASSANDRA-1709-allow-underscores-in-IDENT.txt, > v1-0002-CQL-keyspace-creation.txt, > v1-0003-update-doco-for-CREATE-KEYSPACE.txt, > v1-0004-log-CQL-statement-type.txt > > Original Estimate: 0h > Remaining Estimate: 0h > > CQL specification and implementation for schema management. > This corresponds to the following RPC methods: > * system_add_column_family() > * system_add_keyspace() > * system_drop_keyspace() > * system_update_keyspace() > * system_update_columnfamily() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-526) Operations: Allow the ability to start a node without joining the ring
[ https://issues.apache.org/jira/browse/CASSANDRA-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-526: -- Assignee: Sylvain Lebresne > Operations: Allow the ability to start a node without joining the ring > -- > > Key: CASSANDRA-526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-526 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.8 > > Attachments: 0001-Ability-to-start-without-joining-ring.patch, > 0001-Add-command-line-option-to-wait-on-command-to-join-r.patch > > > In environments with a dedicated operations team, it might make sense for > some organizations to start Cassandra nodes with a flag that allows them to > bootup, but not join the ring until they receive an explicit command. This > would help in situations if certain actions need to happen from the > engineering side before certain nodes go live and take on traffic. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-526) Operations: Allow the ability to start a node without joining the ring
[ https://issues.apache.org/jira/browse/CASSANDRA-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-526: --- Attachment: 0001-Ability-to-start-without-joining-ring.patch Preceding patch was crap (the polite expression is 'a bit overcomplicated'). Attaching version against 0.7. If a start is launch with -Dcassandra.join_ring=false, then the node does everything except launching gossip and joining (and thus bootstrapping if need be). Then there is a simple joinRing() callback in JMX to make the node join. Note that thrift is still launched. It's probably not very useful and most probably crash while in this mode, but you can call describe_version() at least :) > Operations: Allow the ability to start a node without joining the ring > -- > > Key: CASSANDRA-526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-526 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Priority: Minor > Fix For: 0.8 > > Attachments: 0001-Ability-to-start-without-joining-ring.patch, > 0001-Add-command-line-option-to-wait-on-command-to-join-r.patch > > > In environments with a dedicated operations team, it might make sense for > some organizations to start Cassandra nodes with a flag that allows them to > bootup, but not join the ring until they receive an explicit command. This > would help in situations if certain actions need to happen from the > engineering side before certain nodes go live and take on traffic. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2021) contrib/../IndexedRangeSlicer got missed in the ByteBufferUtil refactor.
[ https://issues.apache.org/jira/browse/CASSANDRA-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2021: - Attachment: v1-0001-fix-contrib-.-IndexRangedSlicer.txt > contrib/../IndexedRangeSlicer got missed in the ByteBufferUtil refactor. > > > Key: CASSANDRA-2021 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2021 > Project: Cassandra > Issue Type: Bug >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: v1-0001-fix-contrib-.-IndexRangedSlicer.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2021) contrib/../IndexedRangeSlicer got missed in the ByteBufferUtil refactor.
contrib/../IndexedRangeSlicer got missed in the ByteBufferUtil refactor. Key: CASSANDRA-2021 URL: https://issues.apache.org/jira/browse/CASSANDRA-2021 Project: Cassandra Issue Type: Bug Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.1 Attachments: v1-0001-fix-contrib-.-IndexRangedSlicer.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[
https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984385#action_12984385
]
Brandon Williams commented on CASSANDRA-1934:
-
currentNode (which failed decom and then restarted) does have the correct view
of itself (normal) but
{code}
else if (endpoint.equals(currentNode))
{
// nothing to do
}
{code}
Prevents the other nodes from updating the state from 'Leaving' back to
'normal'.
We almost update the state here:
{code}
else if (Gossiper.instance.compareEndpointStartup(endpoint,
currentNode) > 0)
{
logger_.info(String.format("Nodes %s and %s have the same token %s.
%s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
}
{code}
But don't because the generations will always be equal (in other words, this
code only handles a *different* node updated the state, not the same node
returning)
> Update token metadata for NORMAL state
> --
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.0 rc 3
>Reporter: Nick Bailey
>Assignee: Brandon Williams
>Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the
> tokenmetadata. This means if you try to decommission a node but for some
> reason it fails, and then you bring the node back up, all other nodes will
> see it in a 'Leaving' state. When the state jumps back to normal they should
> update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless
> you restart another node in the cluster in order to put it back in a 'normal'
> state.
--
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-1934) Update token metadata for NORMAL state
[
https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984385#action_12984385
]
Brandon Williams edited comment on CASSANDRA-1934 at 1/20/11 3:36 PM:
--
currentNode (which failed decom and then restarted) does have the correct view
of itself (normal) but
{code}
else if (endpoint.equals(currentNode))
{
// nothing to do
}
{code}
Prevents the other nodes from updating the state from 'Leaving' back to
'normal'.
We almost update the state here:
{code}
else if (Gossiper.instance.compareEndpointStartup(endpoint,
currentNode) > 0)
{
logger_.info(String.format("Nodes %s and %s have the same token %s.
%s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
}
{code}
But don't because the generations will always be equal (in other words, this
code only handles a *different* node updating the state, not the same node
returning)
was (Author: brandon.williams):
currentNode (which failed decom and then restarted) does have the correct
view of itself (normal) but
{code}
else if (endpoint.equals(currentNode))
{
// nothing to do
}
{code}
Prevents the other nodes from updating the state from 'Leaving' back to
'normal'.
We almost update the state here:
{code}
else if (Gossiper.instance.compareEndpointStartup(endpoint,
currentNode) > 0)
{
logger_.info(String.format("Nodes %s and %s have the same token %s.
%s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
}
{code}
But don't because the generations will always be equal (in other words, this
code only handles a *different* node updated the state, not the same node
returning)
> Update token metadata for NORMAL state
> --
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.0 rc 3
>Reporter: Nick Bailey
>Assignee: Brandon Williams
>Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the
> tokenmetadata. This means if you try to decommission a node but for some
> reason it fails, and then you bring the node back up, all other nodes will
> see it in a 'Leaving' state. When the state jumps back to normal they should
> update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless
> you restart another node in the cluster in order to put it back in a 'normal'
> state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1061497 - in /cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress: ./ operations/ tests/
Author: jbellis Date: Thu Jan 20 20:32:25 2011 New Revision: 1061497 URL: http://svn.apache.org/viewvc?rev=1061497&view=rev Log: rename tests -> operations Added: cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/ cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java - copied, changed from r1061475, cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java - copied, changed from r1060922, cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/Inserter.java cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/MultiGetter.java - copied, changed from r1060922, cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/MultiGetter.java cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/RangeSlicer.java - copied, changed from r1060922, cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/RangeSlicer.java cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Reader.java - copied, changed from r1060922, cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/Reader.java Removed: cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/ Modified: cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Stress.java Modified: cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Stress.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Stress.java?rev=1061497&r1=1061496&r2=1061497&view=diff == --- cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Stress.java (original) +++ cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Stress.java Thu Jan 20 20:32:25 2011 @@ -17,7 +17,7 @@ */ package org.apache.cassandra.contrib.stress; -import org.apache.cassandra.contrib.stress.tests.*; +import org.apache.cassandra.contrib.stress.operations.*; import org.apache.cassandra.contrib.stress.util.OperationThread; import org.apache.commons.cli.Option; Copied: cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java (from r1061475, cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java) URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java?p2=cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java&p1=cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java&r1=1061475&r2=1061497&rev=1061497&view=diff == --- cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java (original) +++ cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java Thu Jan 20 20:32:25 2011 @@ -15,7 +15,7 @@ * See the License for the specific language governing permissions and * limitations under the License. */ -package org.apache.cassandra.contrib.stress.tests; +package org.apache.cassandra.contrib.stress.operations; import org.apache.cassandra.contrib.stress.util.OperationThread; import org.apache.cassandra.thrift.*; Copied: cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java (from r1060922, cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/Inserter.java) URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java?p2=cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java&p1=cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/Inserter.java&r1=1060922&r2=1061497&rev=1061497&view=diff == --- cassandra/branches/cassandra-0.7/contrib/stress/src/or
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984377#action_12984377 ] Jonathan Ellis commented on CASSANDRA-1934: --- my point is that currentNode should always have the right view of itself anyway, it's the other nodes we are worried about (according to the issue description anyway). > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984372#action_12984372 ] Brandon Williams commented on CASSANDRA-1934: - If you are comparing endpoint to currentNode and they are the same, the generation difference can never be > 0 > Update token metadata for NORMAL state > -- > > Key: CASSANDRA-1934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1934 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 rc 3 >Reporter: Nick Bailey >Assignee: Brandon Williams >Priority: Minor > Fix For: 0.7.1 > > Attachments: 1934.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > The handleStateNormal() method in StorageService.java doesn't update the > tokenmetadata. This means if you try to decommission a node but for some > reason it fails, and then you bring the node back up, all other nodes will > see it in a 'Leaving' state. When the state jumps back to normal they should > update the token metadata to reflect that. > This also means you won't be able to call 'removetoken' on that node, unless > you restart another node in the cluster in order to put it back in a 'normal' > state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL state
[
https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984368#action_12984368
]
Jonathan Ellis commented on CASSANDRA-1934:
---
How does updating when endpoint.equals(currentNode) solve the problem?
It looks to me like the relevant path is
{code}
logger_.info(String.format("Nodes %s and %s have the same token %s.
%s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
{code}
which is already doing The Right Thing.
> Update token metadata for NORMAL state
> --
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.0 rc 3
>Reporter: Nick Bailey
>Assignee: Brandon Williams
>Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the
> tokenmetadata. This means if you try to decommission a node but for some
> reason it fails, and then you bring the node back up, all other nodes will
> see it in a 'Leaving' state. When the state jumps back to normal they should
> update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless
> you restart another node in the cluster in order to put it back in a 'normal'
> state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2020) stress.java performance falls off heavily towards the end
[ https://issues.apache.org/jira/browse/CASSANDRA-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2020: Component/s: (was: Core) Contrib > stress.java performance falls off heavily towards the end > - > > Key: CASSANDRA-2020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2020 > Project: Cassandra > Issue Type: Improvement > Components: Contrib >Reporter: Brandon Williams >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.7.1 > > Original Estimate: 8h > Remaining Estimate: 8h > > This is due to threads completing towards the end, such that there aren't > enough to fully stress the cluster. The main problem here is that > stress.java is a straight port of stress.py, where each thread runs through > some range until it's done, and the threads finish at different times > (probably offset by jvm warmup time.) Instead, a producer/consumer model > would work better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2020) stress.java performance falls off heavily towards the end
[ https://issues.apache.org/jira/browse/CASSANDRA-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2020: Component/s: Core Remaining Estimate: 8h Original Estimate: 8h > stress.java performance falls off heavily towards the end > - > > Key: CASSANDRA-2020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2020 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.7.1 > > Original Estimate: 8h > Remaining Estimate: 8h > > This is due to threads completing towards the end, such that there aren't > enough to fully stress the cluster. The main problem here is that > stress.java is a straight port of stress.py, where each thread runs through > some range until it's done, and the threads finish at different times > (probably offset by jvm warmup time.) Instead, a producer/consumer model > would work better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1061484 - /cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
Author: jbellis
Date: Thu Jan 20 20:07:07 2011
New Revision: 1061484
URL: http://svn.apache.org/viewvc?rev=1061484&view=rev
Log:
clean up help output
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java?rev=1061484&r1=1061483&r2=1061484&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
Thu Jan 20 20:07:07 2011
@@ -45,28 +45,28 @@ public class Session
static
{
-availableOptions.addOption("h", "help", false, "show
this help message and exit.");
-availableOptions.addOption("n", "num-keys", true,
"Number of keys, default:100.");
-availableOptions.addOption("N", "skip-keys",true,
"Fraction of keys to skip initially, default:0.");
-availableOptions.addOption("t", "threads", true,
"Number of threads to use, default:50.");
-availableOptions.addOption("c", "columns", true,
"Number of columns per key, default:5.");
-availableOptions.addOption("S", "column-size", true, "Size
of column values in bytes, default:34.");
-availableOptions.addOption("C", "cardinality", true,
"Number of unique values stored in columns, default:50.");
-availableOptions.addOption("d", "nodes",true, "Host
nodes (--comma separated), default:locahost.");
-availableOptions.addOption("s", "stdev",true,
"Standard Deviation Factor, default:0.1.");
-availableOptions.addOption("r", "random", false, "Use
random key generator (STDEV will have no effect), default:false.");
-availableOptions.addOption("f", "file", true,
"Write output to file");
-availableOptions.addOption("p", "port", true,
"Thrift port, default:9160.");
-availableOptions.addOption("m", "unframed", false, "Use
unframed transport, default:false.");
-availableOptions.addOption("o", "operation",true,
"Operation to perform (INSERT, READ, RANGE_SLICE, INDEXED_RANGE_SLICE,
MULTI_GET), default:INSERT.");
-availableOptions.addOption("u", "supercolumns", true,
"Number of super columns per key, default:1.");
-availableOptions.addOption("y", "family-type", true,
"Column Family Type (Super, Standard), default:Standard.");
-availableOptions.addOption("k", "keep-going", false,
"Ignore errors inserting or reading, default:false.");
-availableOptions.addOption("i", "progress-interval",true,
"Progress Report Interval (seconds), default:10.");
-availableOptions.addOption("g", "keys-per-call",true,
"Amount of keys to get_range_slices or multiget per call, default:1000.");
-availableOptions.addOption("l", "replication-factor", true,
"Replication Factor to use when creating needed column families, default:1.");
-availableOptions.addOption("e", "consistency-level",true,
"Consistency Level to use (ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM, ALL, ANY),
default:ONE.");
-availableOptions.addOption("x", "create-index", true, "Type
of index to create on needed column families (KEYS).");
+availableOptions.addOption("h", "help", false, "Show
this help message and exit");
+availableOptions.addOption("n", "num-keys", true,
"Number of keys, default:100");
+availableOptions.addOption("N", "skip-keys",true,
"Fraction of keys to skip initially, default:0");
+availableOptions.addOption("t", "threads", true,
"Number of threads to use, default:50");
+availableOptions.addOption("c", "columns", true,
"Number of columns per key, default:5");
+availableOptions.addOption("S", "column-size", true, "Size
of column values in bytes, default:34");
+availableOptions.addOption("C", "cardinality", true,
"Number of unique values stored in columns, default:50");
+availableOptions.addOption("d", "nodes",true, "Host
nodes (comma separated), default:locahost");
+availableOptions.addOption("s", "stdev",true,
"Standard Deviation Factor, default:0.1");
+availableOptions.addOption("r", "random", false, "Use
random key generator (ST
[jira] Updated: (CASSANDRA-2020) stress.java performance falls off heavily towards the end
[ https://issues.apache.org/jira/browse/CASSANDRA-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2020: Description: This is due to threads completing towards the end, such that there aren't enough to fully stress the cluster. The main problem here is that stress.java is a straight port of stress.py, where each thread runs through some range until it's done, and the threads finish at different times (probably offset by jvm warmup time.) Instead, a producer/consumer model would work better. (was: This is due to threads completing towards the end, such that there aren't enough to fully stress the cluster. The main problem here is that stress.java is a straight port of stress.py, where it each thread run through some range until it's done, and the threads finish at different times (probably offset by jvm warmup time.) Instead, a producer/consumer model would work better.) > stress.java performance falls off heavily towards the end > - > > Key: CASSANDRA-2020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2020 > Project: Cassandra > Issue Type: Improvement >Reporter: Brandon Williams >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.7.1 > > > This is due to threads completing towards the end, such that there aren't > enough to fully stress the cluster. The main problem here is that > stress.java is a straight port of stress.py, where each thread runs through > some range until it's done, and the threads finish at different times > (probably offset by jvm warmup time.) Instead, a producer/consumer model > would work better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2020) stress.java performance falls off heavily towards the end
stress.java performance falls off heavily towards the end - Key: CASSANDRA-2020 URL: https://issues.apache.org/jira/browse/CASSANDRA-2020 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 This is due to threads completing towards the end, such that there aren't enough to fully stress the cluster. The main problem here is that stress.java is a straight port of stress.py, where it each thread run through some range until it's done, and the threads finish at different times (probably offset by jvm warmup time.) Instead, a producer/consumer model would work better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1459) Allow modification of HintedHandoff configuration to be changed on the fly per node.
[ https://issues.apache.org/jira/browse/CASSANDRA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-1459: Attachment: 1459.txt Patch to define a maximum hint window in milliseconds. > Allow modification of HintedHandoff configuration to be changed on the fly > per node. > > > Key: CASSANDRA-1459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1459 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: N/A >Reporter: Jeff Davey >Assignee: Brandon Williams > Fix For: 0.7.1 > > Attachments: 1459.txt > > Original Estimate: 6h > Remaining Estimate: 6h > > If there is an extended downtime of a node, allow Hinted Handoff to be > disabled specifically for that node rather than having to decommission it. > If a node will be down for an extended period, it would be useful > to be able to disable HH for it until it returns, without having to > reconfigure and restart nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1061477 - in /cassandra/branches/cassandra-0.7/contrib/stress: README.txt bin/stress src/org/apache/cassandra/contrib/stress/Session.java
Author: jbellis
Date: Thu Jan 20 19:46:50 2011
New Revision: 1061477
URL: http://svn.apache.org/viewvc?rev=1061477&view=rev
Log:
add stress.java README
Added:
cassandra/branches/cassandra-0.7/contrib/stress/README.txt
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/bin/stress
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
Added: cassandra/branches/cassandra-0.7/contrib/stress/README.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/README.txt?rev=1061477&view=auto
==
--- cassandra/branches/cassandra-0.7/contrib/stress/README.txt (added)
+++ cassandra/branches/cassandra-0.7/contrib/stress/README.txt Thu Jan 20
19:46:50 2011
@@ -0,0 +1,59 @@
+stress
+==
+
+Description
+---
+stress is a tool for benchmarking and load testing a Cassandra
+cluster. It is significantly faster than the older py_stress tool.
+
+Setup
+-
+Run `ant` from the Cassandra source directory, then Run `ant` from the
+contrib/stress directory.
+
+Usage
+-
+There are three different modes of operation:
+
+* inserting (loading test data)
+* reading
+* range slicing (only works with the OrderPreservingPartioner)
+* indexed range slicing (works with RandomParitioner on indexed
ColumnFamilies)
+
+Important options:
+-o or --operation:
+Sets the operation mode, one of 'insert', 'read', 'rangeslice', or
'indexedrangeslice'
+-n or --num-keys:
+the number of rows to insert/read/slice; defaults to one million
+-d or --nodes:
+the node(s) to perform the test against. For multiple nodes, supply a
+comma-separated list without spaces, ex:
cassandra1,cassandra2,cassandra3
+-y or --family-type:
+Sets the ColumnFamily type. One of 'Standard' or 'Super'. If using
super,
+you probably want to set the -u option also.
+-c or --columns:
+the number of columns per row, defaults to 5
+-u or --supercolumns:
+use the number of supercolumns specified NOTE: you must set the -y
+option appropriately, or this option has no effect.
+-g or --get-range-slice-count:
+This is only used for the rangeslice operation and will *NOT* work with
+the RandomPartioner. You must set the OrderPreservingPartioner in your
+storage-conf.xml (note that you will need to wipe all existing data
+when switching partioners.) This option sets the number of rows to
+slice at a time and defaults to 1000.
+-r or --random:
+Only used for reads. By default, stress.py will perform reads on rows
+with a guassian distribution, which will cause some repeats. Setting
+this option makes the reads completely random instead.
+-i or --progress-interval:
+The interval, in seconds, at which progress will be output.
+
+Remember that you must perform inserts before performing reads or range slices.
+
+Examples
+
+
+* contrib/stress/bin/stress -d 192.168.1.101 # 1M inserts to given host
+* contrib/stress/bin/stress -d 192.168.1.101 -o read # 1M reads
+* contrib/stress/bin/stress -d 192.168.1.101,192.168.1.102 -n 1000 #
10M inserts spread across two nodes
Modified: cassandra/branches/cassandra-0.7/contrib/stress/bin/stress
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/bin/stress?rev=1061477&r1=1061476&r2=1061477&view=diff
==
--- cassandra/branches/cassandra-0.7/contrib/stress/bin/stress (original)
+++ cassandra/branches/cassandra-0.7/contrib/stress/bin/stress Thu Jan 20
19:46:50 2011
@@ -23,7 +23,7 @@ if [ "x$CLASSPATH" = "x" ]; then
exit 1
fi
-# Circuit class files.
+# Stress class files.
if [ ! -d `dirname $0`/../build/classes ]; then
echo "Unable to locate stress class files" >&2
exit 1
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java?rev=1061477&r1=1061476&r2=1061477&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/Session.java
Thu Jan 20 19:46:50 2011
@@ -52,7 +52,7 @@ public class Session
availableOptions.addOption("c", "columns", true,
"Number of columns per key, default:5.");
availableOptions.addOption("S", "column-size", true, "Size
of column values in bytes, default:34.");
availableOptions.addOption("C", "c
svn commit: r1061475 - /cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java
Author: jbellis
Date: Thu Jan 20 19:36:21 2011
New Revision: 1061475
URL: http://svn.apache.org/viewvc?rev=1061475&view=rev
Log:
fix stress.java for FBU/BBU refactor
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java?rev=1061475&r1=1061474&r2=1061475&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/tests/IndexedRangeSlicer.java
Thu Jan 20 19:36:21 2011
@@ -19,6 +19,7 @@ package org.apache.cassandra.contrib.str
import org.apache.cassandra.contrib.stress.util.OperationThread;
import org.apache.cassandra.thrift.*;
+import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.utils.FBUtilities;
import java.nio.ByteBuffer;
@@ -102,11 +103,11 @@ public class IndexedRangeSlicer extends
private int getMaxKey(List keySlices)
{
byte[] firstKey = keySlices.get(0).getKey();
-int maxKey = FBUtilities.byteBufferToInt(ByteBuffer.wrap(firstKey));
+int maxKey = ByteBufferUtil.toInt(ByteBuffer.wrap(firstKey));
for (KeySlice k : keySlices)
{
-int currentKey =
FBUtilities.byteBufferToInt(ByteBuffer.wrap(k.getKey()));
+int currentKey = ByteBufferUtil.toInt(ByteBuffer.wrap(k.getKey()));
if (currentKey > maxKey)
{
[jira] Updated: (CASSANDRA-1933) generate human-readable json
[ https://issues.apache.org/jira/browse/CASSANDRA-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1933: -- Reviewer: urandom (was: jbellis) > generate human-readable json > > > Key: CASSANDRA-1933 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1933 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.8 > > Attachments: CASSANDRA-1933.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > Let's use AbstractType getString/fromString to generate more human-readable > values in the sstable2json output -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1777) The describe_host API method is misleading in that it returns the interface associated with gossip traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984342#action_12984342 ] Brandon Williams commented on CASSANDRA-1777: - You can't build a routing-aware client from RRDNS though because you'll have no way to map the IP to the token. describe_ring really is useless if the gossip iface isn't the same as the rpc address right now (describe_ring is already using gossip for the info it returns, it's just the wrong info.) > The describe_host API method is misleading in that it returns the interface > associated with gossip traffic > -- > > Key: CASSANDRA-1777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1777 > Project: Cassandra > Issue Type: Bug >Reporter: Nate McCall >Assignee: Brandon Williams > Fix For: 0.8 > > Attachments: 1777.txt > > Original Estimate: 16h > Remaining Estimate: 16h > > If the hardware is configured to use separate interfaces for thrift and > gossip, the gossip interface will be returned, given the results come out of > the ReplicationStrategy eventually. > I understand the approach, but given this is on the API, it effective > worthless in situations of host auto discovery via describe_ring from a > client. I actually see this as the primary use case of this method - why else > would I care about the gossip iface from the client perspective? It's current > form should be relegated to JMX only. > At the same time, we should add port information as well. > describe_splits probably has similar issues. > I see the potential cart-before-horse issues here and that this will probably > be non-trivial to fix, but I think "give me a set of all the hosts to which I > can talk" is pretty important from a client perspective. -- 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-2019) add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature)
[ https://issues.apache.org/jira/browse/CASSANDRA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984320#action_12984320 ] Yang Yang edited comment on CASSANDRA-2019 at 1/20/11 2:14 PM: --- Thanks a lot Jonathan. I'll refactor my code according to the seedsFinder interface. for the tokens setting thing, what we are doing is that we extend thrift.CassandraDaemon, and do the custom tricks to figure out the token first thing in that daemon, and then we call DatabaseDescriptor.setToken() , finally we start the original thrift.CassandraDaemon. we also do other custom work at this stage, for example setting up the JMX notification listener for the SSTable notifications that we added in another jira. I just looked at CASSANDRA-957 , here are my 2cents: the token assignment problem is roughly similar to membership control. it's a fairly complex problem and there are existing solutions. so it may be better to abstract out that piece and put it in a module. for example, you could store the host--->token mapping in a central store:SimpleDB, ZooKeeper, or even the simplest , just in local storage. this membership control should be hooked up with monitoring in order to achieve automatic host fail-over and token re-assignment. for example in our case, we query EC2 autoscaler to purge a dead host (that is already not part of ASG) from its claim on a token.so leaving out the smart decision out, and only keep an interface setInitialToken() to receive such decision might be more flexible for different kinds of token assignment schemes. this is kind of similar to the approach that you have taken on the SeedsFinder interface Thanks a lot Yang was (Author: yangyangyyy): Thanks a lot Jonathan. I'll refactor my code according to the seedsFinder interface. for the tokens setting thing, what we are doing is that we extend thrift.CassandraDaemon, and do the custom tricks to figure out the token first thing in that daemon, and then we call DatabaseDescriptor.setToken() , finally we start the original thrift.CassandraDaemon. we also do other custom work at this stage, for example setting up the JMX notification listener for the SSTable notifications that we added in another jira. I just looked at CASSANDRA-957 , here are my 2cents: the token assignment problem is roughly similar to membership control. it's a fairly complex problem and there are existing solutions. so it may be better to abstract out that piece and put it in a module. for example, you could store the host--->token mapping in a central store:SimpleDB, ZooKeeper, or even the simplest , just in local storage. this membership control should be hooked up with monitoring in order to achieve automatic host fail-over and token re-assignment. for example in our case, we query EC2 autoscaler to purge a dead host (that is already not part of ASG) from its claim on a token.so leaving out the smart decision out, and only leave an interface setInitialToken() to receive such decision might be more flexible for different kinds of token assignment schemes. this is kind of similar to the approach that you have taken on the SeedsFinder interface Thanks a lot Yang > add interface to DatabaseDescriptor to help setting seeds and tokens at boot > time (for EC2 feature) > --- > > Key: CASSANDRA-2019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2019 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 0.7.0 >Reporter: Yang Yang > Fix For: 0.7.1 > > Attachments: DBdscrpt.diff > > > 1) > in the amazon EC2 environment, machines die off and more frequently, and new > instances are brought up more often, so even if we list out all the nodes in > the ring as seeds, all of these seeds may have gradually died off after some > time. at that time , new nodes joining won't be able to find the existing > ring, and will establish a new, separate ring of the same name, which is > wrong. > we have made some custom code that utilizes external systems to figure out > the EC2 autoscaler group, and at boot time feed this info to the new node. > but this requires the new node to be able to modify the seeds at boot time. > right now the DatabaseDescriptor only has a getSeeds() method, we would like > to add a setSeeds() > 2) similarly, for the token-1 trick, we wrote code to do this automatically. > the StorageService.initServer() code reads the initialToken at boot time, we > need to be able to modify this at boot time. so we would like to add > DatabaseDescriptor.setInitialToken() > patch attached. > also theoretically we could do both just b
[jira] Commented: (CASSANDRA-1777) The describe_host API method is misleading in that it returns the interface associated with gossip traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984329#action_12984329 ] Jonathan Ellis commented on CASSANDRA-1777: --- gossip is for internal cluster state, we definitely shouldn't be using it for rpc_address and rpc_port. 90% convinced the answer is "don't use describe_ring for node discovery, that's what RRDNS is for." > The describe_host API method is misleading in that it returns the interface > associated with gossip traffic > -- > > Key: CASSANDRA-1777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1777 > Project: Cassandra > Issue Type: Bug >Reporter: Nate McCall >Assignee: Brandon Williams > Fix For: 0.8 > > Attachments: 1777.txt > > Original Estimate: 16h > Remaining Estimate: 16h > > If the hardware is configured to use separate interfaces for thrift and > gossip, the gossip interface will be returned, given the results come out of > the ReplicationStrategy eventually. > I understand the approach, but given this is on the API, it effective > worthless in situations of host auto discovery via describe_ring from a > client. I actually see this as the primary use case of this method - why else > would I care about the gossip iface from the client perspective? It's current > form should be relegated to JMX only. > At the same time, we should add port information as well. > describe_splits probably has similar issues. > I see the potential cart-before-horse issues here and that this will probably > be non-trivial to fix, but I think "give me a set of all the hosts to which I > can talk" is pretty important from a client perspective. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2019) add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature)
[ https://issues.apache.org/jira/browse/CASSANDRA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Yang updated CASSANDRA-2019: - Attachment: DBdscrpt.diff addition of the setInitialToken() to DatabaseDescriptor.java > add interface to DatabaseDescriptor to help setting seeds and tokens at boot > time (for EC2 feature) > --- > > Key: CASSANDRA-2019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2019 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 0.7.0 >Reporter: Yang Yang > Fix For: 0.7.1 > > Attachments: DBdscrpt.diff > > > 1) > in the amazon EC2 environment, machines die off and more frequently, and new > instances are brought up more often, so even if we list out all the nodes in > the ring as seeds, all of these seeds may have gradually died off after some > time. at that time , new nodes joining won't be able to find the existing > ring, and will establish a new, separate ring of the same name, which is > wrong. > we have made some custom code that utilizes external systems to figure out > the EC2 autoscaler group, and at boot time feed this info to the new node. > but this requires the new node to be able to modify the seeds at boot time. > right now the DatabaseDescriptor only has a getSeeds() method, we would like > to add a setSeeds() > 2) similarly, for the token-1 trick, we wrote code to do this automatically. > the StorageService.initServer() code reads the initialToken at boot time, we > need to be able to modify this at boot time. so we would like to add > DatabaseDescriptor.setInitialToken() > patch attached. > also theoretically we could do both just by modifying the config file, but > that requires running a separate process before cassandra daemon starts, > which is not as clean. > Thanks a lot > Yang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2019) add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature)
[ https://issues.apache.org/jira/browse/CASSANDRA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984320#action_12984320 ] Yang Yang commented on CASSANDRA-2019: -- Thanks a lot Jonathan. I'll refactor my code according to the seedsFinder interface. for the tokens setting thing, what we are doing is that we extend thrift.CassandraDaemon, and do the custom tricks to figure out the token first thing in that daemon, and then we call DatabaseDescriptor.setToken() , finally we start the original thrift.CassandraDaemon. we also do other custom work at this stage, for example setting up the JMX notification listener for the SSTable notifications that we added in another jira. I just looked at CASSANDRA-957 , here are my 2cents: the token assignment problem is roughly similar to membership control. it's a fairly complex problem and there are existing solutions. so it may be better to abstract out that piece and put it in a module. for example, you could store the host--->token mapping in a central store:SimpleDB, ZooKeeper, or even the simplest , just in local storage. this membership control should be hooked up with monitoring in order to achieve automatic host fail-over and token re-assignment. for example in our case, we query EC2 autoscaler to purge a dead host (that is already not part of ASG) from its claim on a token.so leaving out the smart decision out, and only leave an interface setInitialToken() to receive such decision might be more flexible for different kinds of token assignment schemes. this is kind of similar to the approach that you have taken on the SeedsFinder interface Thanks a lot Yang > add interface to DatabaseDescriptor to help setting seeds and tokens at boot > time (for EC2 feature) > --- > > Key: CASSANDRA-2019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2019 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 0.7.0 >Reporter: Yang Yang > Fix For: 0.7.1 > > > 1) > in the amazon EC2 environment, machines die off and more frequently, and new > instances are brought up more often, so even if we list out all the nodes in > the ring as seeds, all of these seeds may have gradually died off after some > time. at that time , new nodes joining won't be able to find the existing > ring, and will establish a new, separate ring of the same name, which is > wrong. > we have made some custom code that utilizes external systems to figure out > the EC2 autoscaler group, and at boot time feed this info to the new node. > but this requires the new node to be able to modify the seeds at boot time. > right now the DatabaseDescriptor only has a getSeeds() method, we would like > to add a setSeeds() > 2) similarly, for the token-1 trick, we wrote code to do this automatically. > the StorageService.initServer() code reads the initialToken at boot time, we > need to be able to modify this at boot time. so we would like to add > DatabaseDescriptor.setInitialToken() > patch attached. > also theoretically we could do both just by modifying the config file, but > that requires running a separate process before cassandra daemon starts, > which is not as clean. > Thanks a lot > Yang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1872) Provide ability send notifications via JMX when an SSTable is written
[ https://issues.apache.org/jira/browse/CASSANDRA-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1872: -- Component/s: (was: Core) Tools Affects Version/s: (was: 0.7.1) Fix Version/s: 0.7.1 > Provide ability send notifications via JMX when an SSTable is written > - > > Key: CASSANDRA-1872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1872 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Nate McCall > Fix For: 0.7.1 > > Attachments: full.diff, jmockit-0.999.5.jar > > > One application of interest is the immediate backup of new SSTables. Relying > on JMX's MBeanNotificationInfo would be a minimally intrusive to add > "listeners" to CFS to facilitate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2019) add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature)
[ https://issues.apache.org/jira/browse/CASSANDRA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984309#action_12984309 ] Jonathan Ellis commented on CASSANDRA-2019: --- Thanks for the patch, Yang! CASSANDRA-1669 already solves 1) in 0.8. We could backport that to the 0.7 branch. CASSANDRA-957 is open for 2), scheduled for fix in 0.8. Maybe we could add setInitialToken as a temporary workaround, but by the time you call setInitialToken isn't it already starting to bootstrap with the value from the config file? I think you'd need CASSANDRA-526 to make this useful. > add interface to DatabaseDescriptor to help setting seeds and tokens at boot > time (for EC2 feature) > --- > > Key: CASSANDRA-2019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2019 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 0.7.0 >Reporter: Yang Yang > Fix For: 0.7.1 > > > 1) > in the amazon EC2 environment, machines die off and more frequently, and new > instances are brought up more often, so even if we list out all the nodes in > the ring as seeds, all of these seeds may have gradually died off after some > time. at that time , new nodes joining won't be able to find the existing > ring, and will establish a new, separate ring of the same name, which is > wrong. > we have made some custom code that utilizes external systems to figure out > the EC2 autoscaler group, and at boot time feed this info to the new node. > but this requires the new node to be able to modify the seeds at boot time. > right now the DatabaseDescriptor only has a getSeeds() method, we would like > to add a setSeeds() > 2) similarly, for the token-1 trick, we wrote code to do this automatically. > the StorageService.initServer() code reads the initialToken at boot time, we > need to be able to modify this at boot time. so we would like to add > DatabaseDescriptor.setInitialToken() > patch attached. > also theoretically we could do both just by modifying the config file, but > that requires running a separate process before cassandra daemon starts, > which is not as clean. > Thanks a lot > Yang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2019) add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature)
add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature) --- Key: CASSANDRA-2019 URL: https://issues.apache.org/jira/browse/CASSANDRA-2019 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7.0 Reporter: Yang Yang Fix For: 0.7.1 1) in the amazon EC2 environment, machines die off and more frequently, and new instances are brought up more often, so even if we list out all the nodes in the ring as seeds, all of these seeds may have gradually died off after some time. at that time , new nodes joining won't be able to find the existing ring, and will establish a new, separate ring of the same name, which is wrong. we have made some custom code that utilizes external systems to figure out the EC2 autoscaler group, and at boot time feed this info to the new node. but this requires the new node to be able to modify the seeds at boot time. right now the DatabaseDescriptor only has a getSeeds() method, we would like to add a setSeeds() 2) similarly, for the token-1 trick, we wrote code to do this automatically. the StorageService.initServer() code reads the initialToken at boot time, we need to be able to modify this at boot time. so we would like to add DatabaseDescriptor.setInitialToken() patch attached. also theoretically we could do both just by modifying the config file, but that requires running a separate process before cassandra daemon starts, which is not as clean. Thanks a lot Yang -- 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 "ClientOptions06" by Ned Wolpert
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "ClientOptions06" page has been changed by Ned Wolpert. The comment on this change is: Updated grails cassandra plugin info that the version needed for 0.6). http://wiki.apache.org/cassandra/ClientOptions06?action=diff&rev1=4&rev2=5 -- * Clojure : * CLJ-Cassandra: http://github.com/robertluo/clj-cassandra * Grails : - * Grails-Cassandra: http://github.com/wolpert/grails-cassandra + * Grails-Cassandra: http://github.com/wolpert/grails-cassandra (Download 0.5.4 from the github site for 0.6 compatibility) * C++ : * LibCassandra: http://github.com/posulliv/libcassandra * C# / .NET
[Cassandra Wiki] Update of "ClientOptions" by Ned Wolpert
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "ClientOptions" page has been changed by Ned Wolpert. The comment on this change is: Re-added in grails cassandra plugin which is now 0.7 compatible.. http://wiki.apache.org/cassandra/ClientOptions?action=diff&rev1=121&rev2=122 -- * Pelops: http://github.com/s7/scale7-pelops * Kundera http://code.google.com/p/kundera/ * Datanucleus JDO: http://github.com/tnine/Datanucleus-Cassandra-Plugin + * Grails: + * grails-cassandra: https://github.com/wolpert/grails-cassandra * .NET: * FluentCassandra: http://github.com/managedfusion/fluentcassandra * Aquiles: http://aquiles.codeplex.com/
[jira] Updated: (CASSANDRA-2018) drop messages from the future.
[ https://issues.apache.org/jira/browse/CASSANDRA-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2018: - Attachment: 0001-drop-aggressively-terminate-connection-when-messages.patch > drop messages from the future. > -- > > Key: CASSANDRA-2018 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2018 > Project: Cassandra > Issue Type: Improvement >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek >Priority: Minor > Fix For: 0.7.1 > > Attachments: > 0001-drop-aggressively-terminate-connection-when-messages.patch > > > drop messages from newer versions. > No matter how CASSANDRA-1015, it will be important for older versions to > ignore messages from the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2016) Files added with missing license headers
[ https://issues.apache.org/jira/browse/CASSANDRA-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984272#action_12984272 ] Hudson commented on CASSANDRA-2016: --- Integrated in Cassandra-0.7 #182 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/182/]) added missing license headers Patch eevans; reported by Stephen Connolly for CASSANDRA-2016 > Files added with missing license headers > > > Key: CASSANDRA-2016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2016 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Stephen Connolly >Assignee: Stephen Connolly >Priority: Blocker > Fix For: 0.7.1 > > Attachments: CASSANDRA-2016-missing-license-headers.patch > > >src/java/org/apache/cassandra/utils/BloomFilterSerializer.java >src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java >src/java/org/apache/cassandra/service/RepairCallback.java >src/java/org/apache/cassandra/io/util/ColumnSortedMap.java > are all missing license headers... ASLv2 I assume -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2018) drop messages from the future.
drop messages from the future. -- Key: CASSANDRA-2018 URL: https://issues.apache.org/jira/browse/CASSANDRA-2018 Project: Cassandra Issue Type: Improvement Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.1 drop messages from newer versions. No matter how CASSANDRA-1015, it will be important for older versions to ignore messages from the future. -- 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-tabpanel&focusedCommentId=12984273#action_12984273
]
Hudson commented on CASSANDRA-1718:
---
Integrated in Cassandra-0.7 #182 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/182/])
chdir / on startup
Patch by eevans for CASSANDRA-1718
> 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
>
> Attachments:
> v1-0001-CASSANDRA-1718-switch-to-home-directory-on-startup.txt,
> v2-0001-CASSANDRA-1718-chdir-on-startup.txt
>
>
> 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.
[jira] Updated: (CASSANDRA-2017) Replace ivy withmaven-ant-tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated CASSANDRA-2017: Attachment: CASSANDRA-2017-initial-patch.patch This is not ready to be applied yet. Only a first stab. I need to optimize somewhat. Attaching so that I can get feedback. Note if you are behind a proxy you will need to have ANT configured for the proxy or use ant-autoproxy > Replace ivy withmaven-ant-tasks > --- > > Key: CASSANDRA-2017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2017 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.1 >Reporter: Stephen Connolly > Attachments: CASSANDRA-2017-initial-patch.patch > > > Replace ivy with maven-ant-tasks. > Three main reasons: > 1. In order to deploy cassandra to maven central, we will need to use > maven-ant-tasks anyway (as ivy does not generate correct poms) > 2. In order to generate gpg signatures using ivy, we need to bootstrap a > second ivy taskdef or use multiple tasks to download bouncycastle. > Maven-ant-tasks does not require this. > 3. Allows consolidating the dependency information in one place. Rather than > having duplication with the maven-ant-tasks for deploy to central -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2017) Replace ivy withmaven-ant-tasks
Replace ivy withmaven-ant-tasks --- Key: CASSANDRA-2017 URL: https://issues.apache.org/jira/browse/CASSANDRA-2017 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: Stephen Connolly Replace ivy with maven-ant-tasks. Three main reasons: 1. In order to deploy cassandra to maven central, we will need to use maven-ant-tasks anyway (as ivy does not generate correct poms) 2. In order to generate gpg signatures using ivy, we need to bootstrap a second ivy taskdef or use multiple tasks to download bouncycastle. Maven-ant-tasks does not require this. 3. Allows consolidating the dependency information in one place. Rather than having duplication with the maven-ant-tasks for deploy to central -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2012) handshake protocol version during connection setup.
[ https://issues.apache.org/jira/browse/CASSANDRA-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984257#action_12984257 ] Gary Dusbabek commented on CASSANDRA-2012: -- This is like the approach you advocated in CASSANDRA-1970 (first message is an unalterable way to identify the communications that follow). If CASSANDRA-1015 ends up using a pre-existing framework for serialization, it would be good if protocol version could be part of the session and not each individual message (simplifies the logic of collecting it). The reasoning, for avro at least, is that this is also the time when when the protocol is sent and knowing the version is the only way to know if what comes next is an old-school message or something radically different. OTOH, if 1015 just extends the current ICompactSerializers to handle versioning, we wouldn't need this ticket, but I think it still makes sense. It enables a certain kind of flexibility wrt to interpreting internode messages. > handshake protocol version during connection setup. > --- > > Key: CASSANDRA-2012 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2012 > Project: Cassandra > Issue Type: New Feature >Reporter: Gary Dusbabek >Assignee: Gary Dusbabek > Fix For: 0.7.1 > > Attachments: 0002-node-sends-version-message-at-startup.patch > > > Really this is for 0.7.2. > CASSANDRA-2011 created verb padding so that 0.7.1 nodes don't blow up as > 0.7.2 nodes are brought up and start exchanging their version information. > This is related to CASSANDRA-1015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1718) cassandra should chdir / when daemonizing
[
https://issues.apache.org/jira/browse/CASSANDRA-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved CASSANDRA-1718.
---
Resolution: Fixed
Did.
> 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
>
> Attachments:
> v1-0001-CASSANDRA-1718-switch-to-home-directory-on-startup.txt,
> v2-0001-CASSANDRA-1718-chdir-on-startup.txt
>
>
> 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.
svn commit: r1061364 - /cassandra/branches/cassandra-0.7/debian/init
Author: eevans
Date: Thu Jan 20 16:11:02 2011
New Revision: 1061364
URL: http://svn.apache.org/viewvc?rev=1061364&view=rev
Log:
chdir / on startup
Patch by eevans for CASSANDRA-1718
Modified:
cassandra/branches/cassandra-0.7/debian/init
Modified: cassandra/branches/cassandra-0.7/debian/init
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/debian/init?rev=1061364&r1=1061363&r2=1061364&view=diff
==
--- cassandra/branches/cassandra-0.7/debian/init (original)
+++ cassandra/branches/cassandra-0.7/debian/init Thu Jan 20 16:11:02 2011
@@ -119,6 +119,9 @@ do_start()
# 2 if daemon could not be started
is_running && return 1
+cassandra_home=`getent passwd cassandra | awk -F ':' '{ print $6; }'`
+cd /# jsvc doesn't chdir() for us
+
$JSVC \
-user cassandra \
-home $JAVA_HOME \
@@ -127,6 +130,8 @@ do_start()
-outfile /var/log/$NAME/output.log \
-cp `classpath` \
-Dlog4j.configuration=log4j-server.properties \
+-XX:HeapDumpPath="$cassandra_home/java_`date +%s`.hprof" \
+-XX:ErrorFile="$cassandra_home/hs_err_`date +%s`.log" \
$JVM_OPTS \
org.apache.cassandra.thrift.CassandraDaemon
[jira] Commented: (CASSANDRA-2016) Files added with missing license headers
[
https://issues.apache.org/jira/browse/CASSANDRA-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984241#action_12984241
]
Eric Evans commented on CASSANDRA-2016:
---
There is an ant target, {{rat-write}}, which I use when creating release
artifacts (as someone has usually forgotten).
> Files added with missing license headers
>
>
> Key: CASSANDRA-2016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2016
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.1
>Reporter: Stephen Connolly
>Priority: Blocker
> Attachments: CASSANDRA-2016-missing-license-headers.patch
>
>
>src/java/org/apache/cassandra/utils/BloomFilterSerializer.java
>src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java
>src/java/org/apache/cassandra/service/RepairCallback.java
>src/java/org/apache/cassandra/io/util/ColumnSortedMap.java
> are all missing license headers... ASLv2 I assume
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1061353 - in /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra: io/util/ColumnSortedMap.java service/RepairCallback.java utils/BloomFilterSerializer.java utils/LegacyBloomFi
Author: eevans
Date: Thu Jan 20 15:56:56 2011
New Revision: 1061353
URL: http://svn.apache.org/viewvc?rev=1061353&view=rev
Log:
added missing license headers
Patch eevans; reported by Stephen Connolly for CASSANDRA-2016
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/ColumnSortedMap.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RepairCallback.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/BloomFilterSerializer.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/ColumnSortedMap.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/ColumnSortedMap.java?rev=1061353&r1=1061352&r2=1061353&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/ColumnSortedMap.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/ColumnSortedMap.java
Thu Jan 20 15:56:56 2011
@@ -1,4 +1,25 @@
package org.apache.cassandra.io.util;
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+
import java.io.DataInput;
import java.io.IOException;
@@ -261,4 +282,4 @@ class ColumnIterator implements Iterator
{
throw new UnsupportedOperationException();
}
-}
\ No newline at end of file
+}
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RepairCallback.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RepairCallback.java?rev=1061353&r1=1061352&r2=1061353&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RepairCallback.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RepairCallback.java
Thu Jan 20 15:56:56 2011
@@ -1,4 +1,25 @@
package org.apache.cassandra.service;
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+
import java.io.IOException;
import java.net.InetAddress;
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/BloomFilterSerializer.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/BloomFilterSerializer.java?rev=1061353&r1=1061352&r2=1061353&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/BloomFilterSerializer.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/BloomFilterSerializer.java
Thu Jan 20 15:56:56 2011
@@ -1,4 +1,25 @@
package org.apache.cassandra.utils;
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.or
[jira] Updated: (CASSANDRA-2016) Files added with missing license headers
[ https://issues.apache.org/jira/browse/CASSANDRA-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated CASSANDRA-2016: Comment: was deleted (was: attached patch adds the ASL headers which I assume are missing by mistake and not intentionally) > Files added with missing license headers > > > Key: CASSANDRA-2016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2016 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Stephen Connolly >Priority: Blocker > Attachments: CASSANDRA-2016-missing-license-headers.patch > > >src/java/org/apache/cassandra/utils/BloomFilterSerializer.java >src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java >src/java/org/apache/cassandra/service/RepairCallback.java >src/java/org/apache/cassandra/io/util/ColumnSortedMap.java > are all missing license headers... ASLv2 I assume -- 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-2016) Files added with missing license headers
[ https://issues.apache.org/jira/browse/CASSANDRA-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984231#action_12984231 ] Stephen Connolly edited comment on CASSANDRA-2016 at 1/20/11 10:38 AM: --- attached patch adds the ASL headers which I assume are missing by mistake and not intentionally was (Author: stephenc): renamed patch to include the issue number as it makes managing them easier when you are applying them! > Files added with missing license headers > > > Key: CASSANDRA-2016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2016 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Stephen Connolly >Priority: Blocker > Attachments: CASSANDRA-2016-missing-license-headers.patch > > >src/java/org/apache/cassandra/utils/BloomFilterSerializer.java >src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java >src/java/org/apache/cassandra/service/RepairCallback.java >src/java/org/apache/cassandra/io/util/ColumnSortedMap.java > are all missing license headers... ASLv2 I assume -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2016) Files added with missing license headers
[ https://issues.apache.org/jira/browse/CASSANDRA-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated CASSANDRA-2016: Attachment: CASSANDRA-2016-missing-license-headers.patch renamed patch to include the issue number as it makes managing them easier when you are applying them! > Files added with missing license headers > > > Key: CASSANDRA-2016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2016 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Stephen Connolly >Priority: Blocker > Attachments: CASSANDRA-2016-missing-license-headers.patch > > >src/java/org/apache/cassandra/utils/BloomFilterSerializer.java >src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java >src/java/org/apache/cassandra/service/RepairCallback.java >src/java/org/apache/cassandra/io/util/ColumnSortedMap.java > are all missing license headers... ASLv2 I assume -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2016) Files added with missing license headers
[ https://issues.apache.org/jira/browse/CASSANDRA-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated CASSANDRA-2016: Attachment: (was: missing-license-headers.diff) > Files added with missing license headers > > > Key: CASSANDRA-2016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2016 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Stephen Connolly >Priority: Blocker > Attachments: CASSANDRA-2016-missing-license-headers.patch > > >src/java/org/apache/cassandra/utils/BloomFilterSerializer.java >src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java >src/java/org/apache/cassandra/service/RepairCallback.java >src/java/org/apache/cassandra/io/util/ColumnSortedMap.java > are all missing license headers... ASLv2 I assume -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2016) Files added with missing license headers
[ https://issues.apache.org/jira/browse/CASSANDRA-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated CASSANDRA-2016: Attachment: missing-license-headers.diff attached patch adds the ASL headers which I assume are missing by mistake and not intentionally > Files added with missing license headers > > > Key: CASSANDRA-2016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2016 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Stephen Connolly >Priority: Blocker > Attachments: CASSANDRA-2016-missing-license-headers.patch > > >src/java/org/apache/cassandra/utils/BloomFilterSerializer.java >src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java >src/java/org/apache/cassandra/service/RepairCallback.java >src/java/org/apache/cassandra/io/util/ColumnSortedMap.java > are all missing license headers... ASLv2 I assume -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2016) Files added with missing license headers
Files added with missing license headers Key: CASSANDRA-2016 URL: https://issues.apache.org/jira/browse/CASSANDRA-2016 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Stephen Connolly Priority: Blocker src/java/org/apache/cassandra/utils/BloomFilterSerializer.java src/java/org/apache/cassandra/utils/LegacyBloomFilterSerializer.java src/java/org/apache/cassandra/service/RepairCallback.java src/java/org/apache/cassandra/io/util/ColumnSortedMap.java are all missing license headers... ASLv2 I assume -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2015) Propagation of schema changes got out of sync with node's notion of ring
[ https://issues.apache.org/jira/browse/CASSANDRA-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984194#action_12984194 ] Peter Schuller commented on CASSANDRA-2015: --- I now believe this was triggered by concurrent migrations (due to a test doing drop/create quickly, and using a hector client pointed to a cluster instead of a single machine). I have not confirmed, but I am definitely able to trigger a similar symptom by submitting 'create keyspace conflict;' more or less concurrently on two nodes at the same time using cassandra-cli. One of the loads is permanently no longer getting schema migrations, even after restart. So, until I know otherwise I'll consider this operator error, and since it is known that concurrent migrations are not supported/allowed, it is not a bug. (Diagnosis mechanisms may be improved, and recovery instructions written, but that is a separate concern.) > Propagation of schema changes got out of sync with node's notion of ring > > > Key: CASSANDRA-2015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2015 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Peter Schuller > > I have a test cluster of 0.7.0 of three nodes, 1, 2, 3. 1 and 2 are seeds > (but not 3). > I had a situation where the following was observed: > * Schema changes submitted to node 1 would not propagate to any other node > (observational method: tail syslog and don't see any flushing of system > memtables/etc except on node 1). > * Schema changes submitted to node 2 or 3 would propagate between them, or to > all (not sure which). > * Mutations submitted on node 1 *would* get propagated to node 3. > * All nodes knew of each other and considered themselves up according to > 'nodetool ring'. > * Because node 3 never got schema migrations, writes submitted to node 1 that > got sent to node 3 blocked for extended periods of time on node 1, while > triggering an exception on now 3 because of an invalid cfid in the row > mutation. > * I can not be entirely sure whether just a regular restart would have fixed > the problem. > Unfortunately, I was not aware of the problem until running some unit tests > against the cluster and I cannot say for sure which order the machines were > bootstrapped in. > After initial discovery I switched to manually submitting 'create keyspace > x;' via cassandra-cli on each node (for different ks:es or interleaving > create/drop), and observing results in syslog. > The observations w.r.t. row mutations did not come from the manual test, but > rather from the unit test that failed so there is some chance that there was > a different mode of failure than during my cassandra-cli tests. > Stopping all nodes and wiping data directories and restarting, fixed the > problem and so far I have not been able to trigger it again. I am not sure > whether just restarting the nodes would have fixed it. > It definitely seems like a problem to me that schema changes did not > propagate even though the node (1) node was apparently sufficiently aware of > the other node (3) to sent mutations to it, even if the original problem may > have been due to some kind of operational error. > I'd be interested in hearing speculation of what likely triggers may be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-2015) Propagation of schema changes got out of sync with node's notion of ring
[ https://issues.apache.org/jira/browse/CASSANDRA-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Schuller resolved CASSANDRA-2015. --- Resolution: Invalid > Propagation of schema changes got out of sync with node's notion of ring > > > Key: CASSANDRA-2015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2015 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Peter Schuller > > I have a test cluster of 0.7.0 of three nodes, 1, 2, 3. 1 and 2 are seeds > (but not 3). > I had a situation where the following was observed: > * Schema changes submitted to node 1 would not propagate to any other node > (observational method: tail syslog and don't see any flushing of system > memtables/etc except on node 1). > * Schema changes submitted to node 2 or 3 would propagate between them, or to > all (not sure which). > * Mutations submitted on node 1 *would* get propagated to node 3. > * All nodes knew of each other and considered themselves up according to > 'nodetool ring'. > * Because node 3 never got schema migrations, writes submitted to node 1 that > got sent to node 3 blocked for extended periods of time on node 1, while > triggering an exception on now 3 because of an invalid cfid in the row > mutation. > * I can not be entirely sure whether just a regular restart would have fixed > the problem. > Unfortunately, I was not aware of the problem until running some unit tests > against the cluster and I cannot say for sure which order the machines were > bootstrapped in. > After initial discovery I switched to manually submitting 'create keyspace > x;' via cassandra-cli on each node (for different ks:es or interleaving > create/drop), and observing results in syslog. > The observations w.r.t. row mutations did not come from the manual test, but > rather from the unit test that failed so there is some chance that there was > a different mode of failure than during my cassandra-cli tests. > Stopping all nodes and wiping data directories and restarting, fixed the > problem and so far I have not been able to trigger it again. I am not sure > whether just restarting the nodes would have fixed it. > It definitely seems like a problem to me that schema changes did not > propagate even though the node (1) node was apparently sufficiently aware of > the other node (3) to sent mutations to it, even if the original problem may > have been due to some kind of operational error. > I'd be interested in hearing speculation of what likely triggers may be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2015) Propagation of schema changes got out of sync with node's notion of ring
Propagation of schema changes got out of sync with node's notion of ring Key: CASSANDRA-2015 URL: https://issues.apache.org/jira/browse/CASSANDRA-2015 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Peter Schuller I have a test cluster of 0.7.0 of three nodes, 1, 2, 3. 1 and 2 are seeds (but not 3). I had a situation where the following was observed: * Schema changes submitted to node 1 would not propagate to any other node (observational method: tail syslog and don't see any flushing of system memtables/etc except on node 1). * Schema changes submitted to node 2 or 3 would propagate between them, or to all (not sure which). * Mutations submitted on node 1 *would* get propagated to node 3. * All nodes knew of each other and considered themselves up according to 'nodetool ring'. * Because node 3 never got schema migrations, writes submitted to node 1 that got sent to node 3 blocked for extended periods of time on node 1, while triggering an exception on now 3 because of an invalid cfid in the row mutation. * I can not be entirely sure whether just a regular restart would have fixed the problem. Unfortunately, I was not aware of the problem until running some unit tests against the cluster and I cannot say for sure which order the machines were bootstrapped in. After initial discovery I switched to manually submitting 'create keyspace x;' via cassandra-cli on each node (for different ks:es or interleaving create/drop), and observing results in syslog. The observations w.r.t. row mutations did not come from the manual test, but rather from the unit test that failed so there is some chance that there was a different mode of failure than during my cassandra-cli tests. Stopping all nodes and wiping data directories and restarting, fixed the problem and so far I have not been able to trigger it again. I am not sure whether just restarting the nodes would have fixed it. It definitely seems like a problem to me that schema changes did not propagate even though the node (1) node was apparently sufficiently aware of the other node (3) to sent mutations to it, even if the original problem may have been due to some kind of operational error. I'd be interested in hearing speculation of what likely triggers may be. -- 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 "NodeProbe" by nehalmehta
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "NodeProbe" page has been changed by nehalmehta. http://wiki.apache.org/cassandra/NodeProbe?action=diff&rev1=10&rev2=11 -- }}} The -host argument is required, the -port argument is optional and will default to 8080 if not supplied. + * In 0.7, streams is replaced by netstats. == Ring == The ring command will present node status and an ascii art rendition of the ring, ''as determined by the node being queried.''
[jira] Commented: (CASSANDRA-2006) Serverwide caps on memtable thresholds
[ https://issues.apache.org/jira/browse/CASSANDRA-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984118#action_12984118 ] David Boxenhorn commented on CASSANDRA-2006: The way I see it - and it becomes even more necessary for a multi-tenant configuration - there should be three completely separate levels of configuration. - Column family configuration is based on data and usage characteristics of column families in your application. - Keyspace configuration enables the modularization of your application (and in a multi-tenant environment, you can assign a keyspace to a tenant) - Server configuration is based on the specific hardware limitations of the server. Server configuration takes priority over keyspace configuration which takes priority over application configuration. Looking at if from the inverse perspective: - CF configuration tunes access to your CFs - Keyspace configuration protects one module of your application from problems in the other modules - Server configuration protects the server as a whole from going beyond the limits of its hardware > Serverwide caps on memtable thresholds > -- > > Key: CASSANDRA-2006 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2006 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Stu Hood > Fix For: 0.8 > > > By storing global operation and throughput thresholds, we could eliminate the > "many small memtables" problem caused by having many CFs. The global > threshold would be set in the config file, to allow different classes of > servers to have different values configured. > Operations occurring in the memtable would add to the global counters, in > addition to the memtable-local counters. When a global threshold was > violated, the memtable in the system that was using the largest fraction of > it's local threshold would be flushed. Local thresholds would continue to act > as they always have. > The result would be larger sstables, safer operation with multiple CFs and > per node tuning. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1936) Fit partitioned counter directly into CounterColumn.value
[ https://issues.apache.org/jira/browse/CASSANDRA-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984100#action_12984100 ] Sylvain Lebresne commented on CASSANDRA-1936: - Patch rebased after #2009 > Fit partitioned counter directly into CounterColumn.value > -- > > Key: CASSANDRA-1936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1936 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 0.8 > > Attachments: > 0001-Put-partitioned-counter-directly-in-column-value.patch, > 1936-ALT-0001-lazily-materialize-value.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > The current implementation of CounterColumn keeps both the partitioned > counter and the total value of the counter (that is, the sum of the parts of > the partitioned counter). > This waste space and this requires the code to keep both representation in > sync. This ticket propose to remove the total value from the representation > and to only calculate it when returning the value to the client. > NOTE: this breaks the on-disk file format (for counters) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1936) Fit partitioned counter directly into CounterColumn.value
[ https://issues.apache.org/jira/browse/CASSANDRA-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-1936: Attachment: 0001-Put-partitioned-counter-directly-in-column-value.patch > Fit partitioned counter directly into CounterColumn.value > -- > > Key: CASSANDRA-1936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1936 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 0.8 > > Attachments: > 0001-Put-partitioned-counter-directly-in-column-value.patch, > 1936-ALT-0001-lazily-materialize-value.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > The current implementation of CounterColumn keeps both the partitioned > counter and the total value of the counter (that is, the sum of the parts of > the partitioned counter). > This waste space and this requires the code to keep both representation in > sync. This ticket propose to remove the total value from the representation > and to only calculate it when returning the value to the client. > NOTE: this breaks the on-disk file format (for counters) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
