[jira] [Updated] (CASSANDRA-14696) DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot returns wrong value for size() and incorrectly calculates count

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-14696:
---
Labels: 4.0-pre-rc-bugs  (was: )

>  DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot 
> returns wrong value for size() and incorrectly calculates count
> 
>
> Key: CASSANDRA-14696
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14696
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
>  Labels: 4.0-pre-rc-bugs
> Fix For: 4.0
>
>
> It appears to return the wrong value for no reason. There isn't a single 
> instance in the code base where we use size. There is an internal count that 
> is calculated, but it is calculated over an empty array. 
> Fix both of these bugs and then use the size to only populate read and write 
> latency values used for speculation when there are actual samples being used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14285) Comma at the end of the end of the seed list is interpretated as localhost

[Kurt Greaves (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16605136#comment-16605136
 ] 

Kurt Greaves commented on CASSANDRA-14285:
--

IDK how many people were doing it, or if we do it elsewhere in ccm/our testing, 
but this also means you can't have an empty seed list - which used to resolve 
to localhost. Honestly, that's probably less surprising, especially considering 
it's not documented at the moment, but thought I'd mention it here because it 
surprised me.

FTR, if you're using {{ccm add}}, you now _have_ to specify {{-s}} for at least 
one node. If people think this is annoying or find other issues we can easily 
add to this patch to handle that case.

> Comma at the end of the end of the seed list is interpretated as localhost
> --
>
> Key: CASSANDRA-14285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14285
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Marco
>Assignee: Nicolas Guyomar
>Priority: Minor
> Fix For: 4.0
>
>
> Seeds: '10.1.20.10,10.1.21.10,10.1.22.10,'  cause a flood of the debug log 
> with messages like this one.
> DEBUG [MessagingService-Outgoing-localhost/127.0.0.1-Gossip] 2018-02-28 
> 15:53:57,314 OutboundTcpConnection.java:545 - Unable to connect to 
> localhost/[127.0.0.1|http://127.0.0.1/]
> This code provide by Nicolas Guyomar provide the reason of the issue.
> In SImpleSeedProvider : 
>  
> String[] hosts = "10.1.20.10,10.1.21.10,10.1.22.10,".split(",", -1);
> List seeds = new ArrayList(hosts.length);
> for (String host : hosts)
> {
> System.out.println(InetAddress.getByName(host.trim()));
> }
>  
> output : 
> /[10.1.20.10|http://10.1.20.10/]
> /[10.1.21.10|http://10.1.21.10/]
> /[10.1.22.10|http://10.1.22.10/]
> localhost/[127.0.0.1|http://127.0.0.1/]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14693) Follow-up: allow transient node to serve as repair coordinator

[Alex Petrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-14693:

Reviewers: Ariel Weisberg, Blake Eggleston  (was: Blake Eggleston)

> Follow-up: allow transient node to serve as repair coordinator
> --
>
> Key: CASSANDRA-14693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14693
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Minor
>
> Allow transient node to serve as a coordinator. 
> |[trunk|https://github.com/apache/cassandra/pull/257]|[utest|https://circleci.com/gh/ifesdjeen/cassandra/329]|[dtest|https://circleci.com/gh/ifesdjeen/cassandra/330]|[dtest-novnode|https://circleci.com/gh/ifesdjeen/cassandra/328]|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14696) DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot returns wrong value for size() and incorrectly calculates count

[Ariel Weisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604998#comment-16604998
 ] 

Ariel Weisberg commented on CASSANDRA-14696:


This is used to fix a more general issue with read and write latency tracking 
where when we have no data we end up using 0 as the value for speculation 
timeouts. This is different from using the default (1/2 the timeout) or the 
value from back when we had data.

>  DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot 
> returns wrong value for size() and incorrectly calculates count
> 
>
> Key: CASSANDRA-14696
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14696
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> It appears to return the wrong value for no reason. There isn't a single 
> instance in the code base where we use size. There is an internal count that 
> is calculated, but it is calculated over an empty array. 
> Fix both of these bugs and then use the size to only populate read and write 
> latency values used for speculation when there are actual samples being used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14696) DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot returns wrong value for size() and incorrectly calculates count

[Ariel Weisberg (JIRA)]

Ariel Weisberg created CASSANDRA-14696:
--

 Summary:  
DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot returns 
wrong value for size() and incorrectly calculates count
 Key: CASSANDRA-14696
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14696
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Ariel Weisberg
Assignee: Ariel Weisberg
 Fix For: 4.0


It appears to return the wrong value for no reason. There isn't a single 
instance in the code base where we use size. There is an internal count that is 
calculated, but it is calculated over an empty array. 

Fix both of these bugs and then use the size to only populate read and write 
latency values used for speculation when there are actual samples being used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14695) preview repair should correctly handle transient ranges

[Blake Eggleston (JIRA)]

Blake Eggleston created CASSANDRA-14695:
---

 Summary: preview repair should correctly handle transient ranges
 Key: CASSANDRA-14695
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14695
 Project: Cassandra
  Issue Type: Bug
  Components: 4.0
Reporter: Blake Eggleston
Assignee: Blake Eggleston


Preview repairs don't exclude transient replicas when validating repaired data. 
This will cause validation repairs on transient keyspaces to always report 
inconsistency



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14694) add latency sample for speculative read repair writes

[Blake Eggleston (JIRA)]

Blake Eggleston created CASSANDRA-14694:
---

 Summary: add latency sample for speculative read repair writes
 Key: CASSANDRA-14694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14694
 Project: Cassandra
  Issue Type: Bug
Reporter: Blake Eggleston
Assignee: Blake Eggleston
 Fix For: 4.0


Speculative read repair mutations shouldn't use read latencies to determine 
when to send a speculative mutation. It should have it's own value based on 
mutation latencies.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14689) Add developer docs for creating releases

[Michael Shuler (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604803#comment-16604803
 ] 

Michael Shuler commented on CASSANDRA-14689:


+1 to merge. Thanks for working on this. I'll try out the main differences of 
svn commit of artifacts to dev, then the svn mv on the next round, then we can 
see how that works out.

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14145) Detecting data resurrection during read

[Sam Tunnicliffe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-14145:

   Resolution: Fixed
Fix Version/s: (was: 4.x)
   4.0
   Status: Resolved  (was: Ready to Commit)

Thanks all, committed to trunk in {{5fbb938adaafd91e7bea1672f09a03c7ac5b9b9d}}

>  Detecting data resurrection during read
> 
>
> Key: CASSANDRA-14145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14145
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 4.0
>
>
> We have seen several bugs in which deleted data gets resurrected. We should 
> try to see if we can detect this on the read path and possibly fix it. Here 
> are a few examples which brought back data
> A replica lost an sstable on startup which caused one replica to lose the 
> tombstone and not the data. This tombstone was past gc grace which means this 
> could resurrect data. We can detect such invalid states by looking at other 
> replicas. 
> If we are running incremental repair, Cassandra will keep repaired and 
> non-repaired data separate. Every-time incremental repair will run, it will 
> move the data from non-repaired to repaired. Repaired data across all 
> replicas should be 100% consistent. 
> Here is an example of how we can detect and mitigate the issue in most cases. 
> Say we have 3 machines, A,B and C. All these machines will have data split 
> b/w repaired and non-repaired. 
> 1. Machine A due to some bug bring backs data D. This data D is in repaired 
> dataset. All other replicas will have data D and tombstone T 
> 2. Read for data D comes from application which involve replicas A and B. The 
> data being read involves data which is in repaired state.  A will respond 
> back to co-ordinator with data D and B will send nothing as tombstone is past 
> gc grace. This will cause digest mismatch. 
> 3. This patch will only kick in when there is a digest mismatch. Co-ordinator 
> will ask both replicas to send back all data like we do today but with this 
> patch, replicas will respond back what data it is returning is coming from 
> repaired vs non-repaired. If data coming from repaired does not match, we 
> know there is a something wrong!! At this time, co-ordinator cannot determine 
> if replica A has resurrected some data or replica B has lost some data. We 
> can still log error in the logs saying we hit an invalid state.
> 4. Besides the log, we can take this further and even correct the response to 
> the query. After logging an invalid state, we can ask replica A and B (and 
> also C if alive) to send back all data for this including gcable tombstones. 
> If any machine returns a tombstone which is after this data, we know we 
> cannot return this data. This way we can avoid returning data which has been 
> deleted. 
> Some Challenges with this 
> 1. When data will be moved from non-repaired to repaired, there could be a 
> race here. We can look at which incremental repairs have promoted things on 
> which replica to avoid false positives.  
> 2. If the third replica is down and live replica does not have any tombstone, 
> we wont be able to break the tie in deciding whether data was actually 
> deleted or resurrected. 
> 3. If the read is for latest data only, we wont be able to detect it as the 
> read will be served from non-repaired data. 
> 4. If the replica where we lose a tombstone is the last replica to compact 
> the tombstone, we wont be able to decide if data is coming back or rest of 
> the replicas has lost that data. But we will still detect something is wrong. 
> 5. We wont affect 99.9% of the read queries as we only do extra work during 
> digest mismatch.
> 6. CL.ONE reads will not be able to detect this. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[1/2] cassandra git commit: Detect inconsistencies in repaired data on the read path

[samt]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 744973e4c -> 5fbb938ad


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5fbb938a/src/java/org/apache/cassandra/service/reads/repair/RepairedDataVerifier.java
--
diff --git 
a/src/java/org/apache/cassandra/service/reads/repair/RepairedDataVerifier.java 
b/src/java/org/apache/cassandra/service/reads/repair/RepairedDataVerifier.java
new file mode 100644
index 000..816fe9f
--- /dev/null
+++ 
b/src/java/org/apache/cassandra/service/reads/repair/RepairedDataVerifier.java
@@ -0,0 +1,95 @@
+/*
+ * 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.
+ */
+
+package org.apache.cassandra.service.reads.repair;
+
+import java.util.concurrent.TimeUnit;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.db.ColumnFamilyStore;
+import org.apache.cassandra.db.PartitionRangeReadCommand;
+import org.apache.cassandra.db.ReadCommand;
+import org.apache.cassandra.db.SinglePartitionReadCommand;
+import org.apache.cassandra.metrics.TableMetrics;
+import org.apache.cassandra.tracing.Tracing;
+import org.apache.cassandra.utils.NoSpamLogger;
+
+public interface RepairedDataVerifier
+{
+public void verify(RepairedDataTracker tracker);
+
+static RepairedDataVerifier simple(ReadCommand command)
+{
+return new SimpleVerifier(command);
+}
+
+static class SimpleVerifier implements RepairedDataVerifier
+{
+private static final Logger logger = 
LoggerFactory.getLogger(SimpleVerifier.class);
+private final ReadCommand command;
+
+private static final String INCONSISTENCY_WARNING = "Detected mismatch 
between repaired datasets for table {}.{} during read of {}. {}";
+
+SimpleVerifier(ReadCommand command)
+{
+this.command = command;
+}
+
+@Override
+public void verify(RepairedDataTracker tracker)
+{
+Tracing.trace("Verifying repaired data tracker {}", tracker);
+
+// some mismatch occurred between the repaired datasets on the 
replicas
+if (tracker.digests.keySet().size() > 1)
+{
+// if any of the digests should be considered inconclusive, 
because there were
+// pending repair sessions which had not yet been committed or 
unrepaired partition
+// deletes which meant some sstables were skipped during 
reads, mark the inconsistency
+// as confirmed
+if (tracker.inconclusiveDigests.isEmpty())
+{
+TableMetrics metrics = 
ColumnFamilyStore.metricsFor(command.metadata().id);
+metrics.confirmedRepairedInconsistencies.mark();
+NoSpamLogger.log(logger, NoSpamLogger.Level.WARN, 1, 
TimeUnit.MINUTES,
+ INCONSISTENCY_WARNING, 
command.metadata().keyspace,
+ command.metadata().name, 
getCommandString(), tracker);
+}
+else if 
(DatabaseDescriptor.reportUnconfirmedRepairedDataMismatches())
+{
+TableMetrics metrics = 
ColumnFamilyStore.metricsFor(command.metadata().id);
+metrics.unconfirmedRepairedInconsistencies.mark();
+NoSpamLogger.log(logger, NoSpamLogger.Level.WARN, 1, 
TimeUnit.MINUTES,
+ INCONSISTENCY_WARNING, 
command.metadata().keyspace,
+ command.metadata().name, 
getCommandString(), tracker);
+}
+}
+}
+
+private String getCommandString()
+{
+return command instanceof SinglePartitionReadCommand
+   ? 
((SinglePartitionReadCommand)command).partitionKey().toString()
+   : 
((PartitionRangeReadCommand)command).dataRange().keyRange().getString(command.metadata().partitionKeyType);
+
+}
+}
+}

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5fbb938a/test/unit/org/apache/cassandra/db/ReadCommandTest.java

[2/2] cassandra git commit: Detect inconsistencies in repaired data on the read path

[samt]

Detect inconsistencies in repaired data on the read path

Patch by Sam Tunnicliffe; reviewed by Marcus Eriksson and Jordan West for 
CASSANDRA-14145


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5fbb938a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5fbb938a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5fbb938a

Branch: refs/heads/trunk
Commit: 5fbb938adaafd91e7bea1672f09a03c7ac5b9b9d
Parents: 744973e
Author: Sam Tunnicliffe 
Authored: Wed May 9 18:57:30 2018 +0100
Committer: Sam Tunnicliffe 
Committed: Wed Sep 5 19:07:12 2018 +0100

--
 CHANGES.txt |   1 +
 conf/cassandra.yaml |  18 +
 .../org/apache/cassandra/config/Config.java |  20 +
 .../cassandra/config/DatabaseDescriptor.java|  29 ++
 .../cassandra/db/PartitionRangeReadCommand.java |  33 +-
 .../org/apache/cassandra/db/ReadCommand.java| 346 +-
 .../cassandra/db/ReadCommandVerbHandler.java|   4 +
 .../org/apache/cassandra/db/ReadResponse.java   | 123 ++-
 .../db/SinglePartitionReadCommand.java  |  60 +--
 .../db/filter/ClusteringIndexNamesFilter.java   |  14 +
 .../db/rows/UnfilteredRowIterators.java |   1 +
 .../cassandra/metrics/KeyspaceMetrics.java  |  22 ++
 .../apache/cassandra/metrics/TableMetrics.java  |  50 +++
 .../org/apache/cassandra/net/ParameterType.java |   3 +-
 .../repair/consistent/LocalSessions.java|  17 +
 .../apache/cassandra/service/StorageProxy.java  |  76 +++-
 .../cassandra/service/StorageProxyMBean.java|  15 +
 .../cassandra/service/reads/DataResolver.java   |  44 ++-
 .../service/reads/ShortReadProtection.java  |   1 +
 .../reads/repair/AbstractReadRepair.java|  21 +-
 .../reads/repair/RepairedDataTracker.java   |  87 +
 .../reads/repair/RepairedDataVerifier.java  |  95 +
 .../apache/cassandra/db/ReadCommandTest.java| 287 ++-
 .../db/ReadCommandVerbHandlerTest.java  | 171 +
 .../apache/cassandra/db/ReadResponseTest.java   | 261 +
 .../service/reads/AbstractReadResponseTest.java |  32 +-
 .../service/reads/DataResolverTest.java | 363 +++
 .../reads/repair/BlockingReadRepairTest.java|   4 +-
 .../DiagEventsBlockingReadRepairTest.java   |   2 +-
 .../reads/repair/ReadOnlyReadRepairTest.java|   5 +-
 .../reads/repair/RepairedDataVerifierTest.java  | 291 +++
 31 files changed, 2399 insertions(+), 97 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5fbb938a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 301f97f..5cfc7ab 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Detect inconsistencies in repaired data on the read path (CASSANDRA-14145)
  * Add checksumming to the native protocol (CASSANDRA-13304)
  * Make AuthCache more easily extendable (CASSANDRA-14662)
  * Extend RolesCache to include detailed role info (CASSANDRA-14497)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5fbb938a/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 995a520..190ce77 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1238,3 +1238,21 @@ diagnostic_events_enabled: false
 # Define use of legacy delayed flusher for replies to TCP connections. This 
will increase latency, but might be beneficial for
 # legacy use-cases where only a single connection is used for each Cassandra 
node. Default is false.
 #native_transport_flush_in_batches_legacy: false
+
+# Enable tracking of repaired state of data during reads and comparison 
between replicas
+# Mismatches between the repaired sets of replicas can be characterized as 
either confirmed
+# or unconfirmed. In this context, unconfirmed indicates that the presence of 
pending repair
+# sessions, unrepaired partition tombstones, or some other condition means 
that the disparity
+# cannot be considered conclusive. Confirmed mismatches should be a trigger 
for investigation
+# as they may be indicative of corruption or data loss.
+# There are separate flags for range vs partition reads as single partition 
reads are only tracked
+# when CL > 1 and a digest mismatch occurs. Currently, range queries don't use 
digests so if
+# enabled for range reads, all range reads will include repaired data 
tracking. As this adds
+# some overhead, operators may wish to disable it whilst still enabling it for 
partition reads
+repaired_data_tracking_for_range_reads_enabled: false
+repaired_data_tracking_for_partition_reads_enabled: false
+# If false, only confirmed mismatches will be reported. If 

[jira] [Updated] (CASSANDRA-14693) Follow-up: allow transient node to serve as repair coordinator

[Alex Petrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-14693:

  Reviewers: Blake Eggleston
Description: 
Allow transient node to serve as a coordinator. 

|[trunk|https://github.com/apache/cassandra/pull/257]|[utest|https://circleci.com/gh/ifesdjeen/cassandra/329]|[dtest|https://circleci.com/gh/ifesdjeen/cassandra/330]|[dtest-novnode|https://circleci.com/gh/ifesdjeen/cassandra/328]|

  was:Allow transient node to serve as a coordinator


> Follow-up: allow transient node to serve as repair coordinator
> --
>
> Key: CASSANDRA-14693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14693
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Minor
>
> Allow transient node to serve as a coordinator. 
> |[trunk|https://github.com/apache/cassandra/pull/257]|[utest|https://circleci.com/gh/ifesdjeen/cassandra/329]|[dtest|https://circleci.com/gh/ifesdjeen/cassandra/330]|[dtest-novnode|https://circleci.com/gh/ifesdjeen/cassandra/328]|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (CASSANDRA-14693) Follow-up: allow transient node to serve as repair coordinator

[Alex Petrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov reassigned CASSANDRA-14693:
---

Assignee: Alex Petrov

> Follow-up: allow transient node to serve as repair coordinator
> --
>
> Key: CASSANDRA-14693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14693
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Minor
>
> Allow transient node to serve as a coordinator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14693) Follow-up: allow transient node to serve as repair coordinator

[Alex Petrov (JIRA)]

Alex Petrov created CASSANDRA-14693:
---

 Summary: Follow-up: allow transient node to serve as repair 
coordinator
 Key: CASSANDRA-14693
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14693
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Alex Petrov


Allow transient node to serve as a coordinator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14690) Add dtests for fqltool replay/compare

[Jeremy Hanna (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-14690:
-
Labels: fqltool  (was: )

> Add dtests for fqltool replay/compare
> -
>
> Key: CASSANDRA-14690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14690
> Project: Cassandra
>  Issue Type: Test
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
>  Labels: fqltool
>
> We should add some basic round-trip dtests for {{fqltool replay}} and 
> {{compare}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14692) join_ring=false populates wrong value into StorageServiceMB and prevents join by nodetool

[Roland Johann (JIRA)]

Roland Johann created CASSANDRA-14692:
-

 Summary: join_ring=false populates wrong value into 
StorageServiceMB and prevents join by nodetool
 Key: CASSANDRA-14692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14692
 Project: Cassandra
  Issue Type: Bug
  Components: Lifecycle
Reporter: Roland Johann
 Fix For: 3.11.3
 Attachments: Bildschirmfoto 2018-09-05 um 17.29.54.png, 
cassandra1_log, cassandra1_nodetool_gossipinfo, cassandra1_nodetool_status, 
cassandra2_nodetool_gossipinfo, cassandra2_nodetool_status

Restarting a cassandra cluster member with option 
{{-Dcassandra.join_ring=false}} populates wrong value to its 
{{StorageServiceMB}} field {{Joined}} which causes the actual trigger to join 
via {{nodetool join}} to abort due to check if {{Join}} in {{StorageServiceMB}} 
is true. Via jconsole it's possible as there is no check.

https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/Join.java

{{nodetool status}} also shows that the node is up and in normal node, on the 
rest of the cluster node status is  {{DN}}. 

{{nodetool gossipinfo}} states that the non joined node is in gossip state 
{{hibernate}}.

Came across this issue while evaluated the problem of zombies to integrate into 
automation processes and the documentation states
{quote}To avoid this problem, run {{nodetool repair}} on any restored node 
before rejoining it to its cluster. 
{quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14647) Reading cardinality from Statistics.db failed

[Vitali Djatsuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604491#comment-16604491
 ] 

Vitali Djatsuk commented on CASSANDRA-14647:


Tested again, and there are no more warning in the log for the whole day. 
Turned out that monitoring system is querying all keys via jmx and then filters 
them based on the configuration file.

> Reading cardinality from Statistics.db failed
> -
>
> Key: CASSANDRA-14647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14647
> Project: Cassandra
>  Issue Type: Bug
>  Components: Metrics
> Environment: Clients are doing only writes with Local One, cluster 
> consist of 3 regions with RF3.
> Storage is configured wth jbod/XFS on 10 x 1Tb disks
> IOPS limit for each disk 500 (total 5000 iops)
> Bandwith for each disk 60mb/s (600 total)
> OS is Debian linux.
>Reporter: Vitali Djatsuk
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: cassandra_compaction_pending_tasks_7days.png
>
>
> There is some issue with sstable metadata which is visible in system.log, the 
> messages says:
> {noformat}
> WARN  [Thread-6] 2018-07-25 07:12:47,928 SSTableReader.java:249 - Reading 
> cardinality from Statistics.db failed for 
> /opt/data/disk5/data/keyspace/table/mc-big-Data.db.{noformat}
> Although there is no such file. 
> The message has appeared after i've changed the compaction strategy from 
> SizeTiered to Leveled. Compaction strategy has been changed region by region 
> (total 3 regions) and it has coincided with the double client write traffic 
> increase.
>  I have tried to run nodetool scrub to rebuilt the sstable, but that does not 
> fix the issue.
> So very hard to define the steps to reproduce, probably it will be:
>  # run stress tool with write traffic
>  # under load change compaction strategy from SireTiered to Leveled for the 
> bunch of hosts
>  # add more write traffic
> Reading the code it is said that if this metadata is broken, then "estimating 
> the keys will be done using index summary". 
>  
> [https://github.com/apache/cassandra/blob/cassandra-3.0.17/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L247]
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14691) Cassandra 2.1 backport - The JVM should exit if jmx fails to bind

[Thomas Steinmaurer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604394#comment-16604394
 ] 

Thomas Steinmaurer edited comment on CASSANDRA-14691 at 9/5/18 1:22 PM:


As discussed with [~KurtG] in Cassandra user list, opened a clone of 
CASSANDRA-11540 for a 2.1 backport as the change seems to be simple + this all 
could be a source for corruption.
{noformat}
ERROR [main] 2018-08-05 21:10:24,046 CassandraDaemon.java:120 - Error starting 
local jmx server: 
java.rmi.server.ExportException: Port already in use: 7199; nested exception 
is: 
java.net.BindException: Address already in use (Bind failed)
…
 
But then continuing with stuff like opening system and even user tables:
 
INFO  [main] 2018-08-05 21:10:24,060 CacheService.java:110 - Initializing key 
cache with capacity of 100 MBs.
INFO  [main] 2018-08-05 21:10:24,067 CacheService.java:132 - Initializing row 
cache with capacity of 0 MBs
INFO  [main] 2018-08-05 21:10:24,073 CacheService.java:149 - Initializing 
counter cache with capacity of 50 MBs
INFO  [main] 2018-08-05 21:10:24,074 CacheService.java:160 - Scheduling counter 
cache save to every 7200 seconds (going to save all keys).
INFO  [main] 2018-08-05 21:10:24,161 ColumnFamilyStore.java:365 - Initializing 
system.sstable_activity
INFO  [SSTableBatchOpen:2] 2018-08-05 21:10:24,692 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/system-sstable_activity-ka-165
 (2023 bytes)
INFO  [SSTableBatchOpen:3] 2018-08-05 21:10:24,692 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/system-sstable_activity-ka-167
 (2336 bytes)
INFO  [SSTableBatchOpen:1] 2018-08-05 21:10:24,692 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/system-sstable_activity-ka-166
 (2686 bytes)
INFO  [main] 2018-08-05 21:10:24,755 ColumnFamilyStore.java:365 - Initializing 
system.hints
INFO  [SSTableBatchOpen:1] 2018-08-05 21:10:24,758 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-377
 (46210621 bytes)
INFO  [main] 2018-08-05 21:10:24,766 ColumnFamilyStore.java:365 - Initializing 
system.compaction_history
INFO  [SSTableBatchOpen:1] 2018-08-05 21:10:24,768 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/system-compaction_history-ka-129
 (91269 bytes)
…
 
Replaying commit logs:
 
…
INFO  [main] 2018-08-05 21:10:25,896 CommitLogReplayer.java:267 - Replaying 
/var/opt/xxx-managed/cassandra/commitlog/CommitLog-4-1533133668366.log
INFO  [main] 2018-08-05 21:10:25,896 CommitLogReplayer.java:270 - Replaying 
/var/opt/xxx-managed/cassandra/commitlog/CommitLog-4-1533133668366.log (CL 
version 4, messaging version 8)
…
 
Even writing memtables already (below just pasted system tables, but also user 
tables):
 
…
INFO  [MemtableFlushWriter:4] 2018-08-05 21:11:52,524 Memtable.java:347 - 
Writing Memtable-size_estimates@1941663179(2.655MiB serialized bytes, 325710 
ops, 2%/0% of on/off-heap limit)
INFO  [MemtableFlushWriter:3] 2018-08-05 21:11:52,552 Memtable.java:347 - 
Writing Memtable-peer_events@1474667699(0.199KiB serialized bytes, 4 ops, 0%/0% 
of on/off-heap limit)
…
 
Until it comes to a point where it can’t bind ports like the storage port 7000:
 
ERROR [main] 2018-08-05 21:11:54,350 CassandraDaemon.java:395 - Fatal 
configuration error
org.apache.cassandra.exceptions.ConfigurationException: /XXX:7000 is in use by 
another process.  Change listen_address:storage_port in cassandra.yaml to 
values that do not conflict with other services
at 
org.apache.cassandra.net.MessagingService.getServerSockets(MessagingService.java:495)
 ~[apache-cassandra-2.1.18.jar:2.1.18]
…
 
Until Cassandra stops:
 
…
INFO  [StorageServiceShutdownHook] 2018-08-05 21:11:54,361 Gossiper.java:1454 - 
Announcing shutdown
…
 
 
So, we have around 2 minutes where Cassandra is mangling with existing data, 
although it shouldn’t.
 
Sounds like a potential candidate for data corruption, right? E.g. later on we 
then see things like (still while being in progress to shutdown?):
 
WARN  [SharedPool-Worker-1] 2018-08-05 21:11:58,181 
AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.io.FileNotFoundException: 
/var/opt/xxx-managed/cassandra/xxx/xxx-fdc68b70950611e8ad7179f2d5bfa3cf/xxx-xxx-ka-15-Data.db
 (No such file or directory)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:52)
 ~[apache-cassandra-2.1.18.jar:2.1.18]
at 

[jira] [Commented] (CASSANDRA-14691) Cassandra 2.1 backport - The JVM should exit if jmx fails to bind

[Thomas Steinmaurer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604394#comment-16604394
 ] 

Thomas Steinmaurer commented on CASSANDRA-14691:


Could be a source for corruption.
{noformat}
ERROR [main] 2018-08-05 21:10:24,046 CassandraDaemon.java:120 - Error starting 
local jmx server: 
java.rmi.server.ExportException: Port already in use: 7199; nested exception 
is: 
java.net.BindException: Address already in use (Bind failed)
…
 
But then continuing with stuff like opening system and even user tables:
 
INFO  [main] 2018-08-05 21:10:24,060 CacheService.java:110 - Initializing key 
cache with capacity of 100 MBs.
INFO  [main] 2018-08-05 21:10:24,067 CacheService.java:132 - Initializing row 
cache with capacity of 0 MBs
INFO  [main] 2018-08-05 21:10:24,073 CacheService.java:149 - Initializing 
counter cache with capacity of 50 MBs
INFO  [main] 2018-08-05 21:10:24,074 CacheService.java:160 - Scheduling counter 
cache save to every 7200 seconds (going to save all keys).
INFO  [main] 2018-08-05 21:10:24,161 ColumnFamilyStore.java:365 - Initializing 
system.sstable_activity
INFO  [SSTableBatchOpen:2] 2018-08-05 21:10:24,692 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/system-sstable_activity-ka-165
 (2023 bytes)
INFO  [SSTableBatchOpen:3] 2018-08-05 21:10:24,692 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/system-sstable_activity-ka-167
 (2336 bytes)
INFO  [SSTableBatchOpen:1] 2018-08-05 21:10:24,692 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/system-sstable_activity-ka-166
 (2686 bytes)
INFO  [main] 2018-08-05 21:10:24,755 ColumnFamilyStore.java:365 - Initializing 
system.hints
INFO  [SSTableBatchOpen:1] 2018-08-05 21:10:24,758 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-377
 (46210621 bytes)
INFO  [main] 2018-08-05 21:10:24,766 ColumnFamilyStore.java:365 - Initializing 
system.compaction_history
INFO  [SSTableBatchOpen:1] 2018-08-05 21:10:24,768 SSTableReader.java:475 - 
Opening 
/var/opt/xxx-managed/cassandra/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/system-compaction_history-ka-129
 (91269 bytes)
…
 
Replaying commit logs:
 
…
INFO  [main] 2018-08-05 21:10:25,896 CommitLogReplayer.java:267 - Replaying 
/var/opt/xxx-managed/cassandra/commitlog/CommitLog-4-1533133668366.log
INFO  [main] 2018-08-05 21:10:25,896 CommitLogReplayer.java:270 - Replaying 
/var/opt/xxx-managed/cassandra/commitlog/CommitLog-4-1533133668366.log (CL 
version 4, messaging version 8)
…
 
Even writing memtables already (below just pasted system tables, but also user 
tables):
 
…
INFO  [MemtableFlushWriter:4] 2018-08-05 21:11:52,524 Memtable.java:347 - 
Writing Memtable-size_estimates@1941663179(2.655MiB serialized bytes, 325710 
ops, 2%/0% of on/off-heap limit)
INFO  [MemtableFlushWriter:3] 2018-08-05 21:11:52,552 Memtable.java:347 - 
Writing Memtable-peer_events@1474667699(0.199KiB serialized bytes, 4 ops, 0%/0% 
of on/off-heap limit)
…
 
Until it comes to a point where it can’t bind ports like the storage port 7000:
 
ERROR [main] 2018-08-05 21:11:54,350 CassandraDaemon.java:395 - Fatal 
configuration error
org.apache.cassandra.exceptions.ConfigurationException: /XXX:7000 is in use by 
another process.  Change listen_address:storage_port in cassandra.yaml to 
values that do not conflict with other services
at 
org.apache.cassandra.net.MessagingService.getServerSockets(MessagingService.java:495)
 ~[apache-cassandra-2.1.18.jar:2.1.18]
…
 
Until Cassandra stops:
 
…
INFO  [StorageServiceShutdownHook] 2018-08-05 21:11:54,361 Gossiper.java:1454 - 
Announcing shutdown
…
 
 
So, we have around 2 minutes where Cassandra is mangling with existing data, 
although it shouldn’t.
 
Sounds like a potential candidate for data corruption, right? E.g. later on we 
then see things like (still while being in progress to shutdown?):
 
WARN  [SharedPool-Worker-1] 2018-08-05 21:11:58,181 
AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread 
Thread[SharedPool-Worker-1,5,main]: {}
java.lang.RuntimeException: java.io.FileNotFoundException: 
/var/opt/xxx-managed/cassandra/xxx/xxx-fdc68b70950611e8ad7179f2d5bfa3cf/xxx-xxx-ka-15-Data.db
 (No such file or directory)
at 
org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:52)
 ~[apache-cassandra-2.1.18.jar:2.1.18]
at 
org.apache.cassandra.io.util.CompressedPoolingSegmentedFile.createPooledReader(CompressedPoolingSegmentedFile.java:95)
 ~[apache-cassandra-2.1.18.jar:2.1.18]
at 

[jira] [Updated] (CASSANDRA-14691) Cassandra 2.1 backport - The JVM should exit if jmx fails to bind

[Thomas Steinmaurer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Steinmaurer updated CASSANDRA-14691:
---
Reviewer:   (was: Sam Tunnicliffe)

> Cassandra 2.1 backport - The JVM should exit if jmx fails to bind
> -
>
> Key: CASSANDRA-14691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14691
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
>Assignee: Alex Petrov
>Priority: Major
>  Labels: lhf
> Fix For: 2.1.x
>
>
> If you are already running a cassandra instance, but for some reason try to 
> start another one, this happens:
> {noformat}
> INFO  20:57:09 JNA mlockall successful
> WARN  20:57:09 JMX is not enabled to receive remote connections. Please see 
> cassandra-env.sh for more info.
> ERROR 20:57:10 Error starting local jmx server:
> java.rmi.server.ExportException: Port already in use: 7199; nested exception 
> is:
> java.net.BindException: Address already in use
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) 
> ~[na:1.7.0_76]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:207) 
> ~[na:1.7.0_76]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:122) 
> ~[na:1.7.0_76]
> at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:98) 
> ~[na:1.7.0_76]
> at 
> java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239) 
> ~[na:1.7.0_76]
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:100)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:222) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:653) 
> [main/:na]
> Caused by: java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method) ~[na:1.7.0_76]
> at 
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:376) 
> ~[na:1.7.0_76]
> at java.net.ServerSocket.bind(ServerSocket.java:376) ~[na:1.7.0_76]
> at java.net.ServerSocket.(ServerSocket.java:237) ~[na:1.7.0_76]
> at 
> javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
>  ~[na:1.7.0_76]
> at 
> org.apache.cassandra.utils.RMIServerSocketFactoryImpl.createServerSocket(RMIServerSocketFactoryImpl.java:13)
>  ~[main/:na]
> at 
> sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) 
> ~[na:1.7.0_76]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) 
> ~[na:1.7.0_76]
> ... 11 common frames omitted
> {noformat}
> However the startup continues, and ends up replaying commitlogs, which is 
> probably not a good thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14691) Cassandra 2.1 backport - The JVM should exit if jmx fails to bind

