cassandra git commit: Doc change: Include SSTable versions within the documentation.

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 904af8531 -> 48a539142


Doc change: Include SSTable versions within the documentation.

Closes #121

Patch by Joaquin Casares; Reviewed by Jeff Jirsa


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

Branch: refs/heads/trunk
Commit: 48a539142e9e318f9177ad8cec47819d1adc3df9
Parents: 904af85
Author: Joaquin Casares 
Authored: Tue Jun 13 20:51:45 2017 -0500
Committer: Jeff Jirsa 
Committed: Tue Aug 29 22:51:25 2017 -0700

--
 doc/source/architecture/storage_engine.rst | 79 +
 1 file changed, 79 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/48a53914/doc/source/architecture/storage_engine.rst
--
diff --git a/doc/source/architecture/storage_engine.rst 
b/doc/source/architecture/storage_engine.rst
index 72d5802..2a95d93 100644
--- a/doc/source/architecture/storage_engine.rst
+++ b/doc/source/architecture/storage_engine.rst
@@ -127,3 +127,82 @@ hash of the partition key when the default partitioner, 
``Murmur3Partition``, is
 stored in the order of their clustering keys.
 
 SSTables can be optionally compressed using block-based compression.
+
+SSTable Versions
+
+
+This section was created using the following
+`gist `_
+which utilized this original
+`source 
`_.
+
+The version numbers, to date are:
+
+Version 0
+~
+
+* b (0.7.0): added version to sstable filenames
+* c (0.7.0): bloom filter component computes hashes over raw key bytes instead 
of strings
+* d (0.7.0): row size in data component becomes a long instead of int
+* e (0.7.0): stores undecorated keys in data and index components
+* f (0.7.0): switched bloom filter implementations in data component
+* g (0.8): tracks flushed-at context in metadata component
+
+Version 1
+~
+
+* h (1.0): tracks max client timestamp in metadata component
+* hb (1.0.3): records compression ration in metadata component
+* hc (1.0.4): records partitioner in metadata component
+* hd (1.0.10): includes row tombstones in maxtimestamp
+* he (1.1.3): includes ancestors generation in metadata component
+* hf (1.1.6): marker that replay position corresponds to 1.1.5+ millis-based 
id (see CASSANDRA-4782)
+* ia (1.2.0):
+
+  * column indexes are promoted to the index file
+  * records estimated histogram of deletion times in tombstones
+  * bloom filter (keys and columns) upgraded to Murmur3
+* ib (1.2.1): tracks min client timestamp in metadata component
+* ic (1.2.5): omits per-row bloom filter of column names
+
+Version 2
+~
+
+* ja (2.0.0):
+
+  * super columns are serialized as composites (note that there is no real 
format change, this is mostly a marker to know if we should expect super 
columns or not. We do need a major version bump however, because we should not 
allow streaming of super columns into this new format)
+  * tracks max local deletiontime in sstable metadata
+  * records bloom_filter_fp_chance in metadata component
+  * remove data size and column count from data file (CASSANDRA-4180)
+  * tracks max/min column values (according to comparator)
+* jb (2.0.1):
+
+  * switch from crc32 to adler32 for compression checksums
+  * checksum the compressed data
+* ka (2.1.0):
+
+  * new Statistics.db file format
+  * index summaries can be downsampled and the sampling level is persisted
+  * switch uncompressed checksums to adler32
+  * tracks presense of legacy (local and remote) counter shards
+* la (2.2.0): new file name format
+* lb (2.2.7): commit log lower bound included
+
+Version 3
+~
+
+* ma (3.0.0):
+
+  * swap bf hash order
+  * store rows natively
+* mb (3.0.7, 3.7): commit log lower bound included
+* mc (3.0.8, 3.9): commit log intervals included
+
+Example Code
+
+
+The following example is useful for finding all sstables that do not match the 
"ib" SSTable version
+
+.. code-block:: bash
+
+find /var/lib/cassandra/data/ -type f | grep -v -- -ib- | grep -v 
"/snapshots"


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

[jira] [Updated] (CASSANDRA-9430) Add startup options to cqlshrc

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-9430:
--
External issue URL: https://github.com/apache/cassandra/pull/146

> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jeremy Hanna
>Priority: Minor
>  Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the 
> cqlshrc file.  For example, a user may want to set the paging to off by 
> default for their environment.  You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default 
> settings on startup.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-9430) Add startup options to cqlshrc

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-9430:
--
Status: Patch Available  (was: Open)

Appears there's a pull request for this functionality at 
https://github.com/apache/cassandra/pull/146

Marking patch-available in case someone would like to review it

> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jeremy Hanna
>Priority: Minor
>  Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the 
> cqlshrc file.  For example, a user may want to set the paging to off by 
> default for their environment.  You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default 
> settings on startup.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13652) Deadlock in AbstractCommitLogSegmentManager

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13652:


Github user jeffjirsa commented on the issue:

https://github.com/apache/cassandra/pull/127
  
Hi @Fuud - eb717f154bd24453273d7175006fdef75e5724c2 has been merged and 
CASSANDRA-13652 is closed. Is this PR still needed? If not, can you close it 
(the committers are unable to close it on your behalf)? 


> Deadlock in AbstractCommitLogSegmentManager
> ---
>
> Key: CASSANDRA-13652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13652
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Fuud
> Fix For: 3.11.1, 4.0
>
>
> AbstractCommitLogManager uses LockSupport.(un)park incorreclty. It invokes 
> unpark without checking if manager thread was parked in approriate place. 
> For example, logging frameworks uses queues and queues uses ReadWriteLock's 
> that uses LockSupport. Therefore AbstractCommitLogManager.wakeManager can 
> wake thread inside Lock and manager thread will sleep forever at park() 
> method (because unpark permit was already consumed inside lock).
> For examle stack traces:
> {code}
> "MigrationStage:1" id=412 state=WAITING
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at 
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.awaitAvailableSegment(AbstractCommitLogSegmentManager.java:263)
> at 
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.advanceAllocatingFrom(AbstractCommitLogSegmentManager.java:237)
> at 
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.forceRecycleAll(AbstractCommitLogSegmentManager.java:279)
> at 
> org.apache.cassandra.db.commitlog.CommitLog.forceRecycleAllSegments(CommitLog.java:210)
> at org.apache.cassandra.config.Schema.dropView(Schema.java:708)
> at 
> org.apache.cassandra.schema.SchemaKeyspace.lambda$updateKeyspace$23(SchemaKeyspace.java:1361)
> at 
> org.apache.cassandra.schema.SchemaKeyspace$$Lambda$382/1123232162.accept(Unknown
>  Source)
> at java.util.LinkedHashMap$LinkedValues.forEach(LinkedHashMap.java:608)
> at 
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080)
> at 
> org.apache.cassandra.schema.SchemaKeyspace.updateKeyspace(SchemaKeyspace.java:1361)
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1332)
> at 
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1282)
>   - locked java.lang.Class@cc38904
> at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$LocalSessionWrapper.run(DebuggableThreadPoolExecutor.java:322)
> at 
> com.ringcentral.concurrent.executors.MonitoredRunnable.run(MonitoredRunnable.java:36)
> at MON_R_MigrationStage.run(NamedRunnableFactory.java:67)
> at 
> com.ringcentral.concurrent.executors.MonitoredThreadPoolExecutor$MdcAwareRunnable.run(MonitoredThreadPoolExecutor.java:114)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$61/179045.run(Unknown
>  Source)
> at java.lang.Thread.run(Thread.java:745)
> "COMMIT-LOG-ALLOCATOR:1" id=80 state=WAITING
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1.runMayThrow(AbstractCommitLogSegmentManager.java:128)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$61/179045.run(Unknown
>  Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Solution is to use Semaphore instead of low-level LockSupport.



--
This 

cassandra git commit: Doc change: Update configuring.rst

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 349f7ea7e -> 904af8531


Doc change: Update configuring.rst

Closes #133

Patch by Piyush Rana; Reviewed by Jeff Jirsa


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

Branch: refs/heads/trunk
Commit: 904af85312d4d2557f118cafd1c614e67a918d7a
Parents: 349f7ea
Author: Piyush Rana 
Authored: Thu Jul 20 18:11:01 2017 +
Committer: Jeff Jirsa 
Committed: Tue Aug 29 22:37:48 2017 -0700

--
 doc/source/getting_started/configuring.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/904af853/doc/source/getting_started/configuring.rst
--
diff --git a/doc/source/getting_started/configuring.rst 
b/doc/source/getting_started/configuring.rst
index 27fac78..e71eeed 100644
--- a/doc/source/getting_started/configuring.rst
+++ b/doc/source/getting_started/configuring.rst
@@ -17,9 +17,9 @@
 Configuring Cassandra
 -
 
-For running Cassandra on a single node, the steps above are enough, you don't 
really need to change any configuration.
-However, when you deploy a cluster of nodes, or use clients that are not on 
the same host, then there are some
-parameters that must be changed.
+For running Cassandra on a single node, the default configuration file present 
at ``./conf/cassandra.yaml`` is enough, 
+you shouldn't need to change any configuration. However, when you deploy a 
cluster of nodes, or use clients that 
+are not on the same host, then there are some parameters that must be changed.
 
 The Cassandra configuration files can be found in the ``conf`` directory of 
tarballs. For packages, the configuration
 files will be located in ``/etc/cassandra``.


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

cassandra git commit: Doc change: Updated correct url post merging for ppc64le capi-rowcache.

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 0e80261c1 -> 349f7ea7e


Doc change: Updated correct url post merging for ppc64le capi-rowcache.

Closes #139

Patch by Amitkumar Ghatwal; Reviewed by Jeff Jirsa


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

Branch: refs/heads/trunk
Commit: 349f7ea7e99f6d906fa7d0a22825cd44b4e624c8
Parents: 0e80261
Author: ghatwala 
Authored: Tue Aug 22 11:36:54 2017 +0530
Committer: Jeff Jirsa 
Committed: Tue Aug 29 22:29:16 2017 -0700

--
 doc/source/plugins/index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/349f7ea7/doc/source/plugins/index.rst
--
diff --git a/doc/source/plugins/index.rst b/doc/source/plugins/index.rst
index 2642df2..4073a92 100644
--- a/doc/source/plugins/index.rst
+++ b/doc/source/plugins/index.rst
@@ -24,7 +24,7 @@ CAPI-Rowcache
 
 The Coherent Accelerator Process Interface (CAPI) is a general term for the 
infrastructure of attaching a Coherent accelerator to an IBM POWER system. A 
key innovation in IBM POWER8’s open architecture is the CAPI. It provides a 
high bandwidth, low latency path between external devices, the POWER8 core, and 
the system’s open memory architecture. IBM Data Engine for NoSQL is an 
integrated platform for large and fast growing NoSQL data stores. It builds on 
the CAPI capability of POWER8 systems and provides super-fast access to large 
flash storage capacity and addresses the challenges associated with typical x86 
server based scale-out deployments.
 
-The official page for the `CAPI-Rowcache plugin 
`__ contains further details how to 
build/run/download the plugin.
+The official page for the `CAPI-Rowcache plugin 
`__ contains further details how to 
build/run/download the plugin.
 
 
 Stratio’s Cassandra Lucene Index


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

[jira] [Commented] (CASSANDRA-13796) Fix trigger example on 4.0

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13796:


Github user clohfink closed the pull request at:

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


> Fix trigger example on 4.0
> --
>
> Key: CASSANDRA-13796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13796
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
> Fix For: 4.0
>
>
> {{CFMetadata.cfName}} was moved to {{name}} not {{table}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13418) Allow TWCS to ignore overlaps when dropping fully expired sstables

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-13418:
--

Yeah more want to document the implications for the user.

Basically my understanding is this:

Case 1 (enabling both: {{unsafe_aggressive_sstable_expiration}} and 
{{uncheckedTombstoneCompaction}}:
If data is read repaired into an earlier window, we will potentially trigger 
more compactions including the overlapping data but only when 
{{provide_overlapping_tombstones}} is set. If it is not set we will potentially 
trigger only single SSTable tombstone compactions which _may or may not_ 
provide a benefit. Basically if you enable more options the benefit is that you 
potentially get rid of read-repaired expired data faster, at the cost of more 
compactions. So you should only really do this if you have a significant amount 
of read-repaired data and hitting a lot of tombstones because of it.

Case 2 (enabling only {{unsafe_aggressive_sstable_expiration}}):
If data is read repaired into an earlier window, it will not be removed until 
the whole SSTable is expired, which means it will hang around until TTL passes 
for that table.

If that's not the whole story/correct please elaborate. I think it's worthwhile 
having it documented clearly somewhere (docs) why you'd set these options 
(together or separately).


> Allow TWCS to ignore overlaps when dropping fully expired sstables
> --
>
> Key: CASSANDRA-13418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13418
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Corentin Chary
>  Labels: twcs
> Attachments: twcs-cleanup.png
>
>
> http://thelastpickle.com/blog/2016/12/08/TWCS-part1.html explains it well. If 
> you really want read-repairs you're going to have sstables blocking the 
> expiration of other fully expired SSTables because they overlap.
> You can set unchecked_tombstone_compaction = true or tombstone_threshold to a 
> very low value and that will purge the blockers of old data that should 
> already have expired, thus removing the overlaps and allowing the other 
> SSTables to expire.
> The thing is that this is rather CPU intensive and not optimal. If you have 
> time series, you might not care if all your data doesn't exactly expire at 
> the right time, or if data re-appears for some time, as long as it gets 
> deleted as soon as it can. And in this situation I believe it would be really 
> beneficial to allow users to simply ignore overlapping SSTables when looking 
> for fully expired ones.
> To the question: why would you need read-repairs ?
> - Full repairs basically take longer than the TTL of the data on my dataset, 
> so this isn't really effective.
> - Even with a 10% chances of doing a repair, we found out that this would be 
> enough to greatly reduce entropy of the most used data (and if you have 
> timeseries, you're likely to have a dashboard doing the same important 
> queries over and over again).
> - LOCAL_QUORUM is too expensive (need >3 replicas), QUORUM is too slow.
> I'll try to come up with a patch demonstrating how this would work, try it on 
> our system and report the effects.
> cc: [~adejanovski], [~rgerard] as I know you worked on similar issues already.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13796) Fix trigger example on 4.0

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13796:


Github user jeffjirsa commented on the issue:

https://github.com/apache/cassandra/pull/140
  
@clohfink  - looks like this was merged in 
2e5847d29bbdd45fd4fc73f071779d91326ceeba , can you close?



> Fix trigger example on 4.0
> --
>
> Key: CASSANDRA-13796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13796
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
> Fix For: 4.0
>
>
> {{CFMetadata.cfName}} was moved to {{name}} not {{table}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-8727) nodetool command to get the status of things that can be enable/disable'd

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-8727:
---

Thanks for the patch [~cormoran]! I've marked this as patch-available, 
hopefully a committer gets some time to review it in the near future.


> nodetool command to get the status of things that can be enable/disable'd
> -
>
> Key: CASSANDRA-8727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8727
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter:  Brian Hess
>Assignee: cormoran
>  Labels: lhf
>
> It is possible to say enableautocompaction or disableautocompaction via 
> nodetool.  But it doesn't appear that there is a nodetool command to display 
> the current state of autocompaction - enabled or disabled.  
> It would be good to be able to get the status of these binary commands so 
> that you can determine the status, possibly make a change to 
> troubleshoot/experiment/etc, and return the status to the way it was when you 
> arrived.
> This applies for autocompaction, backup, binary, gossip, handoff, and thrift.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (CASSANDRA-8727) nodetool command to get the status of things that can be enable/disable'd

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa reassigned CASSANDRA-8727:
-

Assignee: cormoran

> nodetool command to get the status of things that can be enable/disable'd
> -
>
> Key: CASSANDRA-8727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8727
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter:  Brian Hess
>Assignee: cormoran
>  Labels: lhf
>
> It is possible to say enableautocompaction or disableautocompaction via 
> nodetool.  But it doesn't appear that there is a nodetool command to display 
> the current state of autocompaction - enabled or disabled.  
> It would be good to be able to get the status of these binary commands so 
> that you can determine the status, possibly make a change to 
> troubleshoot/experiment/etc, and return the status to the way it was when you 
> arrived.
> This applies for autocompaction, backup, binary, gossip, handoff, and thrift.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-8727) nodetool command to get the status of things that can be enable/disable'd

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-8727:
--
Status: Patch Available  (was: Open)

