[jira] [Updated] (CASSANDRA-13873) Ref bug in Scrub

[Joel Knighton (JIRA)]

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

Joel Knighton updated CASSANDRA-13873:
--
Reproduced In: 3.11.0, 3.10, 4.0  (was: 3.10, 3.11.0, 4.0)
   Status: Patch Available  (was: In Progress)

It looks like this situation can occur when referencing canonical sstables. As 
far as I can tell, the issue reproduces only when we have an sstable in a 
lifecycle transaction with no referencers other than its selfref. If the 
lifecycle transaction updates this sstable, we'll put a new instance of the 
sstable reader in the tracker. This causes no problems when getting live 
sstables, but the canonical sstables can also include sstable readers from the 
compacting set. In this case, the sstable reader that got updated will still be 
in the compacting set, but we won't be able to reference it when we try to 
select and reference canonical sstables, since its instance tidier has run when 
its last ref was released in the lifecycle transaction. Note that the global 
tidier doesn't run, since the updated sstable reader is still referenced. With 
the reproduction provided above in the multiple scrub, the scrubs will 
eventually proceed once the lifecycle transaction finishes, since it will put 
an updated sstablereader in the tracker. If there is a situation where a 
lifecyce transaction needed to select canonical sstables to proceed, this could 
cause a deadlock.

I pushed a branch at 
[c13873-2.2|https://github.com/jkni/cassandra/commit/ba70f70d97f648037e742a16bfdf1c8002d2be9c]
 that implements the simplest fix I can think of. The patch references the 
original sstables involved in a lifecycle transaction when we create the 
transaction, releasing these references whenever we do postCleanup or cancel an 
sstable reader from a transaction. I merged this forward and tests came back 
clean on all active branches. I'm not sure if there is some existing mechanism 
that should cover this case - maybe [~krummas] knows from reviewing 
[CASSANDRA-9699]?

> Ref bug in Scrub
> 
>
> Key: CASSANDRA-13873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13873
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Joel Knighton
>Priority: Critical
>
> I'm hitting a Ref bug when many scrubs run against a node.  This doesn't 
> happen on 3.0.X.  I'm not sure if/if not this happens with compactions too 
> but I suspect it does.
> I'm not seeing any Ref leaks or double frees.
> To Reproduce:
> {quote}
> ./tools/bin/cassandra-stress write n=10m -rate threads=100
> ./bin/nodetool scrub
> #Ctrl-C
> ./bin/nodetool scrub
> #Ctrl-C
> ./bin/nodetool scrub
> #Ctrl-C
> ./bin/nodetool scrub
> {quote}
> Eventually in the logs you get:
> WARN  [RMI TCP Connection(4)-127.0.0.1] 2017-09-14 15:51:26,722 
> NoSpamLogger.java:97 - Spinning trying to capture readers 
> [BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-5-big-Data.db'),
>  
> BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-32-big-Data.db'),
>  
> BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-31-big-Data.db'),
>  
> BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-29-big-Data.db'),
>  
> BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-27-big-Data.db'),
>  
> BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-26-big-Data.db'),
>  
> BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-20-big-Data.db')],
> *released: 
> [BigTableReader(path='/home/jake/workspace/cassandra2/data/data/keyspace1/standard1-2eb5c780998311e79e09311efffdcd17/mc-5-big-Data.db')],*
>  
> This released table has a selfRef of 0 but is in the Tracker



--
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-13897) nodetool compact and flush fail with "error: null"

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-13897:
--

Thanks for the explanation [~blambov], it looks like we should continue 
rounding to powers of two for the chunk cache. 

I've extended the [patch|https://github.com/stef1927/cassandra/tree/13897-3.11] 
to either round up or down [~snazy]. This can be configured via a yaml property 
that it only documented in config, not in the actual yaml file. This property 
is called {{file_cache_round_up}} and by default it will be false when the disk 
optimization strategy is ssd, therefore rounding down, and it will be true when 
it is set to spinning, therefore rounding up only for spinning disks.


> nodetool compact and flush fail with "error: null"
> --
>
> Key: CASSANDRA-13897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13897
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: * Apache Cassandra 3.11.0
> * Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 
> x86_64 x86_64 GNU/Linux
> * jdk1.8.0_144
>Reporter: Jacob Rhoden
>Assignee: Stefania
>Priority: Minor
>
> {{nodetool flush}} and {{nodetool compact}} return an error message that is 
> not clear. This could probably be improved. Both of my two nodes return this 
> error.
> {{nodetool flush}} Will return this error the first 2-3 times you invoke it, 
> then the error temporarily disappears. {{nodetool compress}} always returns 
> this error message no matter how many times you invoke it.
> I have tried deleting saved_caches, commit logs, doing nodetool 
> compact/rebuild/scrub, and nothing seems to remove the error. 
> {noformat}
> cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
>   at 
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
>   at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
>   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 
> 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:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

-
To unsubscribe, e-mail: 

[jira] [Commented] (CASSANDRA-13967) Hints for hosts no longer part of the ring remain in the hints directory

[Andrew Whang (JIRA)]

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

Andrew Whang commented on CASSANDRA-13967:
--

It seems nodetool removenode and assassinate both successfully removes the 
hints for the node being removed. I do see accumulated hints for invalid hosts, 
just not sure how to reproduce it. Will close this ticket if unable to repro.

> Hints for hosts no longer part of the ring remain in the hints directory
> 
>
> Key: CASSANDRA-13967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13967
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Andrew Whang
>Priority: Minor
>
> I find the hints directory grows over time as hosts are decommissioned 
> because the hints for the old hosts remain undelivered/unremoved.



--
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-13475) First version of pluggable storage engine API.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-13475:
---

[~bdeggleston], makes sense, I will come up with a smaller patch, to 
demonstrate the usage.

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



--
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-13291) Replace usages of MessageDigest with Guava's Hasher

[Michael Kjellman (JIRA)]

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

Michael Kjellman edited comment on CASSANDRA-13291 at 10/18/17 8:34 PM:


Alright, after chatting a bit with Sam and Jason I've pushed up a new squashed 
commit that reverts the MD5 hasher usage in {{RandomPartitioner}} and 
{{GuidGenerator}} back to the thread local (and added a comment). Additionally, 
I pulled in the change Sam has for CASSANDRA-13964 that adds an additional MD5 
MessageDigest thread local to the {{RandomPartitioner}} class itself.

# In the interest of "if it's not broke, don't fix it", leaving the two direct 
usages of MessageDigest (as my first iterations of this change did) (via a 
thread local) for {{RandomPartioner}} feels like the most sane thing to do as 
RandomPartitioner will never not be MD5 and it's very difficult to quantify how 
behavior and performance might change when switching to Guava's Hasher for this 
use case
# Functionally, this means the original intent of this ticket can still be 
fully realized, which is to set the foundation for ultimately changing the 
usage of MD5 digests in the rest of the codebase to another hashing function 
with minimal LoC required to implement that in the near future
# I smoke tested a build with the latest merged set of changes with ccm and 
things look good


was (Author: mkjellman):
Alright, after chatting a bit with Sam and Jason I've pushed up a new squashed 
commit that reverts the MD5 hasher usage in {{RandomPartitioner}} and 
{{GuidGenerator}} back to the thread local (and added a comment). Additionally, 
I pulled in the change Sam has for CASSANDRA-13964 that adds an additional MD5 
MessageDigest thread local to the {{RandomPartitioner}} class itself.

# In the interest of "if it's not broke, don't fix it", leaving the two direct 
usages of MessageDigest (as my first iterations of this change did) (via a 
thread local) for {{RandomPartioner}} feels like the most sane thing to do as 
RandomPartitioner will never not be MD5 and it's very difficult to quantify how 
behavior and performance might change when switching to Guava's Hasher for this 
use case
# Functionally, this means the original intent of this ticket can still be 
fully realized, which is to set the foundation for ultimately changing the 
usage of MD5 digests in the rest of the codebase to another hashing function 
with minimal LoC required to implement that in the near future