[Thomas Steinmaurer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Steinmaurer updated CASSANDRA-14691:
---
Fix Version/s: (was: 3.0.7)
   (was: 3.7)
   (was: 2.2.7)
   2.1.x

> Cassandra 2.1 backport - The JVM should exit if jmx fails to bind
> -
>
> Key: CASSANDRA-14691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14691
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
>Assignee: Alex Petrov
>Priority: Major
>  Labels: lhf
> Fix For: 2.1.x
>
>
> If you are already running a cassandra instance, but for some reason try to 
> start another one, this happens:
> {noformat}
> INFO  20:57:09 JNA mlockall successful
> WARN  20:57:09 JMX is not enabled to receive remote connections. Please see 
> cassandra-env.sh for more info.
> ERROR 20:57:10 Error starting local jmx server:
> java.rmi.server.ExportException: Port already in use: 7199; nested exception 
> is:
> java.net.BindException: Address already in use
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) 
> ~[na:1.7.0_76]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) 
> ~[na:1.7.0_76]
> at 
> sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:207) 
> ~[na:1.7.0_76]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:122) 
> ~[na:1.7.0_76]
> at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:98) 
> ~[na:1.7.0_76]
> at 
> java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239) 
> ~[na:1.7.0_76]
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:100)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:222) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:653) 
> [main/:na]
> Caused by: java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method) ~[na:1.7.0_76]
> at 
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:376) 
> ~[na:1.7.0_76]
> at java.net.ServerSocket.bind(ServerSocket.java:376) ~[na:1.7.0_76]
> at java.net.ServerSocket.(ServerSocket.java:237) ~[na:1.7.0_76]
> at 
> javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
>  ~[na:1.7.0_76]
> at 
> org.apache.cassandra.utils.RMIServerSocketFactoryImpl.createServerSocket(RMIServerSocketFactoryImpl.java:13)
>  ~[main/:na]
> at 
> sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) 
> ~[na:1.7.0_76]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) 
> ~[na:1.7.0_76]
> ... 11 common frames omitted
> {noformat}
> However the startup continues, and ends up replaying commitlogs, which is 
> probably not a good thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14691) Cassandra 2.1 backport - The JVM should exit if jmx fails to bind