> nodetool command to get the status of things that can be enable/disable'd
> -
>
> Key: CASSANDRA-8727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8727
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter:  Brian Hess
>Assignee: cormoran
>  Labels: lhf
>
> It is possible to say enableautocompaction or disableautocompaction via 
> nodetool.  But it doesn't appear that there is a nodetool command to display 
> the current state of autocompaction - enabled or disabled.  
> It would be good to be able to get the status of these binary commands so 
> that you can determine the status, possibly make a change to 
> troubleshoot/experiment/etc, and return the status to the way it was when you 
> arrived.
> This applies for autocompaction, backup, binary, gossip, handoff, and thrift.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (CASSANDRA-13824) Add Elixir drivers to doc pages

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa resolved CASSANDRA-13824.

Resolution: Fixed

Committed to trunk as {{0e80261c154c99a2ea541f73d013c088f7fadf3b}}


> Add Elixir drivers to doc pages
> ---
>
> Key: CASSANDRA-13824
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13824
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
>
> From GH PR: https://github.com/apache/cassandra/pull/143



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

cassandra git commit: Doc change: add third party elixir drivers for cassandra

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 33ca487f9 -> 0e80261c1


Doc change: add third party elixir drivers for cassandra

Closes #143

Patch by Samar Dhwoj Acharya; Reviewed by Jeff Jirsa for CASSANDRA-13824


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

Branch: refs/heads/trunk
Commit: 0e80261c154c99a2ea541f73d013c088f7fadf3b
Parents: 33ca487
Author: Samar Dhwoj Acharya 
Authored: Tue Aug 29 16:14:26 2017 -0500
Committer: Jeff Jirsa 
Committed: Tue Aug 29 22:21:22 2017 -0700

--
 doc/source/getting_started/drivers.rst | 6 ++
 1 file changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e80261c/doc/source/getting_started/drivers.rst
--
diff --git a/doc/source/getting_started/drivers.rst 
b/doc/source/getting_started/drivers.rst
index e538386..c8d2e1f 100644
--- a/doc/source/getting_started/drivers.rst
+++ b/doc/source/getting_started/drivers.rst
@@ -110,3 +110,9 @@ Perl
 
 
 - `Cassandra::Client and DBD::Cassandra 
`__
+
+Elixir
+^^
+
+- `Xandra `__
+- `CQEx `__


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

[jira] [Created] (CASSANDRA-13824) Add Elixir drivers to doc pages

[Jeff Jirsa (JIRA)]

Jeff Jirsa created CASSANDRA-13824:
--

 Summary: Add Elixir drivers to doc pages
 Key: CASSANDRA-13824
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13824
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jeff Jirsa
Assignee: Jeff Jirsa
Priority: Trivial


>From GH PR: https://github.com/apache/cassandra/pull/143




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-8523) Writes should be sent to a replacement node while it is streaming in data

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-8523:
---

Github user asfgit closed the pull request at:

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


> Writes should be sent to a replacement node while it is streaming in data
> -
>
> Key: CASSANDRA-8523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8523
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Wagner
>Assignee: Paulo Motta
> Fix For: 2.2.8, 3.0.9, 3.10
>
>
> In our operations, we make heavy use of replace_address (or 
> replace_address_first_boot) in order to replace broken nodes. We now realize 
> that writes are not sent to the replacement nodes while they are in hibernate 
> state and streaming in data. This runs counter to what our expectations were, 
> especially since we know that writes ARE sent to nodes when they are 
> bootstrapped into the ring.
> It seems like cassandra should arrange to send writes to a node that is in 
> the process of replacing another node, just like it does for a nodes that are 
> bootstraping. I hesitate to phrase this as "we should send writes to a node 
> in hibernate" because the concept of hibernate may be useful in other 
> contexts, as per CASSANDRA-8336. Maybe a new state is needed here?
> Among other things, the fact that we don't get writes during this period 
> makes subsequent repairs more expensive, proportional to the number of writes 
> that we miss (and depending on the amount of data that needs to be streamed 
> during replacement and the time it may take to rebuild secondary indexes, we 
> could miss many many hours worth of writes). It also leaves us more exposed 
> to consistency violations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

cassandra git commit: Doc change: Describe replacement cases based on CASSANDRA-8523 and CASSANDRA-12344

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk e6c2ae1f3 -> 33ca487f9


Doc change: Describe replacement cases based on CASSANDRA-8523 and 
CASSANDRA-12344

Closes #145

Patch by Kurt Greaves; Reviewed by Jeff Jirsa for CASSANDRA-8523


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

Branch: refs/heads/trunk
Commit: 33ca487f95665b577730a409e7168feb99d3cbf9
Parents: e6c2ae1
Author: kurt 
Authored: Tue Aug 29 03:36:12 2017 +
Committer: Jeff Jirsa 
Committed: Tue Aug 29 22:17:46 2017 -0700

--
 doc/source/operating/topo_changes.rst | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/33ca487f/doc/source/operating/topo_changes.rst
--
diff --git a/doc/source/operating/topo_changes.rst 
b/doc/source/operating/topo_changes.rst
index c42708e..6c8f8ec 100644
--- a/doc/source/operating/topo_changes.rst
+++ b/doc/source/operating/topo_changes.rst
@@ -98,16 +98,21 @@ Replacing a dead node
 
 In order to replace a dead node, start cassandra with the JVM startup flag
 ``-Dcassandra.replace_address_first_boot=``. Once this property 
is enabled the node starts in a hibernate
-state, during which all the other nodes will see this node to be down.
+state, during which all the other nodes will see this node to be DOWN (DN), 
however this node will see itself as UP 
+(UN). Accurate replacement state can be found in ``nodetool netstats``.
 
-The replacing node will now start to bootstrap the data from the rest of the 
nodes in the cluster. The main difference
-between normal bootstrapping of a new node is that this new node will not 
accept any writes during this phase.
+The replacing node will now start to bootstrap the data from the rest of the 
nodes in the cluster. A replacing node will
+only receive writes during the bootstrapping phase if it has a different ip 
address to the node that is being replaced. 
+(See CASSANDRA-8523 and CASSANDRA-12344)
 
-Once the bootstrapping is complete the node will be marked "UP", we rely on 
the hinted handoff's for making this node
-consistent (since we don't accept writes since the start of the bootstrap).
+Once the bootstrapping is complete the node will be marked "UP". 
 
-.. Note:: If the replacement process takes longer than 
``max_hint_window_in_ms`` you **MUST** run repair to make the
-   replaced node consistent again, since it missed ongoing writes during 
bootstrapping.
+.. Note:: If any of the following cases apply, you **MUST** run repair to make 
the replaced node consistent again, since 
+it missed ongoing writes during/prior to bootstrapping. The *replacement* 
timeframe refers to the period from when the
+node initially dies to when a new node completes the replacement process.
+
+1. The node is down for longer than ``max_hint_window_in_ms`` before being 
replaced.
+2. You are replacing using the same IP address as the dead node **and** 
replacement takes longer than ``max_hint_window_in_ms``.
 
 Monitoring progress
 ^^^


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

[jira] [Commented] (CASSANDRA-8523) Writes should be sent to a replacement node while it is streaming in data

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-8523:
---

GitHub user kgreav opened a pull request:

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

Describe replacement cases based on CASSANDRA-8523 and CASSANDRA-12344

Just updating the docs to cover cases where replacing with a same IP node 
and different IP node.

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

$ git pull https://github.com/kgreav/cassandra replace_fix

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

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

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #145


commit e9228182d7f6916eab0dd64afcc57fedb103f25c
Author: kurt 
Date:   2017-08-29T03:36:12Z

Describe replacement cases based on CASSANDRA-8523 and CASSANDRA-12344




> Writes should be sent to a replacement node while it is streaming in data
> -
>
> Key: CASSANDRA-8523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8523
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Richard Wagner
>Assignee: Paulo Motta
> Fix For: 2.2.8, 3.0.9, 3.10
>
>
> In our operations, we make heavy use of replace_address (or 
> replace_address_first_boot) in order to replace broken nodes. We now realize 
> that writes are not sent to the replacement nodes while they are in hibernate 
> state and streaming in data. This runs counter to what our expectations were, 
> especially since we know that writes ARE sent to nodes when they are 
> bootstrapped into the ring.
> It seems like cassandra should arrange to send writes to a node that is in 
> the process of replacing another node, just like it does for a nodes that are 
> bootstraping. I hesitate to phrase this as "we should send writes to a node 
> in hibernate" because the concept of hibernate may be useful in other 
> contexts, as per CASSANDRA-8336. Maybe a new state is needed here?
> Among other things, the fact that we don't get writes during this period 
> makes subsequent repairs more expensive, proportional to the number of writes 
> that we miss (and depending on the amount of data that needs to be streamed 
> during replacement and the time it may take to rebuild secondary indexes, we 
> could miss many many hours worth of writes). It also leaves us more exposed 
> to consistency violations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13782) Cassandra RPM has wrong owner for /usr/share directories

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13782:


GitHub user sasayabaku opened a pull request:

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

[CASSANDRA-13782] RPM has wrong owner for /usr/share directories

Some Cassandra RPM directories are owned by "cassandra" user against the 
fedora package guidelines.
I changed redhat/cassandra.spec for giving the directories and files to 
appropriate owner.

$ls -l /usr/share | grep cassandra
[Before]
drwxr-xr-x   3 cassandra cassandra86 Aug 30 10:46 cassandra
[After]
drwxr-xr-x   3 root root86 Aug 29 18:03 cassandra

$ls -l /usr/share/cassandra/
[Before]
-rwxr-xr-x 1 cassandra cassandra 6406219 Aug 30 10:44 
apache-cassandra-4.0.jar
-rwxr-xr-x 1 cassandra cassandra 742 Aug 30 10:22 cassandra.in.sh
drwxr-xr-x 4 cassandra cassandra4096 Aug 30 10:46 lib
-rwxr-xr-x 1 cassandra cassandra  505000 Aug 30 10:44 stress.jar
[After]
-rwxr-xr-x 1 root root 6405131 Aug 29 18:01 apache-cassandra-4.0.jar
-rwxr-xr-x 1 root root 742 Aug 29 17:12 cassandra.in.sh
drwxr-xr-x 4 root root4096 Aug 29 18:03 lib
-rwxr-xr-x 1 root root  505000 Aug 29 18:01 stress.jar

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

$ git pull https://github.com/sasayabaku/cassandra trunk

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

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

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #144


commit 04bf41ad514860f8025030017e8682a25e2639d0
Author: sasayabaku 
Date:   2017-08-29T05:20:52Z

chenge owner to
 root




> Cassandra RPM has wrong owner for /usr/share directories
> 
>
> Key: CASSANDRA-13782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13782
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Hannu Kröger
>  Labels: lhf
>
> Some Cassandra RPM directories are owned by cassandra user against the fedora 
> package guidelines.
> Offending lines: 
> https://github.com/apache/cassandra/blob/trunk/redhat/cassandra.spec#L135-L136
> "Permissions on files MUST be set properly. Inside of /usr, files should be 
> owned by root:root unless a more specific user or group is needed for 
> security."
> - 
> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#File_Permissions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13823) The Getting Started page should have instructions on setting up cluster

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-13823:
--

 Summary: The Getting Started page should have instructions on 
setting up cluster
 Key: CASSANDRA-13823
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13823
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation and Website
Reporter: Jon Haddad


Currently the docs don't have an easy to follow guide on setting up a cluster.  
I think it would benefit from a nice easy to follow walkthrough.

https://cassandra.apache.org/doc/latest/getting_started/index.html




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13823) The Getting Started page should have instructions on setting up a cluster

[Jon Haddad (JIRA)]

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

Jon Haddad updated CASSANDRA-13823:
---
Summary: The Getting Started page should have instructions on setting up a 
cluster  (was: The Getting Started page should have instructions on setting up 
cluster)

> The Getting Started page should have instructions on setting up a cluster
> -
>
> Key: CASSANDRA-13823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13823
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>  Labels: lhf
>
> Currently the docs don't have an easy to follow guide on setting up a 
> cluster.  I think it would benefit from a nice easy to follow walkthrough.
> https://cassandra.apache.org/doc/latest/getting_started/index.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13817) cassandra allow filtering bug

[wang huatao (JIRA)]

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

wang huatao commented on CASSANDRA-13817:
-

CREATE TABLE IF NOT EXISTS player (
id text,
name text,
globalexp int,
gold int,
level int,
sliver int,
tankinbattle text,
PRIMARY KEY (id, name)
) WITH CLUSTERING ORDER BY ( name ASC )
AND bloom_filter_fp_chance = 0.01
AND comment = ''
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE'
AND caching = {
'keys' : 'ALL',
'rows_per_partition' : 'ALL'
}
AND compression = {
'chunk_length_in_kb' : 64,
'class' : 'LZ4Compressor',
'enabled' : true
}
AND compaction = {
'class' : 'SizeTieredCompactionStrategy',
'max_threshold' : 32,
'min_threshold' : 4
};