> Replace usages of MessageDigest with Guava's Hasher
> ---
>
> Key: CASSANDRA-13291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13291
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: CASSANDRA-13291-trunk.diff
>
>
> During my profiling of C* I frequently see lots of aggregate time across 
> threads being spent inside the MD5 MessageDigest implementation. Given that 
> there are tons of modern alternative hashing functions better than MD5 
> available -- both in terms of providing better collision resistance and 
> actual computational speed -- I wanted to switch out our usage of MD5 for 
> alternatives (like adler128 or murmur3_128) and test for performance 
> improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  
> switching out the hashing function to something like adler128 or murmur3_128 
> (for example) -- which don't ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest 
> directly in favor of Hasher from Guava. This means going forward we can 
> change a single line of code to switch the hashing algorithm being used 
> (assuming there is an implementation in Guava).



--
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-13291) Replace usages of MessageDigest with Guava's Hasher

[Michael Kjellman (JIRA)]

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

Michael Kjellman edited comment on CASSANDRA-13291 at 10/18/17 8:31 PM:


Alright, after chatting a bit with Sam and Jason I've pushed up a new squashed 
commit that reverts the MD5 hasher usage in {{RandomPartitioner}} and 
{{GuidGenerator}} back to the thread local (and added a comment). Additionally, 
I pulled in the change Sam has for CASSANDRA-13964 that adds an additional MD5 
MessageDigest thread local to the {{RandomPartitioner}} class itself.

# In the interest of "if it's not broke, don't fix it", leaving the two direct 
usages of MessageDigest (as my first iterations of this change did) (via a 
thread local) for {{RandomPartioner}} feels like the most sane thing to do as 
RandomPartitioner will never not be MD5 and it's very difficult to quantify how 
behavior and performance might change when switching to Guava's Hasher for this 
use case
# Functionally, this means the original intent of this ticket can still be 
fully realized, which is to set the foundation for ultimately changing the 
usage of MD5 digests in the rest of the codebase to another hashing function 
with minimal LoC required to implement that in the near future


was (Author: mkjellman):
Alright, after chatting a bit with Sam and Jason I've pushed up a new squashed 
commit that reverts the MD5 hasher usage in {{RandomPartitioner}} and 
{{GuidGenerator}} back to the thread local (and added a comment). Additionally, 
I pulled in the change Sam has for 13964 that adds an additional MD5 
MessageDigest thread local to the {{RandomPartitioner}} class itself.

# In the interest of "if it's not broke, don't fix it", leaving the two direct 
usages of MessageDigest (as my first iterations of this change did) (via a 
thread local) for {{RandomPartioner}} feels like the most sane thing to do as 
RandomPartitioner will never not be MD5 and it's very difficult to quantify how 
behavior and performance might change when switching to Guava's Hasher for this 
use case
# Functionally, this means the original intent of this ticket can still be 
fully realized, which is to set the foundation for ultimately changing the 
usage of MD5 digests in the rest of the codebase to another hashing function 
with minimal LoC required to implement that in the near future

> Replace usages of MessageDigest with Guava's Hasher
> ---
>
> Key: CASSANDRA-13291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13291
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: CASSANDRA-13291-trunk.diff
>
>
> During my profiling of C* I frequently see lots of aggregate time across 
> threads being spent inside the MD5 MessageDigest implementation. Given that 
> there are tons of modern alternative hashing functions better than MD5 
> available -- both in terms of providing better collision resistance and 
> actual computational speed -- I wanted to switch out our usage of MD5 for 
> alternatives (like adler128 or murmur3_128) and test for performance 
> improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  
> switching out the hashing function to something like adler128 or murmur3_128 
> (for example) -- which don't ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest 
> directly in favor of Hasher from Guava. This means going forward we can 
> change a single line of code to switch the hashing algorithm being used 
> (assuming there is an implementation in Guava).



--
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-13291) Replace usages of MessageDigest with Guava's Hasher

[Michael Kjellman (JIRA)]

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

Michael Kjellman commented on CASSANDRA-13291:
--

Alright, after chatting a bit with Sam and Jason I've pushed up a new squashed 
commit that reverts the MD5 hasher usage in {{RandomPartitioner}} and 
{{GuidGenerator}} back to the thread local (and added a comment). Additionally, 
I pulled in the change Sam has for 13964 that adds an additional MD5 
MessageDigest thread local to the {{RandomPartitioner}} class itself.

# In the interest of "if it's not broke, don't fix it", leaving the two direct 
usages of MessageDigest (as my first iterations of this change did) (via a 
thread local) for {{RandomPartioner}} feels like the most sane thing to do as 
RandomPartitioner will never not be MD5 and it's very difficult to quantify how 
behavior and performance might change when switching to Guava's Hasher for this 
use case
# Functionally, this means the original intent of this ticket can still be 
fully realized, which is to set the foundation for ultimately changing the 
usage of MD5 digests in the rest of the codebase to another hashing function 
with minimal LoC required to implement that in the near future

> Replace usages of MessageDigest with Guava's Hasher
> ---
>
> Key: CASSANDRA-13291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13291
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: CASSANDRA-13291-trunk.diff
>
>
> During my profiling of C* I frequently see lots of aggregate time across 
> threads being spent inside the MD5 MessageDigest implementation. Given that 
> there are tons of modern alternative hashing functions better than MD5 
> available -- both in terms of providing better collision resistance and 
> actual computational speed -- I wanted to switch out our usage of MD5 for 
> alternatives (like adler128 or murmur3_128) and test for performance 
> improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  
> switching out the hashing function to something like adler128 or murmur3_128 
> (for example) -- which don't ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest 
> directly in favor of Hasher from Guava. This means going forward we can 
> change a single line of code to switch the hashing algorithm being used 
> (assuming there is an implementation in Guava).



--
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-13475) First version of pluggable storage engine API.

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13475:
-

I mean something more narrowly scoped. That rocksdb branch is several months of 
work interspersed with commits merged in from upstream.

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



--
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-13967) Hints for hosts no longer part of the ring remain in the hints directory

[Andrew Whang (JIRA)]

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

Andrew Whang commented on CASSANDRA-13967:
--

nodetool truncatehints is one way to remove these stale hints, but it would be 
nice for the system to automatically detect and remove stale hints (for target 
hosts no longer part of the ring).

> Hints for hosts no longer part of the ring remain in the hints directory
> 
>
> Key: CASSANDRA-13967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13967
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Andrew Whang
>Priority: Minor
>
> I find the hints directory grows over time as hosts are decommissioned 
> because the hints for the old hosts remain undelivered/unremoved.



--
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-13967) Hints for hosts no longer part of the ring remain in the hints directory

[Andrew Whang (JIRA)]

Andrew Whang created CASSANDRA-13967:


 Summary: Hints for hosts no longer part of the ring remain in the 
hints directory
 Key: CASSANDRA-13967
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13967
 Project: Cassandra
  Issue Type: Bug
  Components: Coordination
Reporter: Andrew Whang
Priority: Minor


I find the hints directory grows over time as hosts are decommissioned because 
the hints for the old hosts remain undelivered/unremoved.



--
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-13966) UDAs that instantiate UDTs break after restart

[Benjamin Shen (JIRA)]

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

Benjamin Shen updated CASSANDRA-13966:
--
Environment: Successfully reproducible on a single-node Mac OS X Yosemite 
10.10.5 cluster and a 6-node 2-DC CentOS 6.9 cluster.  (was: Successfully 
reproducible on a single-node Mac OS X Yosemite 10.10.5 cluster and a 6-node 
CentOS 6.9 cluster.)