[Thomas Steinmaurer (JIRA)]

Thomas Steinmaurer created CASSANDRA-14691:
--

 Summary: Cassandra 2.1 backport - The JVM should exit if jmx fails 
to bind
 Key: CASSANDRA-14691
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14691
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Thomas Steinmaurer
Assignee: Alex Petrov
 Fix For: 2.2.7, 3.0.7, 3.7


If you are already running a cassandra instance, but for some reason try to 
start another one, this happens:

{noformat}
INFO  20:57:09 JNA mlockall successful
WARN  20:57:09 JMX is not enabled to receive remote connections. Please see 
cassandra-env.sh for more info.
ERROR 20:57:10 Error starting local jmx server:
java.rmi.server.ExportException: Port already in use: 7199; nested exception is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) 
~[na:1.7.0_76]
at 
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) 
~[na:1.7.0_76]
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) 
~[na:1.7.0_76]
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) 
~[na:1.7.0_76]
at 
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:207) 
~[na:1.7.0_76]
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:122) 
~[na:1.7.0_76]
at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:98) 
~[na:1.7.0_76]
at 
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239) 
~[na:1.7.0_76]
at 
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:100)
 [main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:222) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:653) 
[main/:na]
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method) ~[na:1.7.0_76]
at 
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:376) 
~[na:1.7.0_76]
at java.net.ServerSocket.bind(ServerSocket.java:376) ~[na:1.7.0_76]
at java.net.ServerSocket.(ServerSocket.java:237) ~[na:1.7.0_76]
at 
javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
 ~[na:1.7.0_76]