> cassandra allow filtering bug
> -
>
> Key: CASSANDRA-13817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13817
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Libraries
>Reporter: wang huatao
>  Labels: allow-filtering
> Fix For: 3.10
>
>
> I have one bug about cassandra cql, when I use  select * from table where 
> name = 'myName' alllow filtering,  sometimes can be found, but sometimes can 
> not found. I am very sure the row data existed. my data was very small, just 
> 2000 rows.and only one node.   i use cassandra 3.10, ubuntu 14.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13680) readBytes needs to clone its data

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13680:
-

{{ByteBufferUtils#readBytes}} isn't necessarily broken or buggy, as long as the 
callers are aware that the returned {{ByteBuffer}} has a shared view (and as 
long as they don't release any direct buffers). It looks like this method was 
created in March 2014 (not attached to any jira), so it's been in the code base 
for 3.5 years and is reasonably stable. (note: the code was around before that 
date; apparently moved from somewhere else in the code base).

Do you have any stack traces or example use cases in which this code is 
failing? 

CASSANDRA-3179 fixed a specific bug on a class that was explicitly for reading 
from files: {{MappedFileDataInput}}. So, while the code may be similar, the use 
and intent are quite different. Furthermore, making 
{{ByteBufferUtils#readBytes}} is completely unnecessary.

> readBytes needs to clone its data
> -
>
> Key: CASSANDRA-13680
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13680
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Hao Zhong
>
> The code of the ByteBufferUtil_readBytes method is as follow:
> {code}
>  public static ByteBuffer readBytes(ByteBuffer bb, int length)
> {
> ByteBuffer copy = bb.duplicate();
> copy.limit(copy.position() + length);
> bb.position(bb.position() + length);
> return copy;
> }
> {code}
> I found that CASSANDRA-3179 fixed a related bug. The buggy code is as follow:
> {code}
>  public synchronized ByteBuffer readBytes(int length) throws IOException
> {
> int remaining = buffer.remaining() - position;
> if (length > remaining)
> throw new IOException(String.format("mmap segment underflow; 
> remaining is %d but %d requested",
> remaining, length));
> ByteBuffer bytes = buffer.duplicate();
> bytes.position(buffer.position() + position).limit(buffer.position() 
> + position + length);
> position += length;
> return bytes;
> }
> {code}
> The fixed code is:
> {code}
>  public synchronized ByteBuffer readBytes(int length) throws IOException
> {
> int remaining = buffer.remaining() - position;
> if (length > remaining)
> throw new IOException(String.format("mmap segment underflow; 
> remaining is %d but %d requested",
> remaining, length));
> if (length == 0)
> return ByteBufferUtil.EMPTY_BYTE_BUFFER;
> ByteBuffer bytes = buffer.duplicate();
> bytes.position(buffer.position() + position).limit(buffer.position() 
> + position + length);
> position += length;
> // we have to copy the data in case we unreference the underlying 
> sstable.  See CASSANDRA-3179
> ByteBuffer clone = ByteBuffer.allocate(bytes.remaining());
> clone.put(bytes);
> clone.flip();
> return clone;
> }
> {code}
> The ByteBufferUtil_readBytes method may be modified in the same way to handle 
> the similar problem. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13587) Deadlock during CommitLog replay when Cassandra restarts

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13587:
-

well, damn, [~jay.zhuang] you should have said so 2 months ago :P. Srsly, 
though, that is good to hear. If the tests pass, I'll go ahead and commit.

> Deadlock during CommitLog replay when Cassandra restarts
> 
>
> Key: CASSANDRA-13587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
> Fix For: 3.0.x
>
> Attachments: 13587-3.0.txt, Reproduce_CASSANDRA-13587.txt
>
>
> Possible deadlock found when Cassandra is replaying commit log and at the 
> same time Mutation gets triggered by 
> SSTableReader(SystemKeyspace.persistSSTableReadMeter). As a result Cassandra 
> restart hangs forever
> Please find details of stack trace here:
> *Frame#1* This thread is trying to apply {{persistSSTableReadMeter}} mutation 
> and as a result it has called {{writeOrder.start()}} in {{Keyspace.java:533}}
> but there are no Commitlog Segments available because {{createReserveSegments 
> (CommitLogSegmentManager.java)}} is not yet {{true}} 
> Hence this thread is blocked on {{createReserveSegments}} to become {{true}}, 
> please note this thread has already started {{writeOrder}}
> {quote}
> "pool-11-thread-1" #251 prio=5 os_prio=0 tid=0x7fe128478400 nid=0x1b274 
> waiting on condition [0x7fe1389a]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.advanceAllocatingFrom(CommitLogSegmentManager.java:277)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.allocate(CommitLogSegmentManager.java:196)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:260)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:540)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:421)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:210)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:224)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:566)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:556)
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:295)
> at 
> org.apache.cassandra.db.SystemKeyspace.persistSSTableReadMeter(SystemKeyspace.java:1181)
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy$1.run(SSTableReader.java:2202)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> *Frame#2* This thread is trying to recover commit logs and as a result it 
> tries to flush Memtable by calling following code:
> {{futures.add(Keyspace.open(SystemKeyspace.NAME).getColumnFamilyStore(SystemKeyspace.BATCHES).forceFlush());}}
> As a result Frame#3 (below) gets created
> {quote}
> "main" #1 prio=5 os_prio=0 tid=0x7fe1c64ec400 nid=0x1af29 waiting on 
> condition [0x7fe1c94a1000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for  <0x0006370da0c0> (a 
> com.google.common.util.concurrent.ListenableFutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at 
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:383)
> at 
> 

[jira] [Commented] (CASSANDRA-13603) Change repair midpoint logging from CASSANDRA-13052

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13603:


Would love to revisit this.

[~spo...@gmail.com] / [~bdeggleston] , pushed rebased versions, and here's 
shortcut links to combined diffs for the three branches: 

https://github.com/apache/cassandra/compare/cassandra-3.0...jeffjirsa:cassandra-3.0-13603?ws=1
https://github.com/apache/cassandra/compare/cassandra-3.11...jeffjirsa:cassandra-3.11-13603?ws=1
 
https://github.com/apache/cassandra/compare/trunk...jeffjirsa:cassandra-13603?ws=1

Either of you see anything else you'd like to change that I didn't catch 
already? Either of you up to mark yourselves as formal reviewer? 

> Change repair midpoint logging from  CASSANDRA-13052
> 
>
> Key: CASSANDRA-13603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13603
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> In CASSANDRA-13052 , we changed the way we handle repairs on small ranges to 
> make them more sane in general, but {{MerkleTree.differenceHelper}} now 
> erroneously logs at error.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13587) Deadlock during CommitLog replay when Cassandra restarts

[Jay Zhuang (JIRA)]

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

Jay Zhuang commented on CASSANDRA-13587:


We deployed the patch to our prod clusters locally for about 2 months now. So 
far it looks good.

> Deadlock during CommitLog replay when Cassandra restarts
> 
>
> Key: CASSANDRA-13587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
> Fix For: 3.0.x
>
> Attachments: 13587-3.0.txt, Reproduce_CASSANDRA-13587.txt
>
>
> Possible deadlock found when Cassandra is replaying commit log and at the 
> same time Mutation gets triggered by 
> SSTableReader(SystemKeyspace.persistSSTableReadMeter). As a result Cassandra 
> restart hangs forever
> Please find details of stack trace here:
> *Frame#1* This thread is trying to apply {{persistSSTableReadMeter}} mutation 
> and as a result it has called {{writeOrder.start()}} in {{Keyspace.java:533}}
> but there are no Commitlog Segments available because {{createReserveSegments 
> (CommitLogSegmentManager.java)}} is not yet {{true}} 
> Hence this thread is blocked on {{createReserveSegments}} to become {{true}}, 
> please note this thread has already started {{writeOrder}}
> {quote}
> "pool-11-thread-1" #251 prio=5 os_prio=0 tid=0x7fe128478400 nid=0x1b274 
> waiting on condition [0x7fe1389a]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.advanceAllocatingFrom(CommitLogSegmentManager.java:277)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.allocate(CommitLogSegmentManager.java:196)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:260)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:540)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:421)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:210)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:224)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:566)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:556)
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:295)
> at 
> org.apache.cassandra.db.SystemKeyspace.persistSSTableReadMeter(SystemKeyspace.java:1181)
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy$1.run(SSTableReader.java:2202)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> *Frame#2* This thread is trying to recover commit logs and as a result it 
> tries to flush Memtable by calling following code:
> {{futures.add(Keyspace.open(SystemKeyspace.NAME).getColumnFamilyStore(SystemKeyspace.BATCHES).forceFlush());}}
> As a result Frame#3 (below) gets created
> {quote}
> "main" #1 prio=5 os_prio=0 tid=0x7fe1c64ec400 nid=0x1af29 waiting on 
> condition [0x7fe1c94a1000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for  <0x0006370da0c0> (a 
> com.google.common.util.concurrent.ListenableFutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at 
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:383)
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.blockForWrites(CommitLogReplayer.java:207)
> at 
> 

[jira] [Resolved] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo resolved CASSANDRA-13821.
---
Resolution: Not A Bug

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo commented on CASSANDRA-13821:
---

Jeff, 
Good to know that. Thanks for the confirmation.
I will close the Case.

Thanks,
R.-

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo updated CASSANDRA-13821:
--
Attachment: (was: operational logs.part01.rar)

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo updated CASSANDRA-13821:
--
Attachment: (was: CCGWEAPP05_cassandra.yaml)

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo updated CASSANDRA-13821:
--
Attachment: (was: operational logs.part03.rar)

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo updated CASSANDRA-13821:
--
Attachment: (was: operational logs.part02.rar)

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo updated CASSANDRA-13821:
--
Attachment: (was: CCGWEAPP04_cassandra.yaml)

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo updated CASSANDRA-13821:
--
Attachment: (was: CCGWEAPP03_cassandra.yaml)

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13587) Deadlock during CommitLog replay when Cassandra restarts

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13587:
-

[~chovatia.jayd...@gmail.com] Thanks for the patch. I've created a branch on my 
repo and pushed to circleci (for unit tests) and apache jenkins (for dtests)

||3.0||
|[branch|https://github.com/jasobrown/cassandra/tree/13587-3.0]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/232/console]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13587-3.0]|

As {{CommitLogSegmentManager}} is reworked on the 3.11 and trunk branches, is 
makes a fix on 3.0 less critical. I agree your patch is straight-forward (and 
easy to review), I'm going to need to ask one or two other folks who are more 
familiar with the CL path to take a look as well.

> Deadlock during CommitLog replay when Cassandra restarts
> 
>
> Key: CASSANDRA-13587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
> Fix For: 3.0.x
>
> Attachments: 13587-3.0.txt, Reproduce_CASSANDRA-13587.txt
>
>
> Possible deadlock found when Cassandra is replaying commit log and at the 
> same time Mutation gets triggered by 
> SSTableReader(SystemKeyspace.persistSSTableReadMeter). As a result Cassandra 
> restart hangs forever
> Please find details of stack trace here:
> *Frame#1* This thread is trying to apply {{persistSSTableReadMeter}} mutation 
> and as a result it has called {{writeOrder.start()}} in {{Keyspace.java:533}}
> but there are no Commitlog Segments available because {{createReserveSegments 
> (CommitLogSegmentManager.java)}} is not yet {{true}} 
> Hence this thread is blocked on {{createReserveSegments}} to become {{true}}, 
> please note this thread has already started {{writeOrder}}
> {quote}
> "pool-11-thread-1" #251 prio=5 os_prio=0 tid=0x7fe128478400 nid=0x1b274 
> waiting on condition [0x7fe1389a]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.advanceAllocatingFrom(CommitLogSegmentManager.java:277)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.allocate(CommitLogSegmentManager.java:196)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:260)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:540)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:421)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:210)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:224)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:566)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:556)
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:295)
> at 
> org.apache.cassandra.db.SystemKeyspace.persistSSTableReadMeter(SystemKeyspace.java:1181)
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy$1.run(SSTableReader.java:2202)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> *Frame#2* This thread is trying to recover commit logs and as a result it 
> tries to flush Memtable by calling following code:
> {{futures.add(Keyspace.open(SystemKeyspace.NAME).getColumnFamilyStore(SystemKeyspace.BATCHES).forceFlush());}}
> As a result Frame#3 (below) gets created
> {quote}
> "main" #1 prio=5 os_prio=0 tid=0x7fe1c64ec400 nid=0x1af29 waiting on 
> condition [0x7fe1c94a1000]
>java.lang.Thread.State: WAITING (parking)
> 

[jira] [Comment Edited] (CASSANDRA-13587) Deadlock during CommitLog replay when Cassandra restarts

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-13587 at 8/29/17 11:04 PM:
---

[~chovatia.jayd...@gmail.com] Thanks for the patch. I've created a branch on my 
repo and pushed to circleci (for unit tests) and apache jenkins (for dtests)

||3.0||
|[branch|https://github.com/jasobrown/cassandra/tree/13587-3.0]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/232/console]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13587-3.0]|

As {{CommitLogSegmentManager}} is reworked on the 3.11 and trunk branches, it 
makes a fix on 3.0 less critical. I agree your patch is straight-forward (and 
easy to review), I'm going to need to ask one or two other folks who are more 
familiar with the CL path to take a look as well.


was (Author: jasobrown):
[~chovatia.jayd...@gmail.com] Thanks for the patch. I've created a branch on my 
repo and pushed to circleci (for unit tests) and apache jenkins (for dtests)

||3.0||
|[branch|https://github.com/jasobrown/cassandra/tree/13587-3.0]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/232/console]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13587-3.0]|

As {{CommitLogSegmentManager}} is reworked on the 3.11 and trunk branches, is 
makes a fix on 3.0 less critical. I agree your patch is straight-forward (and 
easy to review), I'm going to need to ask one or two other folks who are more 
familiar with the CL path to take a look as well.

> Deadlock during CommitLog replay when Cassandra restarts
> 
>
> Key: CASSANDRA-13587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
> Fix For: 3.0.x
>
> Attachments: 13587-3.0.txt, Reproduce_CASSANDRA-13587.txt
>
>
> Possible deadlock found when Cassandra is replaying commit log and at the 
> same time Mutation gets triggered by 
> SSTableReader(SystemKeyspace.persistSSTableReadMeter). As a result Cassandra 
> restart hangs forever
> Please find details of stack trace here:
> *Frame#1* This thread is trying to apply {{persistSSTableReadMeter}} mutation 
> and as a result it has called {{writeOrder.start()}} in {{Keyspace.java:533}}
> but there are no Commitlog Segments available because {{createReserveSegments 
> (CommitLogSegmentManager.java)}} is not yet {{true}} 
> Hence this thread is blocked on {{createReserveSegments}} to become {{true}}, 
> please note this thread has already started {{writeOrder}}
> {quote}
> "pool-11-thread-1" #251 prio=5 os_prio=0 tid=0x7fe128478400 nid=0x1b274 
> waiting on condition [0x7fe1389a]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.advanceAllocatingFrom(CommitLogSegmentManager.java:277)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.allocate(CommitLogSegmentManager.java:196)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:260)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:540)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:421)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:210)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:224)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:566)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:556)
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:295)
> at 
> org.apache.cassandra.db.SystemKeyspace.persistSSTableReadMeter(SystemKeyspace.java:1181)
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy$1.run(SSTableReader.java:2202)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> 