> UDAs that instantiate UDTs break after restart
> --
>
> Key: CASSANDRA-13966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13966
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Successfully reproducible on a single-node Mac OS X 
> Yosemite 10.10.5 cluster and a 6-node 2-DC CentOS 6.9 cluster.
>Reporter: Benjamin Shen
> Fix For: 3.11.x
>
>
> When testing performance optimizations for for UDAs, I noticed that, when 
> instantiated using udfContext, newly created UDTs would cause a UDA to break, 
> but ONLY after restart. This is pretty concern for us to deploy UDAs in a 
> production setting, as it feels like a consistency error.
> When run without restarting Cassandra, this CQL script produces no errors and 
> the expected result:
> {code}-- Create and USE your own keyspace
> CREATE TYPE testing_type (
> a int
> );
> CREATE OR REPLACE FUNCTION
> testing_state (
> state int
> )
> CALLED ON NULL INPUT RETURNS 
> int
> LANGUAGE java AS
> '
> return state+1;
> ';
> CREATE OR REPLACE FUNCTION
> testing_final(state int)
> CALLED ON NULL INPUT RETURNS int LANGUAGE java AS
> '
> udfContext.newUDTValue("testing_type");
> return state;';
> CREATE OR REPLACE AGGREGATE testing_uda()
> SFUNC testing_state
> STYPE int
> FINALFUNC testing_final
> INITCOND 0;
> CREATE TABLE IF NOT EXISTS testing_table (
> "a" int,
> PRIMARY KEY ("a")
> ) WITH gc_grace_seconds=0
> AND COMPACTION={'class': 'TimeWindowCompactionStrategy', 
> 'compaction_window_unit': 'DAYS', 'compaction_window_size': '1'};
> SELECT testing_uda() FROM testing_table;{code}
> However, if you then restart Cassandra on the local node and rerun the last 
> line again:
> {code}
> -- Restart Cassandra after running previous script
> cqlsh:my_keyspace> SELECT testing_uda() FROM testing_table;
> Traceback (most recent call last):
>   File "/Users/bshen/cassandra-trunk/bin/cqlsh.py", line 1044, in 
> perform_simple_statement
> result = future.result()
>   File 
> "/Users/bshen/cassandra-trunk/bin/../lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
>  line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'phoneid.testing_final[int]' failed: 
> java.lang.NullPointerException"
> {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-13966) UDAs that instantiate UDTs break after restart

[Benjamin Shen (JIRA)]

Benjamin Shen created CASSANDRA-13966:
-

 Summary: UDAs that instantiate UDTs break after restart
 Key: CASSANDRA-13966
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13966
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Successfully reproducible on a single-node Mac OS X 
Yosemite 10.10.5 cluster and a 6-node CentOS 6.9 cluster.
Reporter: Benjamin Shen
 Fix For: 3.11.x


When testing performance optimizations for for UDAs, I noticed that, when 
instantiated using udfContext, newly created UDTs would cause a UDA to break, 
but ONLY after restart. This is pretty concern for us to deploy UDAs in a 
production setting, as it feels like a consistency error.

When run without restarting Cassandra, this CQL script produces no errors and 
the expected result:
{code}-- Create and USE your own keyspace

CREATE TYPE testing_type (
a int
);
CREATE OR REPLACE FUNCTION
testing_state (
state int
)
CALLED ON NULL INPUT RETURNS 
int
LANGUAGE java AS
'
return state+1;
';


CREATE OR REPLACE FUNCTION
testing_final(state int)
CALLED ON NULL INPUT RETURNS int LANGUAGE java AS
'
udfContext.newUDTValue("testing_type");
return state;';


CREATE OR REPLACE AGGREGATE testing_uda()
SFUNC testing_state
STYPE int
FINALFUNC testing_final
INITCOND 0;


CREATE TABLE IF NOT EXISTS testing_table (
"a" int,
PRIMARY KEY ("a")
) WITH gc_grace_seconds=0
AND COMPACTION={'class': 'TimeWindowCompactionStrategy', 
'compaction_window_unit': 'DAYS', 'compaction_window_size': '1'};

SELECT testing_uda() FROM testing_table;{code}

However, if you then restart Cassandra on the local node and rerun the last 
line again:
{code}
-- Restart Cassandra after running previous script
cqlsh:my_keyspace> SELECT testing_uda() FROM testing_table;
Traceback (most recent call last):
  File "/Users/bshen/cassandra-trunk/bin/cqlsh.py", line 1044, in 
perform_simple_statement
result = future.result()
  File 
"/Users/bshen/cassandra-trunk/bin/../lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
 line 3826, in result
raise self._final_exception
FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
message="execution of 'phoneid.testing_final[int]' failed: 
java.lang.NullPointerException"
{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-13475) First version of pluggable storage engine API.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-13475:
---

Sure, here is the implementation of the RocksDB based storage engine, and how 
we integrate it with other parts in Cassandra. 
https://github.com/Instagram/cassandra/commits/rocks_3.0

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



--
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-13475) First version of pluggable storage engine API.

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13475:
-

Could you add some code showing how you intend to integrate this with C*? The 
linked branch is just the proposed api, which is kind of difficult to talk 
about in isolation

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



--
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-13907) Versioned documentation on cassandra.apache.org

[Murukesh Mohanan (JIRA)]

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

Murukesh Mohanan commented on CASSANDRA-13907:
--

As a POC, I created a GitHub Pages site: 
https://murukeshm.github.io/cassandra/3.9/ (check the dropdown near the 
copyright notice at the bottom of the page). The commands I used to create them 
are in https://github.com/murukeshm/cassandra/blob/gh-pages/gen.sh It's a bit 
hacky: inserting a {{}} for versions after the HTML docs have been 
generated, and I haven't created a central index page yet, but it can serve as 
a baseline.

> Versioned documentation on cassandra.apache.org
> ---
>
> Key: CASSANDRA-13907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13907
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Murukesh Mohanan
>Priority: Minor
>
> Services like https://readthedocs.org and http://www.javadoc.io/ make it easy 
> to browse the documentation for a particular version or commit of various 
> open source projects. It would be nice to be able to browse the docs for a 
> particular release on http://cassandra.apache.org/doc/.
> Currently it seems only CQL has this at http://cassandra.apache.org/doc/old/.



--
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-13965) SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt produces flaky tests

[JIRA]

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

Andrés de la Peña updated CASSANDRA-13965:
--
Status: Patch Available  (was: In Progress)

> SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt produces flaky tests
> ---
>
> Key: CASSANDRA-13965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13965
> Project: Cassandra
>  Issue Type: Bug
>  Components: Secondary Indexes, Testing
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Minor
> Fix For: 4.x
>
>
> The methods 
> [{{SecondaryIndexManagerTest.assertMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L554-L557]
>  and 
> [{{SecondaryIndexManagerTest.assertNotMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L559-L562]
>  produce occasional test failures. 
> These methods assume that there aren't any other indexes in the 
> {{system.IndexInfo}} table than those created by the calling test. However, 
> it is possible to find indexes built for other tests (not only 
> {{SecondaryIndexManagerTest}}) that rely on {{CQLTester.afterTest}} to 
> cleanup to drop their created indexes, because this method is asynchronous. 
> So, it is possible to reach the 
> {{SecondaryIndexManagerTest.assert(Not)MarkedAsBuilt}} calls before the 
> indexes created by the previous test have been cleaned up.



--
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-13965) SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt produces flaky tests

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-13965:
---

[Here|https://github.com/apache/cassandra/compare/trunk...adelapena:13965-trunk]
 is a patch modifying the methods to only verify the presence/absence in 
{{system.IndexInfo}} table of the index of interest.

> SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt produces flaky tests
> ---
>
> Key: CASSANDRA-13965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13965
> Project: Cassandra
>  Issue Type: Bug
>  Components: Secondary Indexes, Testing
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Minor
> Fix For: 4.x
>
>
> The methods 
> [{{SecondaryIndexManagerTest.assertMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L554-L557]
>  and 
> [{{SecondaryIndexManagerTest.assertNotMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L559-L562]
>  produce occasional test failures. 
> These methods assume that there aren't any other indexes in the 
> {{system.IndexInfo}} table than those created by the calling test. However, 
> it is possible to find indexes built for other tests (not only 
> {{SecondaryIndexManagerTest}}) that rely on {{CQLTester.afterTest}} to 
> cleanup to drop their created indexes, because this method is asynchronous. 
> So, it is possible to reach the 
> {{SecondaryIndexManagerTest.assert(Not)MarkedAsBuilt}} calls before the 
> indexes created by the previous test have been cleaned up.



--
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-13965) SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt produces flaky tests

[JIRA]

Andrés de la Peña created CASSANDRA-13965:
-

 Summary: SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt 
produces flaky tests
 Key: CASSANDRA-13965
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13965
 Project: Cassandra
  Issue Type: Bug
  Components: Secondary Indexes, Testing
Reporter: Andrés de la Peña
Assignee: Andrés de la Peña
Priority: Minor
 Fix For: 4.x


The methods 
[{{SecondaryIndexManagerTest.assertMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L554-L557]
 and 
[{{SecondaryIndexManagerTest.assertNotMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L559-L562]
 produce occasional test failures. 

These methods assume that there aren't any other indexes in the 
{{system.IndexInfo}} table than those created by the calling test. However, it 
is possible to find indexes built for other tests (not only 
{{SecondaryIndexManagerTest}}) that rely on {{CQLTester.afterTest}} to cleanup 
to drop their created indexes, because this method is asynchronous. So, it is 
possible to reach the {{SecondaryIndexManagerTest.assert(Not)MarkedAsBuilt}} 
calls before the indexes created by the previous test have been cleaned up.



--
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-13475) First version of pluggable storage engine API.

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13475:


Can we really get away designing a StorageEngine interface that expects 
ColumnFamilyStore instances for most actions? Actually the defined methods look 
like operations on the CFS to me, so it's a bit unclear how the implementation 
would be different between engines. 

I'd also suggest to clearly define the term "storage engine" first. What are 
the properties and guarantees? How does the life-cycle of such an engine look 
like? What are the possible (error) states?

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



--
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-13425) nodetool refresh should try to insert new sstables in existing leveling

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-13425:
-

finally got around to reviving this - I renamed the ACS method to 
{{prepareForAddition(sstables)}} as it is not unthinkable that for example TWCS 
might also want to do some preprocessing of the added sstables (splitting them 
by time for example), wdyt [~pauloricardomg]?

https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/382/
https://circleci.com/gh/krummas/cassandra/153

> nodetool refresh should try to insert new sstables in existing leveling
> ---
>
> Key: CASSANDRA-13425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13425
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> Currently {{nodetool refresh}} sets level to 0 on all new sstables, instead 
> we could try to find gaps in the existing leveling and insert them there.



--
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-13425) nodetool refresh should try to insert new sstables in existing leveling

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13425:

Status: Patch Available  (was: Open)

> nodetool refresh should try to insert new sstables in existing leveling
> ---
>
> Key: CASSANDRA-13425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13425
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> Currently {{nodetool refresh}} sets level to 0 on all new sstables, instead 
> we could try to find gaps in the existing leveling and insert them there.



--
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-10857) Allow dropping COMPACT STORAGE flag from tables in 3.X

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10857:
--

I definitively like the approach of the patch, and it looks largely good.

As we discussed offline, we should test 2ndary indexes. Other than that, I have 
a few smaller remarks/nits that I'm going to list below, but I took the liberty 
to push 3 commits 
[here|https://github.com/pcmanus/cassandra/commits/10857-review] fixing those 
to move faster. Feel free to push back on some of it, but here's what those 
commit do:
* The first commit has various nits, including some around making language a 
bit more consistent. It also toy around the {{validateColumnFamily}} a bit: I 
figured that since we were calling it most of the time with the thrid parameter 
being {{false}}, we could have an override without that third argument. Then it 
occured to me that moving those methods back to {{ThriftValidation}} would 
remove quite a bit from the diff of this ticket, which made it easier to review 
so I did that. If you care about those methods being in {{Schema}}, I can move 
them back again, and I agree on principle that {{Schema}} is a better home for 
them, but it's all fixed in trunk and 3.x branches are in maintenance mode, so 
felt like minimizing code moved around was a decent idea; ¯\_(ツ)_/¯.
* In the parser, I was a bit worried about allowing empty strings in 
{{QUOTED_NAME}} directly, because that is used in very many places and it felt 
hard/error prone to check all impacted places (and I think some places were 
missing in the patch; typically, I don't think we should let user add column 
with empty names but it doesn't seem ALTER TABLE was preventing that). I 
suggest lowering that risk by limiting the places where we do allow this 
directly in the parser.  Thanksfully, that's reasonably easy because the parser 
already had the {{cident}}, which is used in place where we could get a 
thrift-created column name (as those required a special handling), and it's 
exactly the same places we want to support here. This is the 2nd commit.
* The patch mentions in a number of places that schema changes were not allowed 
in the no-compact mode, which sounds fine, but I didn't find the place where 
that was enforced.  So I added it in {{SchemaAlteringStatement}} directly (and 
I've let changes on keyspaces/non compact tables go because no real reason to 
refuse them).  That's the third commit.  

The last (but not least) remark is around the {{NEWS.txt}} changes. First, as 
it's in the section for 3.0.15, I'm not sure having details there is the best 
place. Second, some of it will be confusing to users because things like 
"sparse/dense" and "compact value columns" are stuffs we use internally but 
aren't something users know about. We can rephrase to make it 
user-understandable, but that will expand the whole section, and back to the 
first point: not the right place for that.

Tl;dr, what I think we should do is shrink that {{NEWS.txt}} section (just say 
we've added DROP COMPACT STORAGE and a new mode to make transitions easier) and 
link to a proper documentation section (to be written).  I'll note that the new 
doc isn't in 3.0 so I the new section will have to be added to a 3.11 patch, 
but it doesn't feel like a big deal to have the 3.0 news file point to the 3.11 
documentation.


> Allow dropping COMPACT STORAGE flag from tables in 3.X
> --
>
> Key: CASSANDRA-10857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10857
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL, Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x
>
>
> Thrift allows users to define flexible mixed column families - where certain 
> columns would have explicitly pre-defined names, potentially non-default 
> validation types, and be indexed.
> Example:
> {code}
> create column family foo
> and default_validation_class = UTF8Type
> and column_metadata = [
> {column_name: bar, validation_class: Int32Type, index_type: KEYS},
> {column_name: baz, validation_class: UUIDType, index_type: KEYS}
> ];
> {code}
> Columns named {{bar}} and {{baz}} will be validated as {{Int32Type}} and 
> {{UUIDType}}, respectively, and be indexed. Columns with any other name will 
> be validated by {{UTF8Type}} and will not be indexed.
> With CASSANDRA-8099, {{bar}} and {{baz}} would be mapped to static columns 
> internally. However, being {{WITH COMPACT STORAGE}}, the table will only 
> expose {{bar}} and {{baz}} columns. Accessing any dynamic columns (any column 
> not named {{bar}} and {{baz}}) right now requires going through Thrift.

[jira] [Commented] (CASSANDRA-13964) Tracing interferes with digest requests when using RandomPartitioner

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13964:
-

I'm +1 on the patch and dtest. I ran the dtest w/o the patch can confirmed the 
failure, then with and confirmed success.

The only minor nit I have is on the dtest where you changed the {{prepare}} 
function. Maybe I'm missing something, but couldn't

{code}
if not random_partitioner:

cluster.set_partitioner("org.apache.cassandra.dht.Murmur3Partitioner")
else:
if random_partitioner:

cluster.set_partitioner("org.apache.cassandra.dht.RandomPartitioner")
else:

cluster.set_partitioner("org.apache.cassandra.dht.Murmur3Partitioner")
{code}

be simplified as 

{code}
if random_partitioner:

cluster.set_partitioner("org.apache.cassandra.dht.RandomPartitioner")
else:

cluster.set_partitioner("org.apache.cassandra.dht.Murmur3Partitioner")
{code}

wrt branches to commit on, for sure we need this on 3.0 and 3.11. We also need 
it on trunk, but should wait to see what happens with CASSANDRA-13291?

> Tracing interferes with digest requests when using RandomPartitioner
> 
>
> Key: CASSANDRA-13964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13964
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Observability
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>
> A {{ThreadLocal}} is used to generate the MD5 digest when a 
> replica serves a read command and the {{isDigestQuery}} flag is set. The same 
> threadlocal is also used by {{RandomPartitioner}} to decorate partition keys. 
> So in a cluster with RP, if tracing is enabled the data digest is corrupted 
> by the partitioner making tokens for the tracing mutations. This causes a 
> digest mismatch on the coordinator, triggering a full data read on every read 
> where CL > 1 (or speculative execution/read repair kick in).



--
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-13964) Tracing interferes with digest requests when using RandomPartitioner

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13964:

Reproduced In: 3.11.1, 3.0.15, 4.0  (was: 3.0.15, 3.11.1, 4.0)
 Reviewer: Jason Brown

> Tracing interferes with digest requests when using RandomPartitioner
> 
>
> Key: CASSANDRA-13964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13964
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Observability
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>
> A {{ThreadLocal}} is used to generate the MD5 digest when a 
> replica serves a read command and the {{isDigestQuery}} flag is set. The same 
> threadlocal is also used by {{RandomPartitioner}} to decorate partition keys. 
> So in a cluster with RP, if tracing is enabled the data digest is corrupted 
> by the partitioner making tokens for the tracing mutations. This causes a 
> digest mismatch on the coordinator, triggering a full data read on every read 
> where CL > 1 (or speculative execution/read repair kick in).



--
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-13902) document memtable_flush_period_in_ms

[Jon Haddad (JIRA)]

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

Jon Haddad updated CASSANDRA-13902:
---
   Resolution: Fixed
Fix Version/s: (was: 4.x)
   4.0
   Status: Resolved  (was: Ready to Commit)

> document memtable_flush_period_in_ms
> 
>
> Key: CASSANDRA-13902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13902
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>  Labels: lhf
> Fix For: 4.0
>
>




--
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-13902) document memtable_flush_period_in_ms

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13902:


Committed as f249cd76987290c564a1e4e1e7f9168f9a9ec005.

> document memtable_flush_period_in_ms
> 
>
> Key: CASSANDRA-13902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13902
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>  Labels: lhf
> Fix For: 4.x
>
>




--
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-13902) document memtable_flush_period_in_ms

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13902:

Status: Ready to Commit  (was: Patch Available)

> document memtable_flush_period_in_ms
> 
>
> Key: CASSANDRA-13902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13902
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>  Labels: lhf
> Fix For: 4.x
>
>




--
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: Added documentation for memtable_flush_period_in_ms

[rustyrazorblade]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 912fdb3ea -> f249cd769


Added documentation for memtable_flush_period_in_ms

Patch by Jon Haddad; reviewed by Jason Brown for CASSANDRA-13902


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

Branch: refs/heads/trunk
Commit: f249cd76987290c564a1e4e1e7f9168f9a9ec005
Parents: 912fdb3
Author: Jon Haddad 
Authored: Wed Oct 18 05:20:39 2017 -0700
Committer: Jon Haddad 
Committed: Wed Oct 18 05:42:23 2017 -0700

--
 doc/source/cql/ddl.rst | 2 ++
 1 file changed, 2 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f249cd76/doc/source/cql/ddl.rst
--
diff --git a/doc/source/cql/ddl.rst b/doc/source/cql/ddl.rst
index c17d8c9..6361983 100644
--- a/doc/source/cql/ddl.rst
+++ b/doc/source/cql/ddl.rst
@@ -479,6 +479,8 @@ A table supports the following options:
 
++--+-+---+
 | ``caching``| *map*| *see below* | :ref:`Caching 
options `. |
 
++--+-+---+
+| ``memtable_flush_period_in_ms``| *simple* | 0   | Time (in ms) 
before Cassandra flushes memtables to disk.  |
+++--+-+---+
 
 .. _cql-compaction-options:
 


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

[jira] [Commented] (CASSANDRA-13291) Replace usages of MessageDigest with Guava's Hasher

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13291:
-

[~beobal] Hmm, you are correct, and I can repro easily. With a two node ccm 
cluster, I got this error in node1:

{noformat}
org.apache.cassandra.exceptions.ConfigurationException: Token must be >= 0 and 
<= 2**127
at 
org.apache.cassandra.dht.RandomPartitioner$2.validate(RandomPartitioner.java:160)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.applyInitialTokens(DatabaseDescriptor.java:927)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:317)
 ~[main/:na]
at 
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:141)
 ~[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:602)
 [main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:646) 
[main/:na]
{noformat}

And this error in node2, which got a bit further in the boot sequence:

{noformat}
ERROR [main] 2017-10-18 05:37:18,547 CassandraDaemon.java:663 - Exception 
encountered during startup
org.apache.cassandra.exceptions.InvalidRequestException: Key may not be empty
at 
org.apache.cassandra.cql3.QueryProcessor.validateKey(QueryProcessor.java:186) 
~[main/:na]
at 
org.apache.cassandra.cql3.statements.ModificationStatement.buildPartitionKeyNames(ModificationStatement.java:310)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:656)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:644)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:595)
 ~[main/:na]
at 
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:590)
 ~[main/:na]