at 
org.apache.cassandra.utils.RMIServerSocketFactoryImpl.createServerSocket(RMIServerSocketFactoryImpl.java:13)
 ~[main/:na]
at 
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) 
~[na:1.7.0_76]
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) 
~[na:1.7.0_76]
... 11 common frames omitted
{noformat}

However the startup continues, and ends up replaying commitlogs, which is 
probably not a good thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14657) Handle failures in upgradesstables/cleanup/relocate

[Marcus Eriksson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604358#comment-16604358
 ] 

Marcus Eriksson commented on CASSANDRA-14657:
-

and dtest to reproduce: 
https://github.com/krummas/cassandra-dtest/commits/marcuse/14657

> Handle failures in upgradesstables/cleanup/relocate
> ---
>
> Key: CASSANDRA-14657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14657
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> If a compaction in {{parallelAllSSTableOperation}} throws exception, all 
> current transactions are closed, this can make us close a transaction that 
> has not yet finished (since we can run many of these compactions in 
> parallel). This causes this error:
> {code}
> java.lang.IllegalStateException: Cannot prepare to commit unless IN_PROGRESS; 
> state is ABORTED
> {code}
> and this can get the leveled manifest (if running LCS) in a bad state causing 
> this error message:
> {code}
> Could not acquire references for compacting SSTables ...
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14683) Pagestate is null after 2^31 rows