[jira] [Commented] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13821:


Hi Ramiro,

Typically the JIRA is reserved for bugs and features. Unless you have reason to 
believe it's a bug in Cassandra, you should probably consider contacting [the 
user list first|http://cassandra.apache.org/community/#mailing] - there are 
other users there that will be happy to try to help you. 



> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
> Attachments: CCGWEAPP03_cassandra.yaml, CCGWEAPP04_cassandra.yaml, 
> CCGWEAPP05_cassandra.yaml, operational logs.part01.rar, operational 
> logs.part02.rar, operational logs.part03.rar
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13764) SelectTest.testMixedTTLOnColumnsWide is flaky

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13764:
---
   Resolution: Fixed
 Reviewer: Joel Knighton
Fix Version/s: 4.0
   3.11.1
   3.0.15
   Status: Resolved  (was: Ready to Commit)

Thanks Joel.

Committed to 3.0 as {{67ac1496cc9e7d9d15be28b9536e9cdbce42473d}} and merged to 
3.11 and trunk WITHOUT adding CHANGES.txt entry, because it's just a test fix 
and never hit a release (not quite a ninja).


> SelectTest.testMixedTTLOnColumnsWide is flaky
> -
>
> Key: CASSANDRA-13764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13764
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> {{org.apache.cassandra.cql3.validation.operations.SelectTest.testMixedTTLOnColumnsWide}}
>  is flaky. This is because it inserts rows and then asserts their contents 
> using {{ttl()}} in the select, but if the test is sufficiently slow, the 
> remaining ttl may change by the time the select is run. Anecdotally, 
> {{testSelectWithAlias}} in the same class uses a fudge factor of 1 second 
> that would fix all the failures I've seen, but it might make more sense to 
> measure the elapsed time in the test and calculate the acceptable variation 
> from that time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

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

Ramiro Rioboo commented on CASSANDRA-13821:
---

Hello Jeff,

I did not find a qualifying option: environmental / tuning / network.
Could you please tell me which Type should I apply?

Thanks,
R.-

> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
> Attachments: CCGWEAPP03_cassandra.yaml, CCGWEAPP04_cassandra.yaml, 
> CCGWEAPP05_cassandra.yaml, operational logs.part01.rar, operational 
> logs.part02.rar, operational logs.part03.rar
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13764) SelectTest.testMixedTTLOnColumnsWide is flaky

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13764:
---
Status: Ready to Commit  (was: Patch Available)

> SelectTest.testMixedTTLOnColumnsWide is flaky
> -
>
> Key: CASSANDRA-13764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13764
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Jeff Jirsa
>Priority: Trivial
>
> {{org.apache.cassandra.cql3.validation.operations.SelectTest.testMixedTTLOnColumnsWide}}
>  is flaky. This is because it inserts rows and then asserts their contents 
> using {{ttl()}} in the select, but if the test is sufficiently slow, the 
> remaining ttl may change by the time the select is run. Anecdotally, 
> {{testSelectWithAlias}} in the same class uses a fudge factor of 1 second 
> that would fix all the failures I've seen, but it might make more sense to 
> measure the elapsed time in the test and calculate the acceptable variation 
> from that time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[jjirsa]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: 771ad53259678badd581f656bc374c0044f7149d
Parents: 031d76c 67ac149
Author: Jeff Jirsa 
Authored: Tue Aug 29 15:50:34 2017 -0700
Committer: Jeff Jirsa 
Committed: Tue Aug 29 15:50:51 2017 -0700

--
 .../cql3/validation/operations/SelectTest.java  | 45 
 1 file changed, 37 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/771ad532/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--


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

[2/6] cassandra git commit: SelectTest.testMixedTTLOnColumnsWide is flaky

[jjirsa]

SelectTest.testMixedTTLOnColumnsWide is flaky

Patch by Jeff Jirsa; Reviewed by Joel Knighton for CASSANDRA-13764


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

Branch: refs/heads/cassandra-3.11
Commit: 67ac1496cc9e7d9d15be28b9536e9cdbce42473d
Parents: e817c83
Author: Jeff Jirsa 
Authored: Tue Aug 29 12:43:38 2017 -0700
Committer: Jeff Jirsa 
Committed: Tue Aug 29 15:50:23 2017 -0700

--
 .../cql3/validation/operations/SelectTest.java  | 45 
 1 file changed, 37 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/67ac1496/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 3ee20a0..90b47b7 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -2973,8 +2973,24 @@ public class SelectTest extends CQLTester
 execute("INSERT INTO %s (k) VALUES (2);");
 execute("INSERT INTO %s (k, i) VALUES (1, 1) USING TTL 100;");
 execute("INSERT INTO %s (k, i) VALUES (3, 3) USING TTL 100;");
-assertRows(execute("SELECT k, i, TTL(i) FROM %s "),
-   row(1, 1, 100), row(2, null, null), row(3, 3, 100));
+assertRows(execute("SELECT k, i FROM %s "),
+   row(1, 1),
+   row(2, null),
+   row(3, 3));
+
+UntypedResultSet rs = execute("SELECT k, i, ttl(i) AS name_ttl FROM 
%s");
+assertEquals("name_ttl", rs.metadata().get(2).name.toString());
+int i = 0;
+for (UntypedResultSet.Row row : rs)
+{
+if ( i % 2 == 0) // Every odd row has a null i/ttl
+assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+else
+assertTrue(row.has("name_ttl") == false);
+
+i++;
+}
+
 }
 
 @Test
@@ -2986,11 +3002,24 @@ public class SelectTest extends CQLTester
 execute("INSERT INTO %s (k, c) VALUES (1, 2) ;");
 execute("INSERT INTO %s (k, c, i) VALUES (1, 3, 3) USING TTL 100;");
 execute("INSERT INTO %s (k, c, i) VALUES (3, 3, 3) USING TTL 100;");
-assertRows(execute("SELECT k, c, i, TTL(i) FROM %s "),
-   row(1, 1, 1, 100),
-   row(1, 2, null, null),
-   row(1, 3, 3, 100),
-   row(2, 2, null, null),
-   row(3, 3, 3, 100));
+assertRows(execute("SELECT k, c, i FROM %s "),
+   row(1, 1, 1),
+   row(1, 2, null),
+   row(1, 3, 3),
+   row(2, 2, null),
+   row(3, 3, 3));
+
+UntypedResultSet rs = execute("SELECT k, c, i, ttl(i) AS name_ttl FROM 
%s");
+assertEquals("name_ttl", rs.metadata().get(3).name.toString());
+int i = 0;
+for (UntypedResultSet.Row row : rs)
+{
+if ( i % 2 == 0) // Every odd row has a null i/ttl
+assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+else
+assertTrue(row.has("name_ttl") == false);
+
+i++;
+}
 }
 }


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

[1/6] cassandra git commit: SelectTest.testMixedTTLOnColumnsWide is flaky

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 e817c83bc -> 67ac1496c
  refs/heads/cassandra-3.11 031d76c9b -> 771ad5325
  refs/heads/trunk 38ae30685 -> e6c2ae1f3


SelectTest.testMixedTTLOnColumnsWide is flaky

Patch by Jeff Jirsa; Reviewed by Joel Knighton for CASSANDRA-13764


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

Branch: refs/heads/cassandra-3.0
Commit: 67ac1496cc9e7d9d15be28b9536e9cdbce42473d
Parents: e817c83
Author: Jeff Jirsa 
Authored: Tue Aug 29 12:43:38 2017 -0700
Committer: Jeff Jirsa 
Committed: Tue Aug 29 15:50:23 2017 -0700

--
 .../cql3/validation/operations/SelectTest.java  | 45 
 1 file changed, 37 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/67ac1496/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 3ee20a0..90b47b7 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -2973,8 +2973,24 @@ public class SelectTest extends CQLTester
 execute("INSERT INTO %s (k) VALUES (2);");
 execute("INSERT INTO %s (k, i) VALUES (1, 1) USING TTL 100;");
 execute("INSERT INTO %s (k, i) VALUES (3, 3) USING TTL 100;");
-assertRows(execute("SELECT k, i, TTL(i) FROM %s "),
-   row(1, 1, 100), row(2, null, null), row(3, 3, 100));
+assertRows(execute("SELECT k, i FROM %s "),
+   row(1, 1),
+   row(2, null),
+   row(3, 3));
+
+UntypedResultSet rs = execute("SELECT k, i, ttl(i) AS name_ttl FROM 
%s");
+assertEquals("name_ttl", rs.metadata().get(2).name.toString());
+int i = 0;
+for (UntypedResultSet.Row row : rs)
+{
+if ( i % 2 == 0) // Every odd row has a null i/ttl
+assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+else
+assertTrue(row.has("name_ttl") == false);
+
+i++;
+}
+
 }
 
 @Test
@@ -2986,11 +3002,24 @@ public class SelectTest extends CQLTester
 execute("INSERT INTO %s (k, c) VALUES (1, 2) ;");
 execute("INSERT INTO %s (k, c, i) VALUES (1, 3, 3) USING TTL 100;");
 execute("INSERT INTO %s (k, c, i) VALUES (3, 3, 3) USING TTL 100;");
-assertRows(execute("SELECT k, c, i, TTL(i) FROM %s "),
-   row(1, 1, 1, 100),
-   row(1, 2, null, null),
-   row(1, 3, 3, 100),
-   row(2, 2, null, null),
-   row(3, 3, 3, 100));
+assertRows(execute("SELECT k, c, i FROM %s "),
+   row(1, 1, 1),
+   row(1, 2, null),
+   row(1, 3, 3),
+   row(2, 2, null),
+   row(3, 3, 3));
+
+UntypedResultSet rs = execute("SELECT k, c, i, ttl(i) AS name_ttl FROM 
%s");
+assertEquals("name_ttl", rs.metadata().get(3).name.toString());
+int i = 0;
+for (UntypedResultSet.Row row : rs)
+{
+if ( i % 2 == 0) // Every odd row has a null i/ttl
+assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+else
+assertTrue(row.has("name_ttl") == false);
+
+i++;
+}
 }
 }


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

[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[jjirsa]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: 771ad53259678badd581f656bc374c0044f7149d
Parents: 031d76c 67ac149
Author: Jeff Jirsa 
Authored: Tue Aug 29 15:50:34 2017 -0700
Committer: Jeff Jirsa 
Committed: Tue Aug 29 15:50:51 2017 -0700

--
 .../cql3/validation/operations/SelectTest.java  | 45 
 1 file changed, 37 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/771ad532/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--


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

[3/6] cassandra git commit: SelectTest.testMixedTTLOnColumnsWide is flaky

[jjirsa]

SelectTest.testMixedTTLOnColumnsWide is flaky

Patch by Jeff Jirsa; Reviewed by Joel Knighton for CASSANDRA-13764


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

Branch: refs/heads/trunk
Commit: 67ac1496cc9e7d9d15be28b9536e9cdbce42473d
Parents: e817c83
Author: Jeff Jirsa 
Authored: Tue Aug 29 12:43:38 2017 -0700
Committer: Jeff Jirsa 
Committed: Tue Aug 29 15:50:23 2017 -0700

--
 .../cql3/validation/operations/SelectTest.java  | 45 
 1 file changed, 37 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/67ac1496/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java 
b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 3ee20a0..90b47b7 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@ -2973,8 +2973,24 @@ public class SelectTest extends CQLTester
 execute("INSERT INTO %s (k) VALUES (2);");
 execute("INSERT INTO %s (k, i) VALUES (1, 1) USING TTL 100;");
 execute("INSERT INTO %s (k, i) VALUES (3, 3) USING TTL 100;");
-assertRows(execute("SELECT k, i, TTL(i) FROM %s "),
-   row(1, 1, 100), row(2, null, null), row(3, 3, 100));
+assertRows(execute("SELECT k, i FROM %s "),
+   row(1, 1),
+   row(2, null),
+   row(3, 3));
+
+UntypedResultSet rs = execute("SELECT k, i, ttl(i) AS name_ttl FROM 
%s");
+assertEquals("name_ttl", rs.metadata().get(2).name.toString());
+int i = 0;
+for (UntypedResultSet.Row row : rs)
+{
+if ( i % 2 == 0) // Every odd row has a null i/ttl
+assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+else
+assertTrue(row.has("name_ttl") == false);
+
+i++;
+}
+
 }
 
 @Test
@@ -2986,11 +3002,24 @@ public class SelectTest extends CQLTester
 execute("INSERT INTO %s (k, c) VALUES (1, 2) ;");
 execute("INSERT INTO %s (k, c, i) VALUES (1, 3, 3) USING TTL 100;");
 execute("INSERT INTO %s (k, c, i) VALUES (3, 3, 3) USING TTL 100;");
-assertRows(execute("SELECT k, c, i, TTL(i) FROM %s "),
-   row(1, 1, 1, 100),
-   row(1, 2, null, null),
-   row(1, 3, 3, 100),
-   row(2, 2, null, null),
-   row(3, 3, 3, 100));
+assertRows(execute("SELECT k, c, i FROM %s "),
+   row(1, 1, 1),
+   row(1, 2, null),
+   row(1, 3, 3),
+   row(2, 2, null),
+   row(3, 3, 3));
+
+UntypedResultSet rs = execute("SELECT k, c, i, ttl(i) AS name_ttl FROM 
%s");
+assertEquals("name_ttl", rs.metadata().get(3).name.toString());
+int i = 0;
+for (UntypedResultSet.Row row : rs)
+{
+if ( i % 2 == 0) // Every odd row has a null i/ttl
+assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+else
+assertTrue(row.has("name_ttl") == false);
+
+i++;
+}
 }
 }


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