at 
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:296)
 ~[main/:na]
at 
org.apache.cassandra.db.SystemKeyspace.updateSchemaVersion(SystemKeyspace.java:648)
 ~[main/:na]
at org.apache.cassandra.schema.Schema.updateVersion(Schema.java:533) 
~[main/:na]
at 
org.apache.cassandra.schema.Schema.updateVersionAndAnnounce(Schema.java:541) 
~[main/:na]
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:787)
 ~[main/:na]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:622) 
~[main/:na]
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:569) 
~[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:364) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:557) 
[main/:na]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:646) 
[main/:na]
{noformat}

> Replace usages of MessageDigest with Guava's Hasher
> ---
>
> Key: CASSANDRA-13291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13291
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: CASSANDRA-13291-trunk.diff
>
>
> During my profiling of C* I frequently see lots of aggregate time across 
> threads being spent inside the MD5 MessageDigest implementation. Given that 
> there are tons of modern alternative hashing functions better than MD5 
> available -- both in terms of providing better collision resistance and 
> actual computational speed -- I wanted to switch out our usage of MD5 for 
> alternatives (like adler128 or murmur3_128) and test for performance 
> improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  
> switching out the hashing function to something like adler128 or murmur3_128 
> (for example) -- which don't ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest 
> directly in favor of Hasher from Guava. This means going forward we can 
> change a single line of code to switch the hashing algorithm being used 
> (assuming there is an implementation in Guava).



--
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: 

[jira] [Commented] (CASSANDRA-13907) Versioned documentation on cassandra.apache.org

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13907:


No arguments here.  I agree, it would be nice to have eventually.  