[Sylvain Lebresne (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604239#comment-16604239
 ] 

Sylvain Lebresne commented on CASSANDRA-14683:
--

Thinking about this, while we certainly should up/remove the limit supported 
for this, I think the sub-part that really matter the most here is solving the 
case of queries without no limit at all, which doesn't require increasing the 
resolution of the limit in the {{PagingState}}, at least not in theory.

In fact, it might be worth fixing that case in 3.x as well, which I think we 
can do by starting to interpret {{Integer.MAX_VALUE}} as "no limit". That is, 
all we'd change here is that when a new page request has {{Integer.MAX_VALUE}} 
as {{remaining}} in his {{PagingState}}, we'll execute the query exactly like 
today, but we'll simply make sure that the newly returned {{PagingState}} still 
has {{Integer.MAX_VALUE}} as {{remaining}}.

I'll note that this would strictly speaking break backward compatibility in the 
sense that if some user was using {{Integer.MAX_VALUE}} as concrete user LIMIT 
*expecting* the query to not return anymore rows, we would now return more rows 
after this change. It's a wacky enough case that it's imo worth breaking so the 
*much* more common case of "I want all my rows" actually works.


> Pagestate is null after 2^31 rows
> -
>
> Key: CASSANDRA-14683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14683
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Abhishek
>Priority: Major
>
> I am using the nodejs driver to take a dump of my table via 
> [pagination|http://datastax.github.io/nodejs-driver/features/paging/#manual-paging]
>  for a simple query.
> My query is \{{select * from mytable}}
> The table has close to 4 billion rows and cassandra stops returning results 
> exactly after 2147483647 rows. The pagestate is not returned after this.
> Cassandra version - 3.0.9
> Nodejs cassandra driver version - 3.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mck updated CASSANDRA-14689:

Status: Patch Available  (was: In Progress)

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14406) Transient Replication: Implement cheap quorum write optimizations

[Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602945#comment-16602945
 ] 

Benedict edited comment on CASSANDRA-14406 at 9/5/18 9:14 AM:
--

Fixes:
 # StorageProxy.mutate would have attempted a standardWritePerformer 
maybeTryAdditionalReplicas for counters
 # assureSufficientLiveReplicas and blockFor were not transient replication (or 
pending replicas) aware
 ** in the case of transient replication, this would mean we did not send 