[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[jjirsa]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: e6c2ae1f3b3ab540ac3bf4a3de40fbf1df8e7db8
Parents: 38ae306 771ad53
Author: Jeff Jirsa 
Authored: Tue Aug 29 15:51:03 2017 -0700
Committer: Jeff Jirsa 
Committed: Tue Aug 29 15:51:16 2017 -0700

--
 .../cql3/validation/operations/SelectTest.java  | 44 
 1 file changed, 36 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e6c2ae1f/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
--
diff --cc 
test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
index 54f11ff,4cdf087..e22519b
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java
@@@ -4755,8 -4746,24 +4755,23 @@@ public class SelectTest extends CQLTest
  execute("INSERT INTO %s (k) VALUES (2);");
  execute("INSERT INTO %s (k, i) VALUES (1, 1) USING TTL 100;");
  execute("INSERT INTO %s (k, i) VALUES (3, 3) USING TTL 100;");
- assertRows(execute("SELECT k, i, TTL(i) FROM %s "),
-row(1, 1, 100), row(2, null, null), row(3, 3, 100));
+ assertRows(execute("SELECT k, i FROM %s "),
+row(1, 1),
+row(2, null),
+row(3, 3));
+ 
+ UntypedResultSet rs = execute("SELECT k, i, ttl(i) AS name_ttl FROM 
%s");
+ assertEquals("name_ttl", rs.metadata().get(2).name.toString());
+ int i = 0;
+ for (UntypedResultSet.Row row : rs)
+ {
+ if ( i % 2 == 0) // Every odd row has a null i/ttl
+ assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+ else
+ assertTrue(row.has("name_ttl") == false);
+ 
+ i++;
+ }
 -
  }
  
  @Test
@@@ -4768,12 -4775,24 +4783,25 @@@
  execute("INSERT INTO %s (k, c) VALUES (1, 2) ;");
  execute("INSERT INTO %s (k, c, i) VALUES (1, 3, 3) USING TTL 100;");
  execute("INSERT INTO %s (k, c, i) VALUES (3, 3, 3) USING TTL 100;");
- assertRows(execute("SELECT k, c, i, TTL(i) FROM %s "),
-row(1, 1, 1, 100),
-row(1, 2, null, null),
-row(1, 3, 3, 100),
-row(2, 2, null, null),
-row(3, 3, 3, 100));
+ assertRows(execute("SELECT k, c, i FROM %s "),
+row(1, 1, 1),
+row(1, 2, null),
+row(1, 3, 3),
+row(2, 2, null),
+row(3, 3, 3));
+ 
+ UntypedResultSet rs = execute("SELECT k, c, i, ttl(i) AS name_ttl 
FROM %s");
+ assertEquals("name_ttl", rs.metadata().get(3).name.toString());
+ int i = 0;
+ for (UntypedResultSet.Row row : rs)
+ {
+ if ( i % 2 == 0) // Every odd row has a null i/ttl
+ assertTrue(row.getInt("name_ttl") >= 90 && 
row.getInt("name_ttl") <= 100);
+ else
+ assertTrue(row.has("name_ttl") == false);
+ 
+ i++;
+ }
  }
 +
  }


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

[jira] [Created] (CASSANDRA-13822) Add example of using cache option to documentation

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-13822:
--

 Summary: Add example of using cache option to documentation
 Key: CASSANDRA-13822
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13822
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation and Website
Reporter: Jon Haddad
Priority: Trivial


We should include an example of configuring cache in the docs.

{code}
CREATE TABLE simple (
id int,
key text,
value text,
primary key(key, value)
) WITH caching = {'keys': 'ALL', 'rows_per_partition': 10};
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13821:


Is there any reason you believe this to be a Cassandra bug rather than 
environmental / tuning / network?


> A lot of ReadTimeoutException errors
> 
>
> Key: CASSANDRA-13821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, CQL
> Environment: We have a Cassandra Cluster with 2 Datacenters:
> Cassandra Version: 2.2.5
> *+DC1 - OperationalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
> *+DC2 - AnalyticalDC:+*
> 3 nodes Virtual Server on VMWare. 
> S.O.: Running on Windows 2012 Server 64bits-native
> vCPU 12 Cores @ 2.5Ghz
> RAM: 16GB
> HDD: 3,6 TB Virtual Drive
>Reporter: Ramiro Rioboo
>  Labels: performance, windows
> Fix For: 2.2.5
>
> Attachments: CCGWEAPP03_cassandra.yaml, CCGWEAPP04_cassandra.yaml, 
> CCGWEAPP05_cassandra.yaml, operational logs.part01.rar, operational 
> logs.part02.rar, operational logs.part03.rar
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Our application connects directly to OperationalDC via CQL.
> During the daily operation we have a large number of WriteTimeoutException 
> and ReadTimeoutException errors.
> In the logs of Cassandra we can see that the read and write timeout errors 
> are also recorded with the error:
> _Java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> *+Log Detail, Application Level:+*
> _22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
> 'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
> Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
> were required but only 1 acknowledged the write)_
> *+Log Detail, Cassandra Level:+*
> _EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
> Range slice failure; received 0 of 1 responses for range 1 of 1 
> java.lang.RuntimeException: java.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
> received only 1 responses._
> The timeout error occurs 2 seconds later because of the configuration in the 
> yaml:+underlined text+
> _# How long the coordinator should wait for writes to complete
> write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13821) A lot of ReadTimeoutException errors

[Ramiro Rioboo (JIRA)]

Ramiro Rioboo created CASSANDRA-13821:
-

 Summary: A lot of ReadTimeoutException errors
 Key: CASSANDRA-13821
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13821
 Project: Cassandra
  Issue Type: Bug
  Components: Core, CQL
 Environment: We have a Cassandra Cluster with 2 Datacenters:

Cassandra Version: 2.2.5

*+DC1 - OperationalDC:+*
3 nodes Virtual Server on VMWare. 
S.O.: Windows 2012 Server 64bits-native
vCPU 12 Cores @ 2.5Ghz
RAM: 16GB
HDD: 3,6 TB Virtual Drive

*+DC2 - AnalyticalDC:+*
3 nodes Virtual Server on VMWare. 
S.O.: Running on Windows 2012 Server 64bits-native
vCPU 12 Cores @ 2.5Ghz
RAM: 16GB
HDD: 3,6 TB Virtual Drive

Reporter: Ramiro Rioboo
 Fix For: 2.2.5
 Attachments: CCGWEAPP03_cassandra.yaml, CCGWEAPP04_cassandra.yaml, 
CCGWEAPP05_cassandra.yaml, operational logs.part01.rar, operational 
logs.part02.rar, operational logs.part03.rar

Our application connects directly to OperationalDC via CQL.
During the daily operation we have a large number of WriteTimeoutException and 
ReadTimeoutException errors.

In the logs of Cassandra we can see that the read and write timeout errors are 
also recorded with the error:

_Java.lang.RuntimeException: java.lang.RuntimeException: 
org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
received only 1 responses._

*+Log Detail, Application Level:+*
_22:54:22,945 [ERROR] AbstractEntityManager  - Insert object 
'Event{...}' error com.datastax.driver.core.exceptions.WriteTimeoutException: 
Cassandra timeout during write query at consistency LOCAL_QUORUM (2 replica 
were required but only 1 acknowledged the write)_

*+Log Detail, Cassandra Level:+*
_EBUG [SharedPool-Worker-6] 2017-08-24 08:36:40,114 StorageProxy.java:1893 - 
Range slice failure; received 0 of 1 responses for range 1 of 1 
java.lang.RuntimeException: java.lang.RuntimeException: 
org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
received only 1 responses._

The timeout error occurs 2 seconds later because of the configuration in the 
yaml:+underlined text+
_# How long the coordinator should wait for writes to complete
write_request_timeout_in_ms: 2000_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13626) Check hashed password matches expected bcrypt hash format before checking

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13626:
---
Status: Patch Available  (was: Open)

|| branch || utest || dtest ||
| [3.0|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13626] | [3.0 
circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.0-13626] | 
[3.0 
dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/233/]
 |
| [3.11|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13626] | 
[3.11 
circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.11-13626] | 
[3.11 
dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/234/]
 |
| [trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-13626] | [trunk 
circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13626] | 
[trunk 
dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/235/]
 |


> Check hashed password matches expected bcrypt hash format before checking
> -
>
> Key: CASSANDRA-13626
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13626
> Project: Cassandra
>  Issue Type: Bug
>  Components: Auth
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We use {{Bcrypt.checkpw}} in the auth subsystem, but do a reasonably poor job 
> of guaranteeing that the hashed password we send to it is really a hashed 
> password, and {{checkpw}} does an even worse job of failing nicely. We should 
> at least sanity check the hash complies with the expected format prior to 
> validating.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13820) List languages on driver list alphabetically

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-13820:
--

 Summary: List languages on driver list alphabetically 
 Key: CASSANDRA-13820
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13820
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation and Website
Reporter: Jon Haddad
Assignee: Jon Haddad


This is pretty minor, but I think the list of drivers on 
https://cassandra.apache.org/doc/latest/getting_started/index.html should be 
listed in alphabetical order to make it more readable.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13587) Deadlock during CommitLog replay when Cassandra restarts

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13587:

Reviewer: Jason Brown

> Deadlock during CommitLog replay when Cassandra restarts
> 
>
> Key: CASSANDRA-13587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13587
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
> Fix For: 3.0.x
>
> Attachments: 13587-3.0.txt, Reproduce_CASSANDRA-13587.txt
>
>
> Possible deadlock found when Cassandra is replaying commit log and at the 
> same time Mutation gets triggered by 
> SSTableReader(SystemKeyspace.persistSSTableReadMeter). As a result Cassandra 
> restart hangs forever
> Please find details of stack trace here:
> *Frame#1* This thread is trying to apply {{persistSSTableReadMeter}} mutation 
> and as a result it has called {{writeOrder.start()}} in {{Keyspace.java:533}}
> but there are no Commitlog Segments available because {{createReserveSegments 
> (CommitLogSegmentManager.java)}} is not yet {{true}} 
> Hence this thread is blocked on {{createReserveSegments}} to become {{true}}, 
> please note this thread has already started {{writeOrder}}
> {quote}
> "pool-11-thread-1" #251 prio=5 os_prio=0 tid=0x7fe128478400 nid=0x1b274 
> waiting on condition [0x7fe1389a]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.advanceAllocatingFrom(CommitLogSegmentManager.java:277)
> at 
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager.allocate(CommitLogSegmentManager.java:196)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:260)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:540)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:421)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:210)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:224)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:566)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:556)
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:295)
> at 
> org.apache.cassandra.db.SystemKeyspace.persistSSTableReadMeter(SystemKeyspace.java:1181)
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy$1.run(SSTableReader.java:2202)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> *Frame#2* This thread is trying to recover commit logs and as a result it 
> tries to flush Memtable by calling following code:
> {{futures.add(Keyspace.open(SystemKeyspace.NAME).getColumnFamilyStore(SystemKeyspace.BATCHES).forceFlush());}}
> As a result Frame#3 (below) gets created
> {quote}
> "main" #1 prio=5 os_prio=0 tid=0x7fe1c64ec400 nid=0x1af29 waiting on 
> condition [0x7fe1c94a1000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for  <0x0006370da0c0> (a 
> com.google.common.util.concurrent.ListenableFutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at 
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:383)
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.blockForWrites(CommitLogReplayer.java:207)
> at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:182)
> at 
> 

[jira] [Commented] (CASSANDRA-13797) RepairJob blocks on syncTasks

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13797:
-