> Versioned documentation on cassandra.apache.org
> ---
>
> Key: CASSANDRA-13907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13907
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Murukesh Mohanan
>Priority: Minor
>
> Services like https://readthedocs.org and http://www.javadoc.io/ make it easy 
> to browse the documentation for a particular version or commit of various 
> open source projects. It would be nice to be able to browse the docs for a 
> particular release on http://cassandra.apache.org/doc/.
> Currently it seems only CQL has this at http://cassandra.apache.org/doc/old/.



--
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-13907) Versioned documentation on cassandra.apache.org

[Murukesh Mohanan (JIRA)]

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

Murukesh Mohanan commented on CASSANDRA-13907:
--

I do, that's why I think this is possible in the first place.

Being able to read the docs without having C* installed, or of a different 
version than the one you have, is extremely convenient. Think of the versioned 
manpage browsing sites ([Ubuntu|http://manpages.ubuntu.com], or 
[Debian|https://manpages.debian.org] or the absolutely fantastic [FreeBSD 
manpage browser|https://freebsd.org/cgi/man.cgi]), or what's probably the best 
documentation site of a software project, [the Python 
docs|https://docs.python.org/] (which are canonical, feature all supported 
versions, support multiple languages, has excellent search, etc.).

Having some documentation online is good ... but given that we have a release 
every few months or so, the online docs will quickly outpace anything that 
people will likely have installed (and are, therefore, using). It's not 
essential, but it's nice to have.

> Versioned documentation on cassandra.apache.org
> ---
>
> Key: CASSANDRA-13907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13907
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Murukesh Mohanan
>Priority: Minor
>
> Services like https://readthedocs.org and http://www.javadoc.io/ make it easy 
> to browse the documentation for a particular version or commit of various 
> open source projects. It would be nice to be able to browse the docs for a 
> particular release on http://cassandra.apache.org/doc/.
> Currently it seems only CQL has this at http://cassandra.apache.org/doc/old/.



--
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-13915) Create a Docker container to build the docs

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13915:
-

[~rustyrazorblade] I thought you were going to investigate some stuff, as 
[~j.casares] said:

bq. As far as Mac vs Linux differences, I'll leave that to Jon Haddad to debug 
and send me anything he finds, if you wouldn't mind? If it's a permissions 
issue, send me to the file you're having issues with and I'll make necessary 
Docker changes since I'm on OSX right now. Other than permissions issues, I've 
never seen a difference between OSX and Linux containers and the container is 
currently running as the root user, so there shouldn't be any issues that I can 
think of.

wrt the {{sudo ant realclean}}, it's kind of a PITA, but not insurmountable. 
[~mshuler] Will those linux file permissions (that I mention) be a problem for 
the build system(s)?

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
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-13902) document memtable_flush_period_in_ms

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13902:
-

+1

> document memtable_flush_period_in_ms
> 
>
> Key: CASSANDRA-13902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13902
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>  Labels: lhf
> Fix For: 4.x
>
>




--
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-13902) document memtable_flush_period_in_ms

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13902:

Reviewer: Jason Brown

> document memtable_flush_period_in_ms
> 
>
> Key: CASSANDRA-13902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13902
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>  Labels: lhf
> Fix For: 4.x
>
>




--
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-13902) document memtable_flush_period_in_ms

[Jon Haddad (JIRA)]

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

Jon Haddad updated CASSANDRA-13902:
---
Assignee: Jon Haddad
  Status: Patch Available  (was: Open)

https://github.com/apache/cassandra/compare/trunk...rustyrazorblade:13902_memtable_flush_period_in_ms_doc

> document memtable_flush_period_in_ms
> 
>
> Key: CASSANDRA-13902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13902
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>  Labels: lhf
> Fix For: 4.x
>
>




--
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-13291) Replace usages of MessageDigest with Guava's Hasher

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13291:
-

This breaks stuff in schema updates when RP is used (not sure how well that's 
going to be covered by utest/dtest). To repro, just create a 2 node ccm cluster 
with RP, the second node will error out trying to update schema in 
{{StorageService::prepareToJoin}}.
I didn't have time to dig into it, but I guess the schema digest calculation is 
at fault, M3P isn't affected.

Now, back to that horse I was flogging...

If we've decided that the threadlocal stuff is no longer necessary, I'm not 
sure why you moved it from {{FBUtilities}} to {{MD5Digest}} and kept its use by 
{{ResultSet}} and {{GuidGenerator}}. If we're sure we don't need it anymore, 
lets get rid of it completely. Otherwise, I think it would make sense for 
{{RandomPartitioner::hashToBigInteger}} to make use of it, given its hotness.

The main reason I'm interesting is that earlier this week I came across 
CASSANDRA-13964, which obviously overlaps with this somewhat.


> Replace usages of MessageDigest with Guava's Hasher
> ---
>
> Key: CASSANDRA-13291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13291
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: CASSANDRA-13291-trunk.diff
>
>
> During my profiling of C* I frequently see lots of aggregate time across 
> threads being spent inside the MD5 MessageDigest implementation. Given that 
> there are tons of modern alternative hashing functions better than MD5 
> available -- both in terms of providing better collision resistance and 
> actual computational speed -- I wanted to switch out our usage of MD5 for 
> alternatives (like adler128 or murmur3_128) and test for performance 
> improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  
> switching out the hashing function to something like adler128 or murmur3_128 
> (for example) -- which don't ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest 
> directly in favor of Hasher from Guava. This means going forward we can 
> change a single line of code to switch the hashing algorithm being used 
> (assuming there is an implementation in Guava).



--
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-13964) Tracing interferes with digest requests when using RandomPartitioner

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-13964:

Reproduced In: 3.11.1, 3.0.15, 4.0  (was: 3.0.15, 3.11.1, 4.0)
   Status: Patch Available  (was: In Progress)

> Tracing interferes with digest requests when using RandomPartitioner
> 
>
> Key: CASSANDRA-13964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13964
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Observability
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>
> A {{ThreadLocal}} is used to generate the MD5 digest when a 
> replica serves a read command and the {{isDigestQuery}} flag is set. The same 
> threadlocal is also used by {{RandomPartitioner}} to decorate partition keys. 
> So in a cluster with RP, if tracing is enabled the data digest is corrupted 
> by the partitioner making tokens for the tracing mutations. This causes a 
> digest mismatch on the coordinator, triggering a full data read on every read 
> where CL > 1 (or speculative execution/read repair kick in).



--
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-13964) Tracing interferes with digest requests when using RandomPartitioner

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13964:
-

Added a second {{ThreadLocal}} for exclusive use by 
{{RandomPartitioner}}. 
New dtest: https://github.com/beobal/cassandra-dtest/tree/13964

||branch||utest||dtest||
|[13964-3.0|https://github.com/beobal/cassandra/tree/13964-3.0]|[utest|https://circleci.com/gh/beobal/cassandra/tree/13964-3.0]|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/379/]|
|[13964-3.11|https://github.com/beobal/cassandra/tree/13964-3.11]|[utest|https://circleci.com/gh/beobal/cassandra/tree/13964-3.11]|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/380/]|
|[13964-trunk|https://github.com/beobal/cassandra/tree/13964-trunk]|[utest|https://circleci.com/gh/beobal/cassandra/tree/13964-trunk]|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/381/]|


> Tracing interferes with digest requests when using RandomPartitioner
> 
>
> Key: CASSANDRA-13964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13964
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Observability
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>
> A {{ThreadLocal}} is used to generate the MD5 digest when a 
> replica serves a read command and the {{isDigestQuery}} flag is set. The same 
> threadlocal is also used by {{RandomPartitioner}} to decorate partition keys. 
> So in a cluster with RP, if tracing is enabled the data digest is corrupted 
> by the partitioner making tokens for the tracing mutations. This causes a 
> digest mismatch on the coordinator, triggering a full data read on every read 
> where CL > 1 (or speculative execution/read repair kick in).



--
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-13915) Create a Docker container to build the docs

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13915:


[~jasobrown] did you still want to handle the review?

> Create a Docker container to build the docs
> ---
>
> Key: CASSANDRA-13915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13915
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>
> As requested by [~rustyrazorblade], I will be adding a Docker container to 
> build the docs without any prereqs (other than Docker).



--
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-13907) Versioned documentation on cassandra.apache.org

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13907:


Not sure if you're aware of this, but the docs ship with Cassandra itself.  

> Versioned documentation on cassandra.apache.org
> ---
>
> Key: CASSANDRA-13907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13907
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Murukesh Mohanan
>Priority: Minor
>
> Services like https://readthedocs.org and http://www.javadoc.io/ make it easy 
> to browse the documentation for a particular version or commit of various 
> open source projects. It would be nice to be able to browse the docs for a 
> particular release on http://cassandra.apache.org/doc/.
> Currently it seems only CQL has this at http://cassandra.apache.org/doc/old/.



--
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-13963) SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild is flaky