enough initial writes, because we capped ourselves to blockFor recipients
 # AbstractWriteResponseHandler
 ** was sending to all remaining replicas in case of failure to meet 
consistency, not only those relevant for consistency
 ** hasTransientResponse was racy - could have a transient response arrive 
after checking condition
 *** Have introduced {{Accumulator.snapshot}} to make working with it safely 
more obvious
 *** We take a snapshot, and look inside the list to decide if we have a 
transient response
 # sendMessagesToNonLocalDC was asserting no transient replicas - simply 
removed the assertions, as logic is consistent
 # Hints were not implemented, but mostly involved filtering them out; batch 
log will be less trivial when implemented, as currently must hint
# On write, we were filtering {{pending}} replicas to only full ones, which 
would have broken our consistency guarantees
 # This patch was also affected by [transient<->full ring ownership 
movements|https://issues.apache.org/jira/browse/CASSANDRA-14409?focusedCommentId=16602977=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16602977]
 # Introduced separate threshold for cheap quorum upgrades
 # There was a rare possible race condition when removing transient replication 
from a keyspace, during which period we would not handle transient replicas 
correctly

Nits:
 # StorageProxy.mutate used a HashMap, when a List would suffice

Follow-ups pre-4.0:
 # We should rename speculative_write_threshold (I thought we agreed on 