let's see if this one finishes: 
[dtest|https://issues.apache.org/jira/browse/CASSANDRA-13797]

> RepairJob blocks on syncTasks
> -
>
> Key: CASSANDRA-13797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13797
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> The thread running {{RepairJob}} blocks while it waits for the validations it 
> starts to complete ([see 
> here|https://github.com/bdeggleston/cassandra/blob/9fdec0a82851f5c35cd21d02e8c4da8fc685edb2/src/java/org/apache/cassandra/repair/RepairJob.java#L185]).
>  However, the downstream callbacks (ie: the post-repair cleanup stuff) aren't 
> waiting for {{RepairJob#run}} to return, they're waiting for a result to be 
> set on RepairJob the future, which happens after the sync tasks have 
> completed. This post repair cleanup stuff also immediately shuts down the 
> executor {{RepairJob#run}} is running in. So in noop repair sessions, where 
> there's nothing to stream, I'm seeing the callbacks sometimes fire before 
> {{RepairJob#run}} wakes up, and causing an {{InterruptedException}} is thrown.
> I'm pretty sure this can just be removed, but I'd like a second opinion. This 
> appears to just be a holdover from before repair coordination became async. I 
> thought it might be doing some throttling by blocking, but each repair 
> session gets it's own executor, and validation is  throttled by the fixed 
> size executors doing the actual work of validation, so I don't think we need 
> to keep this around.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13786) Validation compactions can cause orphan sstable warnings

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-13786:

Reviewer: Marcus Eriksson
  Status: Patch Available  (was: Open)

Fixed

[trunk|https://github.com/bdeggleston/cassandra/tree/orphan-sstables2]
[utest|https://circleci.com/gh/bdeggleston/cassandra/tree/orphan-sstables2]
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/230/]

> Validation compactions can cause orphan sstable warnings
> 
>
> Key: CASSANDRA-13786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13786
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> I've seen LevelledCompactionStrategy occasionally logging: 
> {quote} from level 0 is not on corresponding level in the 
> leveled manifest. This is not a problem per se, but may indicate an orphaned 
> sstable due to a failed compaction not cleaned up properly."{quote} warnings 
> from a ValidationExecutor thread.
> What's happening here is that a compaction running concurrently with the 
> validation is promoting (or demoting) sstables as part of an incremental 
> repair, and an sstable has changed hands by the time the validation 
> compaction gets around to getting scanners for it. The sstable 
> isolation/synchronization done by validation compactions is a lot looser than 
> normal compactions, so seeing this happen isn't very surprising. Given that 
> it's harmless, and not unexpected, I think it would be best to not log these 
> during validation compactions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13764) SelectTest.testMixedTTLOnColumnsWide is flaky

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-13764:
---

The idea looks sound to me - I think you need to remove the TTL column from the 
select 
[here|https://github.com/jeffjirsa/cassandra/commit/a1e49db69622de11a996d09105e5ebf3b54c58c3#diff-7f5981228f9d9428fb164aa91316aa85R2976],
 as you did in {{testMixedTTLOnColumnsWide}}. If you agree, I'm comfortable 
with you doing that on commit and don't need to rereview if CI looks good.

> SelectTest.testMixedTTLOnColumnsWide is flaky
> -
>
> Key: CASSANDRA-13764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13764
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Jeff Jirsa
>Priority: Trivial
>
> {{org.apache.cassandra.cql3.validation.operations.SelectTest.testMixedTTLOnColumnsWide}}
>  is flaky. This is because it inserts rows and then asserts their contents 
> using {{ttl()}} in the select, but if the test is sufficiently slow, the 
> remaining ttl may change by the time the select is run. Anecdotally, 
> {{testSelectWithAlias}} in the same class uses a fudge factor of 1 second 
> that would fix all the failures I've seen, but it might make more sense to 
> measure the elapsed time in the test and calculate the acceptable variation 
> from that time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13818) Add support for --hosts, --force, and subrange repair to incremental repair

[Blake Eggleston (JIRA)]

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

Blake Eggleston edited comment on CASSANDRA-13818 at 8/29/17 9:19 PM:
--

[trunk|https://github.com/bdeggleston/cassandra/tree/13818]
[dtest-branch|https://github.com/bdeggleston/cassandra-dtest/tree/13818]
[utest|https://circleci.com/gh/bdeggleston/cassandra/tree/13818]
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/229/]

Before adding the functionality for this, I did some repair related cleanup. 
First, I removed any remaining references to the idea of a 'consistent' repair, 
it's all incremental now. I also cleaned up {{RepairRunnable}} a bit. Removing 
some unused function args, and refactoring out some abuse 
({{List>>}}) of 
generics.

I should point out that doing a non-global incremental repair still uses all of 
the incremental repair plumbing, it just always demotes the result back to 
unrepaired. This means that there is still an anti-compaction performed up 
front. This is not optimal from the perspective of moving bytes around on disk, 
but I'd rather do that than add another repair path for what should be a repair 
option that's not used often. Because of this though, doing a subrange repair 
no longer prevents a repair from being considered global. The original reason 
for doing this was to prevent anti-compaction, but since anti-compaction is 
preformed at the start of an incremental repair, I don't see any reason to just 
promote the incrementally repaired subrange when it's finished.


was (Author: bdeggleston):
[trunk|https://github.com/bdeggleston/cassandra/tree/13818]
[dtest|https://github.com/bdeggleston/cassandra-dtest/tree/13818]
[utest|https://circleci.com/gh/bdeggleston/cassandra/tree/13818]
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/229/]

Before adding the functionality for this, I did some repair related cleanup. 
First, I removed any remaining references to the idea of a 'consistent' repair, 
it's all incremental now. I also cleaned up {{RepairRunnable}} a bit. Removing 
some unused function args, and refactoring out some abuse 
({{List>>}}) of 
generics.

I should point out that doing a non-global incremental repair still uses all of 
the incremental repair plumbing, it just always demotes the result back to 
unrepaired. This means that there is still an anti-compaction performed up 
front. This is not optimal from the perspective of moving bytes around on disk, 
but I'd rather do that than add another repair path for what should be a repair 
option that's not used often. Because of this though, doing a subrange repair 
no longer prevents a repair from being considered global. The original reason 
for doing this was to prevent anti-compaction, but since anti-compaction is 
preformed at the start of an incremental repair, I don't see any reason to just 
promote the incrementally repaired subrange when it's finished.

> Add support for --hosts, --force, and subrange repair to incremental repair
> ---
>
> Key: CASSANDRA-13818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13818
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It should be possible to run incremental repair with nodes down, we just 
> shouldn't promote the data to repaired afterwards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13818) Add support for --hosts, --force, and subrange repair to incremental repair

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-13818:

 Reviewer: Marcus Eriksson
Fix Version/s: 4.0
   Status: Patch Available  (was: Open)

[trunk|https://github.com/bdeggleston/cassandra/tree/13818]
[dtest|https://github.com/bdeggleston/cassandra-dtest/tree/13818]
[utest|https://circleci.com/gh/bdeggleston/cassandra/tree/13818]
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/229/]

Before adding the functionality for this, I did some repair related cleanup. 
First, I removed any remaining references to the idea of a 'consistent' repair, 
it's all incremental now. I also cleaned up {{RepairRunnable}} a bit. Removing 
some unused function args, and refactoring out some abuse 
({{List>>}}) of 
generics.

I should point out that doing a non-global incremental repair still uses all of 
the incremental repair plumbing, it just always demotes the result back to 
unrepaired. This means that there is still an anti-compaction performed up 
front. This is not optimal from the perspective of moving bytes around on disk, 
but I'd rather do that than add another repair path for what should be a repair 
option that's not used often. Because of this though, doing a subrange repair 
no longer prevents a repair from being considered global. The original reason 
for doing this was to prevent anti-compaction, but since anti-compaction is 
preformed at the start of an incremental repair, I don't see any reason to just 
promote the incrementally repaired subrange when it's finished.

> Add support for --hosts, --force, and subrange repair to incremental repair
> ---
>
> Key: CASSANDRA-13818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13818
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It should be possible to run incremental repair with nodes down, we just 
> shouldn't promote the data to repaired afterwards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Jay Zhuang (JIRA)]

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

Jay Zhuang resolved CASSANDRA-13785.

Resolution: Duplicate

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Jay Zhuang (JIRA)]

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

Jay Zhuang commented on CASSANDRA-13785:


Thanks [~jjirsa] it's the same issue as CASSANDRA-12014. Closing as duplicated.

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Jay Zhuang (JIRA)]

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

Jay Zhuang updated CASSANDRA-13785:
---
Status: Open  (was: Patch Available)

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13785:


FWIW, there's a related CASSANDRA-12014 which is patch available which TRIES to 
guess when this will happen and change the index interval to compensate.


> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13695) ReadStage threads have no timeout

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13695:
-

ftr, SASI has a QoS mechanism already [built 
in|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/plan/QueryController.java#L154].
 The basic logic is rather straight forward, and could probably be extracted 
and reused. Plumbing it in/through is where the real work is, as [~cnlwsu] 
pointed out in the linked user@ thread. 



> ReadStage threads have no timeout
> -
>
> Key: CASSANDRA-13695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13695
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Vladimir Yudovin
>
> Following this discussion: [High CPU after read 
> timeout|https://lists.apache.org/thread.html/e22a2a77634f9228bf1d5474cc77ea461262f2e125cd2fa21a17f7a2@%3Cdev.cassandra.apache.org%3E]
> Currently ReadStage threads have no timeout and continue to run without 
> limitation after xxx_request_timeout_in_ms expired. Thus single bad request 
> like SELECT ... ALLOW FILTERING can paralyze the whole cluster for hours and 
> even more.
> I guess that read request should include a kind *timeout *or *expired_at 
> parameter* and handling thread will check it and stop processing after 
> expiration time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13655) Range deletes in a CAS batch are ignored

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13655:


Thank you both, sorry for the delay. Have pushed up a commit to each branch to 
address your collective comments. CircleCI is queued up, dtests are running. 

|| Branch || Unit Tests || Dtests ||
| [3.0|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13655] | 
[circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.0-13655] | 
[asf 
jenkins|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/226/]
 |
| [3.11|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13655] | 
[circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.11-13655] 
| [asf 
jenkins|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/227/]
 |
| [trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-13655] | 
[circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13655] | 
[asf 
jenkins|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/228/]
 |


> Range deletes in a CAS batch are ignored
> 
>
> Key: CASSANDRA-13655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13655
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Range deletes in a CAS batch are ignored 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13692) CompactionAwareWriter_getWriteDirectory throws incompatible exceptions

[Dimitar Dimitrov (JIRA)]

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

Dimitar Dimitrov commented on CASSANDRA-13692:
--

Sorry for the late promised update.
I'm currently finalizing the test, which is a bit of a mix between 
{{OutOfSpaceTest}}, {{CompactionAwareWriterTest}}, and 
{{CompactionsBytemanTest}}.

I reckon that (1) the {{OutOfSpaceTest}}s approach translates well enough for 
checking whether failure policies are correctly triggered in this case; (2) the 
trickiest part (for me) would be to figure out whether the way 
{{CompactionAwareWriter#getWriteDirectory(Iterable, long)}} gets 
reached and executed, is correct and relevant.

> CompactionAwareWriter_getWriteDirectory throws incompatible exceptions
> --
>
> Key: CASSANDRA-13692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13692
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Hao Zhong
>Assignee: Dimitar Dimitrov
>  Labels: lhf
>
> The CompactionAwareWriter_getWriteDirectory throws RuntimeException:
> {code}
> public Directories.DataDirectory getWriteDirectory(Iterable 
> sstables, long estimatedWriteSize)
> {
> File directory = null;
> for (SSTableReader sstable : sstables)
> {
> if (directory == null)
> directory = sstable.descriptor.directory;
> if (!directory.equals(sstable.descriptor.directory))
> {
> logger.trace("All sstables not from the same disk - putting 
> results in {}", directory);
> break;
> }
> }
> Directories.DataDirectory d = 
> getDirectories().getDataDirectoryForFile(directory);
> if (d != null)
> {
> long availableSpace = d.getAvailableSpace();
> if (availableSpace < estimatedWriteSize)
> throw new RuntimeException(String.format("Not enough space to 
> write %s to %s (%s available)",
>  
> FBUtilities.prettyPrintMemory(estimatedWriteSize),
>  d.location,
>  
> FBUtilities.prettyPrintMemory(availableSpace)));
> logger.trace("putting compaction results in {}", directory);
> return d;
> }
> d = getDirectories().getWriteableLocation(estimatedWriteSize);
> if (d == null)
> throw new RuntimeException(String.format("Not enough disk space 
> to store %s",
>  
> FBUtilities.prettyPrintMemory(estimatedWriteSize)));
> return d;
> }
> {code}
> However, the thrown exception does not  trigger the failure policy. 
> CASSANDRA-11448 fixed a similar problem. The buggy code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory = 
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new RuntimeException("Insufficient disk space to write " + 
> writeSize + " bytes");
> return directory;
> }
> {code}
> The fixed code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory = 
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new FSWriteError(new IOException("Insufficient disk space 
> to write " + writeSize + " bytes"), "");
> return directory;
> }
> {code}
> The fixed code throws FSWE and triggers the failure policy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13764) SelectTest.testMixedTTLOnColumnsWide is flaky

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13764:
---
Status: Patch Available  (was: In Progress)

> SelectTest.testMixedTTLOnColumnsWide is flaky
> -
>
> Key: CASSANDRA-13764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13764
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Jeff Jirsa
>Priority: Trivial
>
> {{org.apache.cassandra.cql3.validation.operations.SelectTest.testMixedTTLOnColumnsWide}}
>  is flaky. This is because it inserts rows and then asserts their contents 
> using {{ttl()}} in the select, but if the test is sufficiently slow, the 
> remaining ttl may change by the time the select is run. Anecdotally, 
> {{testSelectWithAlias}} in the same class uses a fudge factor of 1 second 
> that would fix all the failures I've seen, but it might make more sense to 
> measure the elapsed time in the test and calculate the acceptable variation 
> from that time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13764) SelectTest.testMixedTTLOnColumnsWide is flaky

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13764:


[~slebresne] says he's ok with ninja'ing this in, but in case you ( [~jkni] ) 
want to review before I do it (I need to push for Circle anyway just to be 
safe, so this'll sit here until Circle gives me a green run):

3.0: https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13764 (Circle: 
https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.0-13764 )
3.11: https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13764 (Circle: 
 https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.11-13764 )
trunk: https://github.com/jeffjirsa/cassandra/tree/cassandra-13764 (Circle: 
https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13764 )

> SelectTest.testMixedTTLOnColumnsWide is flaky
> -
>
> Key: CASSANDRA-13764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13764
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Jeff Jirsa
>Priority: Trivial
>
> {{org.apache.cassandra.cql3.validation.operations.SelectTest.testMixedTTLOnColumnsWide}}
>  is flaky. This is because it inserts rows and then asserts their contents 
> using {{ttl()}} in the select, but if the test is sufficiently slow, the 
> remaining ttl may change by the time the select is run. Anecdotally, 
> {{testSelectWithAlias}} in the same class uses a fudge factor of 1 second 
> that would fix all the failures I've seen, but it might make more sense to 
> measure the elapsed time in the test and calculate the acceptable variation 
> from that time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13433) RPM distribution improvements and known issues

[Nathaniel Tabernero (JIRA)]

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

Nathaniel Tabernero edited comment on CASSANDRA-13433 at 8/29/17 7:40 PM:
--

I've attached a patch file against cassandra-3.9 for creating a rpm which works 
on Centos 6 ([^cassandra-3.9-centos6.patch]).  At the time we upgraded 
Cassandra, version 3.9 was the latest stable version. This patch file includes 
a rpm spec file which has a dependency on python27 from the centos-release-scl 
repo. The python27 package will install python into an alternate location which 
will not conflict the Centos 6's default installed python 2.6 . Additionally, 
the spec file will modify the cqlsh script to use python 2.7.

Here are the steps we use to install Cassandra 3.9 on Centos 6.9 in our 
environment:
{panel}
#Install Java 8, then
sudo yum install centos-release-scl # install SCL repo
sudo yum localinstall cassandra-3.9-2.scl.el6.noarch.rpm #install custom build 
cassandra 3.9 rpm
sudo service cassandra start
sudo chkconfig cassandra on
{panel}

If this custom rpm is not available and cassandra 3.9 is already installed 
through other means, then: 
{panel}
sudo yum install centos-release-scl # install SCL repo
sudo yum install python27 # install Python 2.7
{panel}

Then, manually modify the cqlsh script.  Add the following lines after the 
comment header
{panel}
\# Enable python2.7 from centos 6 SCL 
source /opt/rh/python27/enable
{panel}

I hope this is helpful!



was (Author: ntabernero):
I've attached a patch file against cassandra-3.9 for creating a rpm which works 
on Centos 6.  At the time we upgraded Cassandra, version 3.9 was the latest 
stable version. This patch file includes a rpm spec file which has a dependency 
on python27 from the centos-release-scl repo. The python27 package will install 
python into an alternate location which will not conflict the Centos 6's 
default installed python 2.6 . Additionally, the spec file will modify the 
cqlsh script to use python 2.7.

Here are the steps we use to install Cassandra 3.9 on Centos 6.9 in our 
environment:
{panel}
#Install Java 8, then
sudo yum install centos-release-scl # install SCL repo
sudo yum localinstall cassandra-3.9-2.scl.el6.noarch.rpm #install custom build 
cassandra 3.9 rpm
sudo service cassandra start
sudo chkconfig cassandra on
{panel}

If this custom rpm is not available and cassandra 3.9 is already installed 
through other means, then: 
{panel}
sudo yum install centos-release-scl # install SCL repo
sudo yum install python27 # install Python 2.7
{panel}

Then, manually modify the cqlsh script.  Add the following lines after the 
comment header
{panel}
\# Enable python2.7 from centos 6 SCL 
source /opt/rh/python27/enable
{panel}

I hope this is helpful!


> RPM distribution improvements and known issues
> --
>
> Key: CASSANDRA-13433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13433
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: cassandra-3.9-centos6.patch
>
>
> Starting with CASSANDRA-13252, new releases will be provided as both official 
> RPM and Debian packages.  While the Debian packages are already well 
> established with our user base, the RPMs just have been release for the first 
> time and still require some attention. 
> Feel free to discuss RPM related issues in this ticket and open a sub-task to 
> fill a bug report. 
> Please note that native systemd support will be implemented with 
> CASSANDRA-13148 and this is not strictly a RPM specific issue. We still 
> intent to offer non-systemd support based on the already working init scripts 
> that we ship. Therefor the first step is to make use of systemd backward 
> compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd 
> and non-systemd environments.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13433) RPM distribution improvements and known issues

[Nathaniel Tabernero (JIRA)]

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

Nathaniel Tabernero updated CASSANDRA-13433:

Attachment: cassandra-3.9-centos6.patch

patch file against cassandra-3.9 for creating a rpm which works on Centos 6

> RPM distribution improvements and known issues
> --
>
> Key: CASSANDRA-13433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13433
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: cassandra-3.9-centos6.patch
>
>
> Starting with CASSANDRA-13252, new releases will be provided as both official 
> RPM and Debian packages.  While the Debian packages are already well 
> established with our user base, the RPMs just have been release for the first 
> time and still require some attention. 
> Feel free to discuss RPM related issues in this ticket and open a sub-task to 
> fill a bug report. 
> Please note that native systemd support will be implemented with 
> CASSANDRA-13148 and this is not strictly a RPM specific issue. We still 
> intent to offer non-systemd support based on the already working init scripts 
> that we ship. Therefor the first step is to make use of systemd backward 
> compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd 
> and non-systemd environments.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13433) RPM distribution improvements and known issues

[Nathaniel Tabernero (JIRA)]

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

Nathaniel Tabernero edited comment on CASSANDRA-13433 at 8/29/17 7:37 PM:
--

I've attached a patch file against cassandra-3.9 for creating a rpm which works 
on Centos 6.  At the time we upgraded Cassandra, version 3.9 was the latest 
stable version. This patch file includes a rpm spec file which has a dependency 
on python27 from the centos-release-scl repo. The python27 package will install 
python into an alternate location which will not conflict the Centos 6's 
default installed python 2.6 . Additionally, the spec file will modify the 
cqlsh script to use python 2.7.

Here are the steps we use to install Cassandra 3.9 on Centos 6.9 in our 
environment:
{panel}
#Install Java 8, then
sudo yum install centos-release-scl # install SCL repo
sudo yum localinstall cassandra-3.9-2.scl.el6.noarch.rpm #install custom build 
cassandra 3.9 rpm
sudo service cassandra start
sudo chkconfig cassandra on
{panel}

If this custom rpm is not available and cassandra 3.9 is already installed 
through other means, then: 
{panel}
sudo yum install centos-release-scl # install SCL repo
sudo yum install python27 # install Python 2.7
{panel}

Then, manually modify the cqlsh script.  Add the following lines after the 
comment header
{panel}
\# Enable python2.7 from centos 6 SCL 
source /opt/rh/python27/enable
{panel}

I hope this is helpful!



was (Author: ntabernero):
I've attached a patch file against cassandra-3.9 for creating a rpm which works 
on Centos 6.  At the time we upgraded Cassandra, version 3.9 was the latest 
stable version. This patch file includes a rpm spec file which has a dependency 
on python27 from the centos-release-scl repo. The python27 package will install 
python into an alternate location which will not conflict the Centos 6's 
default installed python 2.6 . Additionally, the spec file will modify the 
cqlsh script to use python 2.7.

Here are the steps we use to install Cassandra 3.9 on Centos 6.9 in our 
environment:
{panel}
#Install Java 8, then
sudo yum install centos-release-scl # install SCL repo
sudo yum localinstall cassandra-3.9-2.scl.el6.noarch.rpm #install custom build 
cassandra 3.9 rpm
sudo service cassandra start
sudo chkconfig cassandra on
{panel}

If this custom rpm is not available and cassandra 3.9 is already installed 
through other means, then: 
{panel}
sudo yum install centos-release-scl # install SCL repo
sudo yum install python27 # install Python 2.7
{panel}

Then, manually modify the cqlsh script.  Add the following lines after the 
comment header
{panel}
# Enable python2.7 from centos 6 SCL 
source /opt/rh/python27/enable
{panel}

I hope this is helpful!


> RPM distribution improvements and known issues
> --
>
> Key: CASSANDRA-13433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13433
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: cassandra-3.9-centos6.patch
>
>
> Starting with CASSANDRA-13252, new releases will be provided as both official 
> RPM and Debian packages.  While the Debian packages are already well 
> established with our user base, the RPMs just have been release for the first 
> time and still require some attention. 
> Feel free to discuss RPM related issues in this ticket and open a sub-task to 
> fill a bug report. 
> Please note that native systemd support will be implemented with 
> CASSANDRA-13148 and this is not strictly a RPM specific issue. We still 
> intent to offer non-systemd support based on the already working init scripts 
> that we ship. Therefor the first step is to make use of systemd backward 
> compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd 
> and non-systemd environments.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13433) RPM distribution improvements and known issues

[Nathaniel Tabernero (JIRA)]

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

Nathaniel Tabernero commented on CASSANDRA-13433:
-

I've attached a patch file against cassandra-3.9 for creating a rpm which works 
on Centos 6.  At the time we upgraded Cassandra, version 3.9 was the latest 
stable version. This patch file includes a rpm spec file which has a dependency 
on python27 from the centos-release-scl repo. The python27 package will install 
python into an alternate location which will not conflict the Centos 6's 
default installed python 2.6 . Additionally, the spec file will modify the 
cqlsh script to use python 2.7.

Here are the steps we use to install Cassandra 3.9 on Centos 6.9 in our 
environment:
{panel}
#Install Java 8, then
sudo yum install centos-release-scl # install SCL repo
sudo yum localinstall cassandra-3.9-2.scl.el6.noarch.rpm #install custom build 
cassandra 3.9 rpm
sudo service cassandra start
sudo chkconfig cassandra on
{panel}

If this custom rpm is not available and cassandra 3.9 is already installed 
through other means, then: 
{panel}
sudo yum install centos-release-scl # install SCL repo
sudo yum install python27 # install Python 2.7
{panel}

Then, manually modify the cqlsh script.  Add the following lines after the 
comment header
{panel}
# Enable python2.7 from centos 6 SCL 
source /opt/rh/python27/enable
{panel}

I hope this is helpful!


> RPM distribution improvements and known issues
> --
>
> Key: CASSANDRA-13433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13433
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>
> Starting with CASSANDRA-13252, new releases will be provided as both official 
> RPM and Debian packages.  While the Debian packages are already well 
> established with our user base, the RPMs just have been release for the first 
> time and still require some attention. 
> Feel free to discuss RPM related issues in this ticket and open a sub-task to 
> fill a bug report. 
> Please note that native systemd support will be implemented with 
> CASSANDRA-13148 and this is not strictly a RPM specific issue. We still 
> intent to offer non-systemd support based on the already working init scripts 
> that we ship. Therefor the first step is to make use of systemd backward 
> compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd 
> and non-systemd environments.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13756) StreamingHistogram is not thread safe

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13756:
-

I'm +1 on the snapshot version of the code. You may want to wait a day to see 
if [~krummas] has any additional feedback.

> StreamingHistogram is not thread safe
> -
>
> Key: CASSANDRA-13756
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13756
> Project: Cassandra
>  Issue Type: Bug
>Reporter: xiangzhou xia
>Assignee: Jeff Jirsa
> Fix For: 3.0.x, 3.11.x
>
>
> When we test C*3 in shadow cluster, we notice after a period of time, several 
> data node suddenly run into 100% cpu and stop process query anymore.
> After investigation, we found that threads are stuck on the sum() in 
> streaminghistogram class. Those are jmx threads that working on expose 
> getTombStoneRatio metrics (since jmx is kicked off every 3 seconds, there is 
> a chance that multiple jmx thread is access streaminghistogram at the same 
> time).  
> After further investigation, we find that the optimization in CASSANDRA-13038 
> led to a spool flush every time when we call sum(). Since TreeMap is not 
> thread safe, threads will be stuck when multiple threads visit sum() at the 
> same time.
> There are two approaches to solve this issue. 
> The first one is to add a lock to the flush in sum() which will introduce 
> some extra overhead to streaminghistogram.
> The second one is to avoid streaminghistogram to be access by multiple 
> threads. For our specific case, is to remove the metrics we added.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (CASSANDRA-13764) SelectTest.testMixedTTLOnColumnsWide is flaky

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa reassigned CASSANDRA-13764:
--

Assignee: Jeff Jirsa

> SelectTest.testMixedTTLOnColumnsWide is flaky
> -
>
> Key: CASSANDRA-13764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13764
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Jeff Jirsa
>Priority: Trivial
>
> {{org.apache.cassandra.cql3.validation.operations.SelectTest.testMixedTTLOnColumnsWide}}
>  is flaky. This is because it inserts rows and then asserts their contents 
> using {{ttl()}} in the select, but if the test is sufficiently slow, the 
> remaining ttl may change by the time the select is run. Anecdotally, 
> {{testSelectWithAlias}} in the same class uses a fudge factor of 1 second 
> that would fix all the failures I've seen, but it might make more sense to 
> measure the elapsed time in the test and calculate the acceptable variation 
> from that time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13711) Invalid writetime for null columns in cqlsh

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13711:


I saw him open it as CASSANDRA-13764 - let me fix it there just so we don't 
re-open this




> Invalid writetime for null columns in cqlsh
> ---
>
> Key: CASSANDRA-13711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13711
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> From the user list:
> https://lists.apache.org/thread.html/448731c029eee72e499fc6acd44d257d1671193f850a68521c2c6681@%3Cuser.cassandra.apache.org%3E
> {code}
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm create test -n 1 -s -v 3.0.10
> Current cluster is now: test
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm node1 cqlsh
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.10 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy', 
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.t ( a text primary key, b text );
> cqlsh> insert into test.t(a) values('z');
> cqlsh> insert into test.t(a) values('w');
> cqlsh> insert into test.t(a) values('e');
> cqlsh> insert into test.t(a) values('r');
> cqlsh> insert into test.t(a) values('t');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b | writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t | null | null
> (5 rows)
> cqlsh>
> cqlsh> insert into test.t(a,b) values('t','x');
> cqlsh> insert into test.t(a) values('b');
> cqlsh> select a,b, writetime (b) from test.t;
>  a | b| writetime(b)
> ---+--+--
>  z | null | null
>  e | null | null
>  r | null | null
>  w | null | null
>  t |x | 1500565131354883
>  b | null | 1500565131354883
> (6 rows)
> {code}
> Data on disk:
> {code}
> MacBook-Pro:~ jjirsa$ ~/.ccm/repository/3.0.14/tools/bin/sstabledump 
> /Users/jjirsa/.ccm/test/node1/data0/test/t-bed196006d0511e7904be9daad294861/mc-1-big-Data.db
> [
>   {
> "partition" : {
>   "key" : [ "z" ],
>   "position" : 0
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 20,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:54.818118Z" },
> "cells" : [ ]
>   }
> ]
>   },
>   {
> "partition" : {
>   "key" : [ "e" ],
>   "position" : 21
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 44,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:04.288547Z" },
> "cells" : [ ]
>   }
> ]
>   },
>   {
> "partition" : {
>   "key" : [ "r" ],
>   "position" : 45
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 68,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:08.991417Z" },
> "cells" : [ ]
>   }
> ]
>   },
>   {
> "partition" : {
>   "key" : [ "w" ],
>   "position" : 69
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 92,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:59.005382Z" },
> "cells" : [ ]
>   }
> ]
>   },
>   {
> "partition" : {
>   "key" : [ "t" ],
>   "position" : 93
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 120,
> "liveness_info" : { "tstamp" : "2017-07-20T15:38:51.354883Z" },
> "cells" : [
>   { "name" : "b", "value" : "x" }
> ]
>   }
> ]
>   },
>   {
> "partition" : {
>   "key" : [ "b" ],
>   "position" : 121
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 146,
> "liveness_info" : { "tstamp" : "2017-07-20T15:39:03.631297Z" },
> "cells" : [ ]
>   }
> ]
>   }
> ]MacBook-Pro:~ jjirsa$
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13752:


Short term (until you can upgrade), you probably want to avoid calling the 
{{getDroppableTombstoneRatio()}} mbean.

> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13752:
---
Resolution: Duplicate
Status: Resolved  (was: Patch Available)

> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Jay Zhuang (JIRA)]

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

Jay Zhuang commented on CASSANDRA-13785:


[~aweisberg] Thanks for the quick response.

{quote}
So you are the unlucky person to catch SafeMemoryWriter misbehaving. If we want 
our test hygiene to be good you would be the person to write a basic set of 
unit tests for it. Go through each external method in SafeMemoryWriter and test 
it's API (null handling, largest value, smallest value, negative value, 0) and 
internal state (0 length, empty buffer, full buffer, etc.).
{quote}
Make sense, I'll add more unittests.

{quote}
This will still hit the same issue if the decorated key size is larger than 
expected right? I know almost everyone uses fixed length keys, but it looks 
fragile to not at least fail fast if they use variable length keys or if the 
size changes in future iterations.
{quote}
Yes :(  It will fail the assert here: {{[assert entries.length() <= 
Integer.MAX_VALUE;|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L172]}}
 and trigger the same problem.

{quote}
This is a bug in SafeMemoryWriter.length()?
{quote}
I don't think so, maybe it's a bad name. 
{{[length()|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L81]}}
 means the current position. But if the memory longer than Int.MAX_VALUE, it 
moves the length() forward to only cover the Int.MAX_VALUE length, so we can 
only use the last Int.MAX_VALUE size. e.g. if memory size is {{10 + 
Int.MAX_VALUE}}, then the first length() is 10, if memory size is {{10 + 2 * 
Int.MAX_VALUE}}, the first length() is {{10 + Int.MAX_VALUE}}. I think the 
purpose is to support Int.MAX_VALUE memory, but not sure why, as it only used 
by {{IndexSummaryBuilder}}.

{quote}
Even if this throws AssertionError it still shouldn't leak memory right? We 
should log the error, but not leak. I think (I'll check) that we don't treat 
assertion failures as fatal and crash the process.
{quote}
It doesn't log the error, the compaction thread just fails silently. Here is 
the call stack (it's 3.0.14 with a few debugging code, so the line number might 
not exactly match):
{{noformat}}
at org.apache.cassandra.io.util.Memory.(Memory.java:82)
at org.apache.cassandra.io.util.SafeMemory.(SafeMemory.java:32)
at 
org.apache.cassandra.io.util.SafeMemoryWriter.(SafeMemoryWriter.java:31)
at 
org.apache.cassandra.io.sstable.IndexSummaryBuilder.(IndexSummaryBuilder.java:112)
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter$IndexWriter.(BigTableWriter.java:377)
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter.(BigTableWriter.java:84)
at 
org.apache.cassandra.io.sstable.format.big.BigFormat$WriterFactory.open(BigFormat.java:93)
at 
org.apache.cassandra.io.sstable.format.SSTableWriter.create(SSTableWriter.java:96)
at 
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.switchCompactionLocation(DefaultCompactionWriter.java:64)
at 
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.maybeSwitchWriter(CompactionAwareWriter.java:128)
at 
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:108)
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:195)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at 
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
at java.lang.Thread.run(Thread.java:745)
{{noformat}}
I think the leak should be because the {{writer.finish()}} is not called: 
[CompactionTask.java:206|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/compaction/CompactionTask.java#L206]

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: 

[jira] [Commented] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[JIRA]

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

Hannu Kröger commented on CASSANDRA-13752:
--

I'm happy as long as it's fixed! Thanks for the support here! :)

> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13752:


[~hkroger] thanks so much for the detailed report and your patience while we 
fix this right. Do you mind if I close this as a dupe of 13756, the new patches 
there should fix it (and ultimately, it's the same issue - it wasn't thread 
safe)?


> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13756) StreamingHistogram is not thread safe

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13756:


Pushed new branches up based on what we learned from 13752:


|| branch || utest || dtest ||
| [3.0|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13756] | [3.0 
circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.0-13756] | 
[3.0 
dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/224/]
 |
| [3.11|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13756] | 
[3.11 
circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.11-13756] | 
[3.11 
dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/225/]
 |




> StreamingHistogram is not thread safe
> -
>
> Key: CASSANDRA-13756
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13756
> Project: Cassandra
>  Issue Type: Bug
>Reporter: xiangzhou xia
>Assignee: Jeff Jirsa
> Fix For: 3.0.x, 3.11.x
>
>
> When we test C*3 in shadow cluster, we notice after a period of time, several 
> data node suddenly run into 100% cpu and stop process query anymore.
> After investigation, we found that threads are stuck on the sum() in 
> streaminghistogram class. Those are jmx threads that working on expose 
> getTombStoneRatio metrics (since jmx is kicked off every 3 seconds, there is 
> a chance that multiple jmx thread is access streaminghistogram at the same 
> time).  
> After further investigation, we find that the optimization in CASSANDRA-13038 
> led to a spool flush every time when we call sum(). Since TreeMap is not 
> thread safe, threads will be stuck when multiple threads visit sum() at the 
> same time.
> There are two approaches to solve this issue. 
> The first one is to add a lock to the flush in sum() which will introduce 
> some extra overhead to streaminghistogram.
> The second one is to avoid streaminghistogram to be access by multiple 
> threads. For our specific case, is to remove the metrics we added.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13752:


I'd rather just change it to a builder in 3.0 and 3.11 for safety in case 
someone else comes along and tries to misuse it again in the future?

I've got the 3.0 version done, working on 3.11 now. Would you do a second 
review with Jason just to be safe? 





> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Issue Comment Deleted] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13752:
---
Comment: was deleted

(was: I'd rather just change it to a builder in 3.0 and 3.11 for safety in case 
someone else comes along and tries to misuse it again in the future?

I've got the 3.0 version done, working on 3.11 now. Would you do a second 
review with Jason just to be safe? 



)

> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13752:


Let's just call this a dupe of 13756, and fix it all there.

I'm pushing changes to 3.0 and 3.11 that transform this into a builder, but 
also changes to CANONICAL for safety. If you have time, can you do a second 
review alongside Jason so we can squash this once and be confident it's fixed?

> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13819) Surprising under-documented behavior with DELETE...USING TIMESTAMP

[Eric Wolak (JIRA)]

Eric Wolak created CASSANDRA-13819:
--

 Summary: Surprising under-documented behavior with DELETE...USING 
TIMESTAMP
 Key: CASSANDRA-13819
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13819
 Project: Cassandra
  Issue Type: Bug
Reporter: Eric Wolak
Priority: Minor


While investigating differences between various Bigtable derivatives, I‘ve run 
into an odd behavior of Cassandra. I’m guessing this is intended behavior, but 
it's surprising enough to me that I think it should be explicitly documented.

Let‘s say I have a sensor device reporting data with timestamps. It has a great 
clock, so I use its timestamps in a USING TIMESTAMP clause in my INSERT 
statements. One day Jeff realizes that we had a hardware bug with the sensor, 
and data before timestamp T is incorrect. He issues a DELETE...USING TIMESTAMP 
T to remove the old data. In the meantime, Sam figures out a way to backfill 
the data, and she writes a job to insert corrected data into the same table. In 
keeping with the schema, her job issues INSERT...USING TIMESTAMP statememts, 
with timestamps before T (because that’s the time the data points correspond 
to). When testing her job, Sam discovers that the backfilled data isn‘t 
appearing in the database! In fact, there’s no way for her to insert data with 
a TIMESTAMP <= T, because the tombstone written by Jeff several days ago is 
masking them. How can Sam backfill the corrected data?

This behavior seems to match the HBase “Current Limitation” that Deletes Mask 
Puts, documented at http://hbase.apache.org/book.html#_deletes_mask_puts. 
Should the Cassandra docs also explicitly call-out this behavior?

Related:

http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutDeletes.html




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-13785:


New stuff and summarizing.
* So you are the unlucky person to catch SafeMemoryWriter misbehaving. If we 
want our test hygiene to be good you would be the person to write a basic set 
of unit tests for it. Go through each external method in SafeMemoryWriter and 
test it's API (null handling, largest value, smallest value, negative value, 0) 
and internal state (0 length, empty buffer, full buffer, etc.).
* This will still hit the same issue if the decorated key size is larger than 
expected right? I know almost everyone uses fixed length keys, but it looks 
fragile to not at least fail fast if they use variable length keys or if the 
size changes in future iterations.
* This is a bug in {{SafeMemoryWriter.length()}}?
* Even if this throws AssertionError it still shouldn't leak memory right? We 
should log the error, but not leak. I think (I'll check) that we don't treat 
assertion failures as fatal and crash the process.


> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13752) Corrupted SSTables created in 3.11

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-13752:
-

bq. we should be using a "builder" for StreamingHistogram
looks like we already do this in trunk

so lets just change to CANONICAL and do CASSANDRA-13756 - wdyt [~jjirsa]?

> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Blocker
> Fix For: 3.11.1
>
>
> We have discovered issues with corrupted SSTables. 
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 - 
> Cannot read sstable 
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
>  Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt, 
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug  7 08:37 
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug  7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra  10 Aug  7 08:37 
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug  7 08:37 
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra   75880 Aug  7 08:37 
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra   13762 Aug  7 08:37 
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra  882008 Aug  7 08:37 
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra  92 Aug  7 08:37 mc-6166-big-TOC.txt
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13363) Fix racy read command serialization

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13363:
-

LGTM and the failing dtest is passing for me locally now, so +1 assuming CI is 
still happy.

> Fix racy read command serialization
> ---
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
>  Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a 
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13363) Fix racy read command serialization

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-13363:

Status: Ready to Commit  (was: Patch Available)

> Fix racy read command serialization
> ---
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
>  Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a 
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-13785 at 8/29/17 5:48 PM:
-

Isn't this also a bug in SafeMemoryWriter? Length is supposed to be the amount 
of memory written not the size of the allocated buffer?


was (Author: aweisberg):
Isn't this also a bug in SafeMemoryWriter? Length is supposed to be the amount 
of memory written not the size of the allocated buffrer?

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-13785:


Isn't this also a bug in SafeMemoryWriter? Length is supposed to be the amount 
of memory written not the size of the allocated buffrer?

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13818) Add support for --hosts, --force, and subrange repair to incremental repair

[Blake Eggleston (JIRA)]

Blake Eggleston created CASSANDRA-13818:
---

 Summary: Add support for --hosts, --force, and subrange repair to 
incremental repair
 Key: CASSANDRA-13818
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13818
 Project: Cassandra
  Issue Type: Improvement
Reporter: Blake Eggleston
Assignee: Blake Eggleston


It should be possible to run incremental repair with nodes down, we just 
shouldn't promote the data to repaired afterwards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-13785:


Sure I'm looking at it now. What about the leak? Even if this fails it 
shouldn't leak memory right?

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13363) Fix racy read command serialization

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-13363:
--
Status: Patch Available  (was: In Progress)

> Fix racy read command serialization
> ---
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
>  Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a 
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13363) Fix racy read command serialization

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13363:
---

Thanks for the review. Pushed a commit addressing the issues to the same branch 
(and rebased on top of most recent 3.0 while at it). Tests scheduled/running: 
[utest|https://circleci.com/gh/iamaleksey/cassandra/17], 
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/223/].

> Fix racy read command serialization
> ---
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
>  Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a 
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13785) Compaction fails for SSTables with large number of keys

[Jay Zhuang (JIRA)]

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

Jay Zhuang commented on CASSANDRA-13785:


[~aweisberg] do you mind reviewing the patch?

> Compaction fails for SSTables with large number of keys
> ---
>
> Key: CASSANDRA-13785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13785
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Every a few minutes there're "LEAK DTECTED" messages in the log:
> {noformat}
> ERROR [Reference-Reaper:1] 2017-08-18 17:18:40,357 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3ed22d7) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1022568824:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:20:49,693 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6470405b) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@97898152:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> ERROR [Reference-Reaper:1] 2017-08-18 17:22:38,519 Ref.java:223 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@6fc4af5f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@1247404854:[Memory@[0..159b6ba4),
>  Memory@[0..d8123468)] was not released before the reference was garbage 
> collected
> {noformat}
> Debugged the issue and found it's triggered by failed compactions, if the 
> compacted SSTable has more than 51m {{Integer.MAX_VALUE / 40}}) keys, it will 
> fail to create the IndexSummary: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84].
> Cassandra compaction tried to compact every a few minutes and keeps failing.
> The root cause is while [creating 
> SafeMemoryWriter|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L112]
>  with {{> Integer.MAX_VALUE}} space, it returns the tailing 
> {{Integer.MAX_VALUE}} space 
> [SafeMemoryWriter.java:83|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/util/SafeMemoryWriter.java#L83],
>  which makes the first 
> [entries.length()|https://github.com/apache/cassandra/blob/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java#L173]
>  not 0. So the assert fails here: 
> [IndexSummary:84|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L84]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13700) Heartbeats can cause gossip information to go permanently missing on certain nodes

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13700:
-

pushed the minor fix as sha {{6b927783ba0777d3dd7c2c3311b246a8dbce5b59}} to 
2.1+.

> Heartbeats can cause gossip information to go permanently missing on certain 
> nodes
> --
>
> Key: CASSANDRA-13700
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13700
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Critical
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0, 2.1.19
>
>
> In {{Gossiper.getStateForVersionBiggerThan}}, we add the {{HeartBeatState}} 
> from the corresponding {{EndpointState}} to the {{EndpointState}} to send. 
> When we're getting state for ourselves, this means that we add a reference to 
> the local {{HeartBeatState}}. Then, once we've built a message (in either the 
> Syn or Ack handler), we send it through the {{MessagingService}}. In the case 
> that the {{MessagingService}} is sufficiently slow, the {{GossipTask}} may 
> run before serialization of the Syn or Ack. This means that when the 
> {{GossipTask}} acquires the gossip {{taskLock}}, it may increment the 
> {{HeartBeatState}} version of the local node as stored in the endpoint state 
> map. Then, when we finally serialize the Syn or Ack, we'll follow the 
> reference to the {{HeartBeatState}} and serialize it with a higher version 
> than we saw when constructing the Ack or Ack2.
> Consider the case where we see {{HeartBeatState}} with version 4 when 
> constructing an Ack and send it through the {{MessagingService}}. Then, we 
> add some piece of state with version 5 to our local {{EndpointState}}. If 
> {{GossipTask}} runs and increases the {{HeartBeatState}} version to 6 before 
> the {{MessageOut}} containing the Ack is serialized, the node receiving the 
> Ack will believe it is current to version 6, despite the fact that it has 
> never received a message containing the {{ApplicationState}} tagged with 
> version 5.
> I've reproduced in this in several versions; so far, I believe this is 
> possible in all versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

cassandra-dtest git commit: ninja-fix misspelled variable name

[jasobrown]

Repository: cassandra-dtest
Updated Branches:
  refs/heads/master 2ad557dff -> 19b6613d7


ninja-fix misspelled variable name


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

Branch: refs/heads/master
Commit: 19b6613d7c1cd220432af1157b07dbba8fd4a0bb
Parents: 2ad557d
Author: Jason Brown 
Authored: Tue Aug 29 08:52:25 2017 -0700
Committer: Jason Brown 
Committed: Tue Aug 29 08:52:25 2017 -0700

--
 bootstrap_test.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/19b6613d/bootstrap_test.py
--
diff --git a/bootstrap_test.py b/bootstrap_test.py
index 54c49c1..d29390c 100644
--- a/bootstrap_test.py
+++ b/bootstrap_test.py
@@ -150,7 +150,7 @@ class TestBootstrap(BaseBootstrapTest):
 cluster = self.cluster
 yaml_opts = {'streaming_keep_alive_period_in_secs': 2}
 if cluster.version() < '4.0':
-yamp_opts['streaming_socket_timeout_in_ms'] = 1000
+yaml_opts['streaming_socket_timeout_in_ms'] = 1000
 cluster.set_configuration_options(values=yaml_opts)
 
 # Create a single node cluster


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

[3/8] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[jasobrown]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: e817c83bc06b7b23aa94c8cd1099103b129801a5
Parents: a7cb009 4b52a68
Author: Jason Brown 
Authored: Tue Aug 29 08:28:09 2017 -0700
Committer: Jason Brown 
Committed: Tue Aug 29 08:28:28 2017 -0700

--
 src/java/org/apache/cassandra/gms/Gossiper.java | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e817c83b/src/java/org/apache/cassandra/gms/Gossiper.java
--


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

[8/8] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[jasobrown]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 38ae30685106d745c070114ad9916a9dfcc4ebaf
Parents: 6e395dd 031d76c
Author: Jason Brown 
Authored: Tue Aug 29 08:37:22 2017 -0700
Committer: Jason Brown 
Committed: Tue Aug 29 08:37:22 2017 -0700

--

--



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

[5/8] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[jasobrown]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: e817c83bc06b7b23aa94c8cd1099103b129801a5
Parents: a7cb009 4b52a68
Author: Jason Brown 
Authored: Tue Aug 29 08:28:09 2017 -0700
Committer: Jason Brown 
Committed: Tue Aug 29 08:28:28 2017 -0700

--
 src/java/org/apache/cassandra/gms/Gossiper.java | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e817c83b/src/java/org/apache/cassandra/gms/Gossiper.java
--


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

[7/8] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[jasobrown]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: 031d76c9b4bcf7a3da735cc15d32b5a88be7aeda
Parents: 35dc3b6 e817c83
Author: Jason Brown 
Authored: Tue Aug 29 08:36:58 2017 -0700
Committer: Jason Brown 
Committed: Tue Aug 29 08:36:58 2017 -0700

--

--



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