[JIRA]

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

Andrés de la Peña updated CASSANDRA-13963:
--
Status: Patch Available  (was: In Progress)

> SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild
>  is flaky
> -
>
> Key: CASSANDRA-13963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13963
> Project: Cassandra
>  Issue Type: Bug
>  Components: Secondary Indexes, Testing
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Minor
> Fix For: 4.x
>
>
> The unit test 
> [SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L460-L476]
>  is flaky. Apart from [the CI results showing a 3% 
> flakiness|http://cassci.datastax.com/view/All_Jobs/job/trunk_utest/2430/testReport/org.apache.cassandra.index/SecondaryIndexManagerTest/indexWithfailedInitializationIsNotQueryableAfterPartialRebuild/],
>  the test failure can be locally reproduced just running the test multiple 
> times. In my case, it fails 2-5 times for each 1000 executions.



--
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-13963) SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild is flaky

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-13963:
---

[Here|https://github.com/apache/cassandra/compare/trunk...adelapena:13963-trunk]
 is a patch solving the problem.

It seems that the call to [{{TestingIndex.shouldFailCreate = 
false;}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L466]
 is done right after creating the index configured to fail, without waiting for 
the finalization of the build task. If we are not lucky the index initalization 
task can start after disabling the configured fail. In such case, the two calls 
to {{assertFalse(cfs.indexManager.isIndexQueryable(index))}} can either succeed 
because the index build task hasn't started yet (not because it has failed), or 
fail because the task has successfully finished without the configured 
initialization task failure.

The unit tests usually use 
[{{CQLTester.waitForIndex}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L709-L737]
 method to wait for the finalization of index builds. In that case, since we 
are making the initialization to fail, we can't rely on this method, so the 
patch adds a new 
[{{CQLTester.waitForIndexBuilds}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L709-L737]
 method to wait for the finalization of index build tasks independently of 
their results and the marking procedure. This method is in {{CQLTester}} 
instead of {{SecondaryIndexManagerTest}} because I think it's suitable to be 
used by other tests. 

> SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild
>  is flaky
> -
>
> Key: CASSANDRA-13963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13963
> Project: Cassandra
>  Issue Type: Bug
>  Components: Secondary Indexes, Testing
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Minor
> Fix For: 4.x
>
>
> The unit test 
> [SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L460-L476]
>  is flaky. Apart from [the CI results showing a 3% 
> flakiness|http://cassci.datastax.com/view/All_Jobs/job/trunk_utest/2430/testReport/org.apache.cassandra.index/SecondaryIndexManagerTest/indexWithfailedInitializationIsNotQueryableAfterPartialRebuild/],
>  the test failure can be locally reproduced just running the test multiple 
> times. In my case, it fails 2-5 times for each 1000 executions.



--
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-13964) Tracing interferes with digest requests when using RandomPartitioner

[Sam Tunnicliffe (JIRA)]

Sam Tunnicliffe created CASSANDRA-13964:
---

 Summary: Tracing interferes with digest requests when using 
RandomPartitioner
 Key: CASSANDRA-13964
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13964
 Project: Cassandra
  Issue Type: Bug
  Components: Local Write-Read Paths, Observability
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe


A {{ThreadLocal}} is used to generate the MD5 digest when a 
replica serves a read command and the {{isDigestQuery}} flag is set. The same 
threadlocal is also used by {{RandomPartitioner}} to decorate partition keys. 
So in a cluster with RP, if tracing is enabled the data digest is corrupted by 
the partitioner making tokens for the tracing mutations. This causes a digest 
mismatch on the coordinator, triggering a full data read on every read where CL 
> 1 (or speculative execution/read repair kick in).




--
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-13963) SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild is flaky

[JIRA]

Andrés de la Peña created CASSANDRA-13963:
-

 Summary: 
SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild
 is flaky
 Key: CASSANDRA-13963
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13963
 Project: Cassandra
  Issue Type: Bug
  Components: Secondary Indexes, Testing
Reporter: Andrés de la Peña
Assignee: Andrés de la Peña
Priority: Minor
 Fix For: 4.x


The unit test 
[SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L460-L476]
 is flaky. Apart from [the CI results showing a 3% 
flakiness|http://cassci.datastax.com/view/All_Jobs/job/trunk_utest/2430/testReport/org.apache.cassandra.index/SecondaryIndexManagerTest/indexWithfailedInitializationIsNotQueryableAfterPartialRebuild/],
 the test failure can be locally reproduced just running the test multiple 
times. In my case, it fails 2-5 times for each 1000 executions.



--
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-13962) should java.io.OutputStream.flush() be called on Commit log operations ?

[Ilya Shipitsin (JIRA)]

Ilya Shipitsin created CASSANDRA-13962:
--

 Summary: should java.io.OutputStream.flush() be called on Commit 
log operations ?
 Key: CASSANDRA-13962
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13962
 Project: Cassandra
  Issue Type: Bug
 Environment: cassandra 2.2.8
Reporter: Ilya Shipitsin


we run high loaded cassandra cluster on 2.2.8
when we reboot node, very often we observe broken commit log, like described 
here

https://stackoverflow.com/questions/33304367/cassandra-exiting-due-to-error-while-processing-commit-log-during-initializatio

I guess, that output is not flushed upon commit log write, I mean  
java.io.OutputStream.flush()


google also say, the same issue occur to sstables (they are written in more 
rare fashion, so we did not observe that practically)


any idea why output is not flushed ? is it done in purpose ?



--
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-13897) nodetool compact and flush fail with "error: null"

[Branimir Lambov (JIRA)]

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

Branimir Lambov commented on CASSANDRA-13897:
-

The cache will also take buffers from the buffer pool of that size. If the size 
does not divide 64k, space will be wasted in each buffer, and this could cause 
buffer management problems. If we don't change the pool to gracefully handle 
this, I think it's safer to just round the size.

> nodetool compact and flush fail with "error: null"
> --
>
> Key: CASSANDRA-13897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13897
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: * Apache Cassandra 3.11.0
> * Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 
> x86_64 x86_64 GNU/Linux
> * jdk1.8.0_144
>Reporter: Jacob Rhoden
>Assignee: Stefania
>Priority: Minor
>
> {{nodetool flush}} and {{nodetool compact}} return an error message that is 
> not clear. This could probably be improved. Both of my two nodes return this 
> error.
> {{nodetool flush}} Will return this error the first 2-3 times you invoke it, 
> then the error temporarily disappears. {{nodetool compress}} always returns 
> this error message no matter how many times you invoke it.
> I have tried deleting saved_caches, commit logs, doing nodetool 
> compact/rebuild/scrub, and nothing seems to remove the error. 
> {noformat}
> cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
>   at 
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
>   at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
>   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 
> 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:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
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-13897) nodetool compact and flush fail with "error: null"

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-13897:
--

[~blambov], can the {{CachingRebufferer}} be changed to only require a multiple 
of 4096 rather than a power of two? [~snazy] and myself are worried that 
neither rounding up nor rounding down to a power of two feels too right as in 
both cases we may end up being quite far from the initial value derived from 
the data and the disk optimization strategy. As far as I have understood, the 
rebufferer requires a power of two to calculate the page position, can it not 
align to 4096 multiples instead?

> nodetool compact and flush fail with "error: null"
> --
>
> Key: CASSANDRA-13897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13897
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: * Apache Cassandra 3.11.0
> * Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 
> x86_64 x86_64 GNU/Linux
> * jdk1.8.0_144
>Reporter: Jacob Rhoden
>Assignee: Stefania
>Priority: Minor
>
> {{nodetool flush}} and {{nodetool compact}} return an error message that is 
> not clear. This could probably be improved. Both of my two nodes return this 
> error.
> {{nodetool flush}} Will return this error the first 2-3 times you invoke it, 
> then the error temporarily disappears. {{nodetool compress}} always returns 
> this error message no matter how many times you invoke it.
> I have tried deleting saved_caches, commit logs, doing nodetool 
> compact/rebuild/scrub, and nothing seems to remove the error. 
> {noformat}
> cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
>   at 
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
>   at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
>   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 
> 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:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
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: 

[jira] [Updated] (CASSANDRA-13897) nodetool compact and flush fail with "error: null"

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-13897:
-
Reproduced In: 3.11.1, 3.11.0  (was: 3.11.0, 3.11.1)
 Reviewer: Robert Stupp

> nodetool compact and flush fail with "error: null"
> --
>
> Key: CASSANDRA-13897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13897
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: * Apache Cassandra 3.11.0
> * Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 
> x86_64 x86_64 GNU/Linux
> * jdk1.8.0_144
>Reporter: Jacob Rhoden
>Assignee: Stefania
>Priority: Minor
>
> {{nodetool flush}} and {{nodetool compact}} return an error message that is 
> not clear. This could probably be improved. Both of my two nodes return this 
> error.
> {{nodetool flush}} Will return this error the first 2-3 times you invoke it, 
> then the error temporarily disappears. {{nodetool compress}} always returns 
> this error message no matter how many times you invoke it.
> I have tried deleting saved_caches, commit logs, doing nodetool 
> compact/rebuild/scrub, and nothing seems to remove the error. 
> {noformat}
> cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
>   at 
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
>   at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
>   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 
> 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:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
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-13897) nodetool compact and flush fail with "error: null"

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-13897:
--