transient_write_threshold)?

Follow-ups:
 # EACH_QUORUM not implemented for transient replication; must either error or 
implement before release
 # we don’t limit our cheap quorum upgrade to the minimum number of additional 
transient replicas, so a single missing response will result in all DCs 
receiving an extra full write mutation, doubling cross-dc traffic for that write
 # maybeTryAdditionalReplicas / sendMessagesToNonLocalDC are not DC aware in 
their interactions, so transient writes incur more cross-DC traffic (ideally, 
the proxies would be able to coordinate upgrading to a transient write)
 # we don’t expose metrics around success/failure of cheap quorum
 # transient write count isn’t incremented when we perform a non-additional 
write (i.e. due to down full node)


was (Author: benedict):
Fixes:
# StorageProxy.mutate would have attempted a standardWritePerformer 
maybeTryAdditionalReplicas for counters 
# assureSufficientLiveReplicas and blockFor were not transient replication (or 
pending replicas) aware
#* in the case of transient replication, this would mean we did not send enough 
initial writes, because we capped ourselves to blockFor recipients
# AbstractWriteResponseHandler
#* was sending to all remaining replicas in case of failure to meet 
consistency, not only those relevant for consistency
#* hasTransientResponse was racy - could have a transient response arrive after 
checking condition
#** Have introduced {{Accumulator.snapshot}} to make working with it safely 
more obvious
#** We take a snapshot, and look inside the list to decide if we have a 
transient response
# sendMessagesToNonLocalDC was asserting no transient replicas - simply removed 
the assertions, as logic is consistent
# Hints were not implemented, but mostly involved filtering them out; batch log 
will be less trivial when implemented, as currently must hint
# Introduced separate threshold for cheap quorum upgrades
# There was a rare possible race condition when removing transient replication 
from a keyspace, during which period we would not handle transient replicas 
correctly

Nits:
# StorageProxy.mutate used a HashMap, when a List would suffice

Follow-ups pre-4.0:
# We should rename speculative_write_threshold (I thought we agreed on 
transient_write_threshold)?

Follow-ups:
# EACH_QUORUM not implemented for transient replication; must either error or 
implement before release
# we don’t limit our cheap quorum upgrade to the minimum number of additional 
transient replicas, so a single missing response will result in all DCs 
receiving an extra full write mutation, doubling cross-dc traffic for that write
# maybeTryAdditionalReplicas / sendMessagesToNonLocalDC are not DC aware in 
their interactions, so transient writes incur more cross-DC traffic (ideally, 
the proxies would be able to coordinate upgrading to a 

[jira] [Updated] (CASSANDRA-14690) Add dtests for fqltool replay/compare

[Marcus Eriksson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-14690:

Status: Patch Available  (was: Open)

dtest: https://github.com/krummas/cassandra-dtest/commits/marcuse/fqltooltest
trunk test run on the new dtest branch: 
https://circleci.com/gh/krummas/cassandra/tree/marcuse%2Ffqltool

> Add dtests for fqltool replay/compare
> -
>
> Key: CASSANDRA-14690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14690
> Project: Cassandra
>  Issue Type: Test
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
>
> We should add some basic round-trip dtests for {{fqltool replay}} and 
> {{compare}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14690) Add dtests for fqltool replay/compare

[Marcus Eriksson (JIRA)]

Marcus Eriksson created CASSANDRA-14690:
---

 Summary: Add dtests for fqltool replay/compare
 Key: CASSANDRA-14690
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14690
 Project: Cassandra
  Issue Type: Test
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson


We should add some basic round-trip dtests for {{fqltool replay}} and 
{{compare}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604034#comment-16604034
 ] 

mck edited comment on CASSANDRA-14689 at 9/5/18 7:28 AM:
-

Pull Request @ https://github.com/apache/cassandra/pull/230


|| branch || CircleCI || 
| 
[trunk|https://github.com/thelastpickle/cassandra/tree/mck/docs--release-process]
 | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fdocs--release-process.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process]
 |

^not like the CircleCi builds check the website build, but one can dream…


was (Author: michaelsembwever):
Pull Request @ https://github.com/apache/cassandra/pull/230


|| branch || CircleCI || 
| 
[trunk|https://github.com/thelastpickle/cassandra/tree/mck/docs--release-process]
 | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fdocs--release-process.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process]
 |

^not like the CircleCi builds checks the website build, but one can dream…

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604034#comment-16604034
 ] 

mck edited comment on CASSANDRA-14689 at 9/5/18 7:28 AM:
-

Pull Request @ https://github.com/apache/cassandra/pull/230


|| branch || CircleCI || 
| 
[trunk|https://github.com/thelastpickle/cassandra/tree/mck/docs--release-process]
 | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fdocs--release-process.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process]
 |

^not like the CircleCi builds checks the website build, but one can dream…


was (Author: michaelsembwever):
Pull Request @ https://github.com/apache/cassandra/pull/230


|| branch || CircleCI || 
| 
[trunk|https://github.com/thelastpickle/cassandra/tree/mck/docs--release-process]
 | 
[!https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process]
   |


> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604034#comment-16604034
 ] 

mck commented on CASSANDRA-14689:
-

Pull Request @ https://github.com/apache/cassandra/pull/230


|| branch || testall || 
| 
[trunk|https://github.com/thelastpickle/cassandra/tree/mck/docs--release-process]
 | 
[!https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process]
   |


> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604034#comment-16604034
 ] 

mck edited comment on CASSANDRA-14689 at 9/5/18 7:23 AM:
-

Pull Request @ https://github.com/apache/cassandra/pull/230


|| branch || CircleCI || 
| 
[trunk|https://github.com/thelastpickle/cassandra/tree/mck/docs--release-process]
 | 
[!https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process]
   |



was (Author: michaelsembwever):
Pull Request @ https://github.com/apache/cassandra/pull/230


|| branch || testall || 
| 
[trunk|https://github.com/thelastpickle/cassandra/tree/mck/docs--release-process]
 | 
[!https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fdocs--release-process]
   |


> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated CASSANDRA-14689:
---
Labels: pull-request-available  (was: )

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mck updated CASSANDRA-14689:

Reviewers: Michael Shuler, Stefan Podkowinski

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mck reassigned CASSANDRA-14689:
---

Assignee: mck

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mck updated CASSANDRA-14689:

Fix Version/s: 4.x

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mck updated CASSANDRA-14689:

Description: 
Provide an initial outline on the steps Release Managers follow for creating, 
voting and publishing a release for Apache Cassandra.


ASF has the following guidelines:
 * `ASF Release Policy `_.
 * `ASF Release Distribution Policy 
`_.
 * `ASF Release Best Practices 
`_.

The project is still doing some things in an outdated manner, eg using 
people.apache.org URLs for staging artefacts. There is no urgent need to fix 
these things but by having the docs published it can improved incrementally 
over time.

fyi [~mshuler]

  was:

Provide an initial outline on the steps Release Managers follow for creating, 
voting and publishing a release for Apache Cassandra.


ASF has the following guidelines:
 * `ASF Release Policy `_.
 * `ASF Release Distribution Policy 
`_.
 * `ASF Release Best Practices 
`_.

The project is still doing some things in an outdated manner, eg using 
people.apache.org URLs for staging artefacts. There is no urgent need to fix 
these things but by having the docs published it can improved incrementally 
over time.


> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14689) Add developer docs for creating releases

[mck (JIRA)]

mck created CASSANDRA-14689:
---

 Summary: Add developer docs for creating releases
 Key: CASSANDRA-14689
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
 Project: Cassandra
  Issue Type: Task
  Components: Documentation and Website
Reporter: mck



Provide an initial outline on the steps Release Managers follow for creating, 
voting and publishing a release for Apache Cassandra.


ASF has the following guidelines:
 * `ASF Release Policy `_.
 * `ASF Release Distribution Policy 
`_.
 * `ASF Release Best Practices 
`_.

The project is still doing some things in an outdated manner, eg using 
people.apache.org URLs for staging artefacts. There is no urgent need to fix 
these things but by having the docs published it can improved incrementally 
over time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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