Patch for 3.11 is available 
[here|https://github.com/stef1927/cassandra/tree/13897-3.11]. It rounds up to 
the next power of two since we cap at 64 KB. 

CircleCI was having github access problems, so I've launched the CI jobs on our 
internal servers.


> nodetool compact and flush fail with "error: null"
> --
>
> Key: CASSANDRA-13897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13897
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: * Apache Cassandra 3.11.0
> * Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 
> x86_64 x86_64 GNU/Linux
> * jdk1.8.0_144
>Reporter: Jacob Rhoden
>Assignee: Stefania
>Priority: Minor
>
> {{nodetool flush}} and {{nodetool compact}} return an error message that is 
> not clear. This could probably be improved. Both of my two nodes return this 
> error.
> {{nodetool flush}} Will return this error the first 2-3 times you invoke it, 
> then the error temporarily disappears. {{nodetool compress}} always returns 
> this error message no matter how many times you invoke it.
> I have tried deleting saved_caches, commit logs, doing nodetool 
> compact/rebuild/scrub, and nothing seems to remove the error. 
> {noformat}
> cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
>   at 
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
>   at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
>   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 
> 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:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
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-13897) nodetool compact and flush fail with "error: null"

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-13897:
-
Reproduced In: 3.11.1, 3.11.0  (was: 3.11.0, 3.11.1)
   Status: Patch Available  (was: Open)

> nodetool compact and flush fail with "error: null"
> --
>
> Key: CASSANDRA-13897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13897
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: * Apache Cassandra 3.11.0
> * Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 
> x86_64 x86_64 GNU/Linux
> * jdk1.8.0_144
>Reporter: Jacob Rhoden
>Assignee: Stefania
>Priority: Minor
>
> {{nodetool flush}} and {{nodetool compact}} return an error message that is 
> not clear. This could probably be improved. Both of my two nodes return this 
> error.
> {{nodetool flush}} Will return this error the first 2-3 times you invoke it, 
> then the error temporarily disappears. {{nodetool compress}} always returns 
> this error message no matter how many times you invoke it.
> I have tried deleting saved_caches, commit logs, doing nodetool 
> compact/rebuild/scrub, and nothing seems to remove the error. 
> {noformat}
> cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
>   at 
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
>   at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
>   at 
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>   at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
>   at 
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
>   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 
> 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:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
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-13291) Replace usages of MessageDigest with Guava's Hasher

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13291:
-

bq. the reason we got here is because of the fact that the ultimate goal here 
(to switch the hashing function we're using) ... 

ok, sgtm

Beyond that, I'm +1. If the tests all look legit, I'll commit tomorrow.

> Replace usages of MessageDigest with Guava's Hasher
> ---
>
> Key: CASSANDRA-13291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13291
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: CASSANDRA-13291-trunk.diff
>
>
> During my profiling of C* I frequently see lots of aggregate time across 
> threads being spent inside the MD5 MessageDigest implementation. Given that 
> there are tons of modern alternative hashing functions better than MD5 
> available -- both in terms of providing better collision resistance and 
> actual computational speed -- I wanted to switch out our usage of MD5 for 
> alternatives (like adler128 or murmur3_128) and test for performance 
> improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  
> switching out the hashing function to something like adler128 or murmur3_128 
> (for example) -- which don't ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest 
> directly in favor of Hasher from Guava. This means going forward we can 
> change a single line of code to switch the hashing algorithm being used 
> (assuming there is an implementation in Guava).



--
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-13291) Replace usages of MessageDigest with Guava's Hasher

[Michael Kjellman (JIRA)]

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

Michael Kjellman commented on CASSANDRA-13291:
--

Re: the {{newHasher()}} stuff, I agree with you but the reason we got here is 
because of the fact that the ultimate goal here (to switch the hashing function 
we're using) was split into two tickets to separate all this boring refactoring 
from the actual conversation about what hashing function we should use going 
forward and make that change pretty small (obviously high impact but small in 
number of LoC, assuming we have this boring refactor ticket done). I avoid 
wrapping the wrapper because I felt keeping it as basic as possible would make 
the number of changes needed to handle rolling upgrades etc would be easier

I just committed all your other comments/findings, squashed, and force pushed 
it up to my branch.

> Replace usages of MessageDigest with Guava's Hasher
> ---
>
> Key: CASSANDRA-13291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13291
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Kjellman
>Assignee: Michael Kjellman
> Attachments: CASSANDRA-13291-trunk.diff
>
>
> During my profiling of C* I frequently see lots of aggregate time across 
> threads being spent inside the MD5 MessageDigest implementation. Given that 
> there are tons of modern alternative hashing functions better than MD5 
> available -- both in terms of providing better collision resistance and 
> actual computational speed -- I wanted to switch out our usage of MD5 for 
> alternatives (like adler128 or murmur3_128) and test for performance 
> improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  
> switching out the hashing function to something like adler128 or murmur3_128 
> (for example) -- which don't ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest 
> directly in favor of Hasher from Guava. This means going forward we can 
> change a single line of code to switch the hashing algorithm being used 
> (assuming there is an implementation in Guava).



--
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