[jira] [Commented] (CASSANDRA-13993) Add optional startup delay to wait until peers are ready

[Joseph Lynch (JIRA)]

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

Joseph Lynch commented on CASSANDRA-13993:
--

[~jasobrown] this is a great idea and would definitely help with the pain of 
rolling restarts! I'm curious though about the choice to make this a percentage 
instead of a raw count either for only the local datacenter or for each 
datacenter (e.g. block until N nodes or fewer are marked down in this nodes 
local datacenter)? In particular I'm concerned that in typical setups (maybe 
something like 2 datacenters, <60 nodes, RF=3, mostly 
{{NetworkTopologyStrategy}} keyspaces) having anything more than one node down 
in gossip in the same datacenter will mean a high probability of getting 
unavailable exceptions @ {{LOCAL_QUORUM}} or timeouts, especially with 
vnode=256 clusters where any 2 nodes down in different racks essentially 
guarantees an unavailable error for some intersecting token range.

What if instead of a percentage the system waited for a fixed number (or fewer) 
of endpoints to be marked as down in the local datacenter, such as 1 by 
default, relying on the timeout for large clusters (although it would be 
awesome if this timeout re-used or defaulted to an existing timeout relevant to 
gossip convergence such as {{BROADCAST_INTERVAL}} or {{RING_DELAY}}).

What do you think? I worked up a quick proof of concept implementation that 
implements counts for the local DC, each DC, or all DCs (for users that are 
using {{LOCAL_QUORUM}} vs {{EACH_QUORUM}} vs {{QUORUM}}) over on 
[github|https://github.com/jasobrown/cassandra/compare/13993...jolynch:13993] 
to show kind of what I'm thinking. I didn't fix the unit tests but if you think 
it's a good idea I can fix them up and add some more (that test multi dc 
setups).

I guess that to make it even smarter a previous {{CassandraDaemon.stop}} could 
persist how many {{DOWN}} nodes there were in a local table or some such and 
then the {{CassandraDaemon.start}} waits for the maximum of that persisted 
number and the configured default, but that adds more complexity and given the 
flexibility of the three counts I am not sure it's worth it.

> Add optional startup delay to wait until peers are ready
> 
>
> Key: CASSANDRA-13993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13993
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Lifecycle
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.x
>
>
> When bouncing a node in a large cluster, is can take a while to recognize the 
> rest of the cluster as available. This is especially true if using TLS on 
> internode messaging connections. The bouncing node (and any clients connected 
> to it) may see a series of Unavailable or Timeout exceptions until the node 
> is 'warmed up' as connecting to the rest of the cluster is asynchronous from 
> the rest of the startup process.
> There are two aspects that drive a node's ability to successfully communicate 
> with a peer after a bounce:
> - marking the peer as 'alive' (state that is held in gossip). This affects 
> the unavailable exceptions
> - having both open outbound and inbound connections open and ready to each 
> peer. This affects timeouts.
> Details of each of these mechanisms are described in the comments below.
> This ticket proposes adding a mechanism, optional and configurable, to delay 
> opening the client native protocol port until some percentage of the peers in 
> the cluster is marked alive and connected to/from. Thus while we potentially 
> slow down startup (delay opening the client port), we alleviate the chance 
> that queries made by clients don't hit transient unavailable/timeout 
> exceptions.



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

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

[jira] [Commented] (CASSANDRA-14239) OutOfMemoryError when bootstrapping with less than 100GB RAM

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-14239:
--

Don't know that people have had great success with G1. Seems like the memtables 
are using up too much memory but anyway you should try with a smaller heap 
and/or CMS. Maybe try offheap memtables as well? Seems like there might still 
be a bug here though.

> OutOfMemoryError when bootstrapping with less than 100GB RAM
> 
>
> Key: CASSANDRA-14239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14239
> Project: Cassandra
>  Issue Type: Bug
> Environment: Details of the bootstrapping Node
>  * ProLiant BL460c G7
>  * 56GB RAM
>  * 2x 146GB 10K HDD (One dedicated for Commitlog, one for Data, Hints and 
> saved_caches)
>  * CentOS 7.4 on SD-Card
>  * /tmp and /var/log on tmpfs
>  * Oracle JDK 1.8.0_151
>  * Cassandra 3.11.1
> Cluster
>  * 10 existing Nodes (Up and Normal)
>Reporter: Jürgen Albersdorfer
>Priority: Major
> Attachments: Objects-by-class.csv, 
> Objects-with-biggest-retained-size.csv, cassandra-env.sh, cassandra.yaml, 
> jvm.options, jvm_opts.txt, stack-traces.txt
>
>
> Hi, I face an issue when bootstrapping a Node having less than 100GB RAM on 
> our 10 Node C* 3.11.1 Cluster.
> During bootstrap, when I watch the cassandra.log I observe a growth in JVM 
> Heap Old Gen which gets not significantly freed up any more.
> I know that JVM collects on Old Gen only when really needed. I can see 
> collections, but there is always a remainder which seems to grow forever 
> without ever getting freed.
> After the Node successfully Joined the Cluster, I can remove the extra RAM I 
> have given it for bootstrapping without any further effect.
> It feels like Cassandra will not forget about every single byte streamed over 
> the Network over time during bootstrapping, - which would be a memory leak 
> and a major problem, too.
> I was able to produce a HeapDumpOnOutOfMemoryError from a 56GB Node (40 GB 
> assigned JVM Heap). YourKit Profiler shows huge amount of Memory allocated 
> for org.apache.cassandra.db.Memtable (22 GB) 
> org.apache.cassandra.db.rows.BufferCell (19 GB) and java.nio.HeapByteBuffer 
> (11 GB)



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

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

[jira] [Commented] (CASSANDRA-14087) NPE when CAS encounters empty frozen collection

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-14087:
--

Thanks [~blerer], I've updated both branches for the nit. 3.0 should still 
merge cleanly into 3.11.

[~bdeggleston] 'tis ready for review again.

> NPE when CAS encounters empty frozen collection
> ---
>
> Key: CASSANDRA-14087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14087
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jens Bannmann
>Assignee: Kurt Greaves
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> When a compare-and-set operation specifying an equality criterion with a 
> non-{{null}} value encounters an empty collection ({{null}} cell), the server 
> throws a {{NullPointerException}} and the query fails.
> This does not happen for non-frozen collections.
> There's a self-contained test case at 
> [github|https://github.com/incub8/cassandra-npe-in-cas].
> The stack trace for 3.11.0 is:
> {code}
> ERROR [Native-Transport-Requests-1] 2017-11-27 12:59:26,924 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.cql3.ColumnCondition$CollectionBound.appliesTo(ColumnCondition.java:546)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest$ColumnsConditions.appliesTo(CQL3CasRequest.java:324)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.appliesTo(CQL3CasRequest.java:210)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:265) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:217)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_151]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.0.jar:3.11.0]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> {code}



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

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

[jira] [Commented] (CASSANDRA-14210) Optimize SSTables upgrade task scheduling

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-14210:
--

LGTM [~krummas].

> Optimize SSTables upgrade task scheduling
> -
>
> Key: CASSANDRA-14210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14210
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Oleksandr Shulgin
>Assignee: Kurt Greaves
>Priority: Major
> Fix For: 4.x
>
>
> When starting the SSTable-rewrite process by running {{nodetool 
> upgradesstables --jobs N}}, with N > 1, not all of the provided N slots are 
> used.
> For example, we were testing with {{concurrent_compactors=5}} and {{N=4}}.  
> What we observed both for version 2.2 and 3.0, is that initially all 4 
> provided slots are used for "Upgrade sstables" compactions, but later when 
> some of the 4 tasks are finished, no new tasks are scheduled immediately.  It 
> takes the last of the 4 tasks to finish before new 4 tasks would be 
> scheduled.  This happens on every node we've observed.
> This doesn't utilize available resources to the full extent allowed by the 
> --jobs N parameter.  In the field, on a cluster of 12 nodes with 4-5 TiB data 
> each, we've seen that the whole process was taking more than 7 days, instead 
> of estimated 1.5-2 days (provided there would be close to full N slots 
> utilization).
> Instead, new tasks should be scheduled as soon as there is a free compaction 
> slot.
> Additionally, starting from the biggest SSTables could further reduce the 
> total time required for the whole process to finish on any given node.



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

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

[jira] [Updated] (CASSANDRA-14244) Some tests in read_repair_test are flakey

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-14244:

Status: Patch Available  (was: Open)

DTest PR for this here: https://github.com/apache/cassandra-dtest/pull/20
One additional change I made, aside from setting the table options, was to 
disable dynamic snitch as this could also cause a coordinator to direct a read 
command to another replicwhen it could execute it itself.

CI is running against that dtest branch and I haven't seen a failure in over 50 
runs locally
https://circleci.com/workflow-run/69c20512-3407-45e9-887a-5a7b2f7ea95b

> Some tests in read_repair_test are flakey
> -
>
> Key: CASSANDRA-14244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14244
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Major
>  Labels: dtest
>
> Since being refactored for CASSANDRA-14134, 
> {{test_alter_rf_and_run_read_repair}} and {{test_read_repair_chance}} in 
> {{read_repair_test.TestReadRepair}} are flakey and regularly fail on all 
> branches. The problem is that the inital setup of these two tests doesn't 
> explicitly set the {{read_repair_chance}} or {{dclocal_read_repair_chance}} 
> properties on the test table. As a consequence, read repairs are sometimes 
> probabilistically triggered and query results don't match the expectations.



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

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

[jira] [Commented] (CASSANDRA-14244) Some tests in read_repair_test are flakey

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-14244:


GitHub user beobal opened a pull request:

https://github.com/apache/cassandra-dtest/pull/20

Make replica selection deterministic in read_repair_test

CASSANDRA-14244

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

$ git pull https://github.com/beobal/cassandra-dtest CASSANDRA-14244

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

https://github.com/apache/cassandra-dtest/pull/20.patch

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

This closes #20


commit 50f3a87766892644900053218f8c80e98711fe2c
Author: Sam Tunnicliffe 
Date:   2018-02-21T00:20:23Z

Make replica selection deterministic in read_repair_test




> Some tests in read_repair_test are flakey
> -
>
> Key: CASSANDRA-14244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14244
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Major
>  Labels: dtest
>
> Since being refactored for CASSANDRA-14134, 
> {{test_alter_rf_and_run_read_repair}} and {{test_read_repair_chance}} in 
> {{read_repair_test.TestReadRepair}} are flakey and regularly fail on all 
> branches. The problem is that the inital setup of these two tests doesn't 
> explicitly set the {{read_repair_chance}} or {{dclocal_read_repair_chance}} 
> properties on the test table. As a consequence, read repairs are sometimes 
> probabilistically triggered and query results don't match the expectations.



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

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

[jira] [Commented] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-8460:
---

Taking a look at this ticket, I've got a concern, and I'd like to suggest an 
alternative.  

Juggling multiple disks has been a bit of a pain so far and still has some 
weird behavior.  We're a little better now that we split by token ranges, but 
there's still (IIRC) a point in time where the failure of a single disk can 
resurrect some data which had just been tombstoned.  If this is fixed, 
apologies, but I haven't seen it.  I'm not quite sure that adding complexity to 
this already long lasting pain point is going to help the project overall.

As an alternative, it's already possible to more or less get this behavior in a 
fashion that works with _every_ compaction strategy.  LVM (Linux only) is 
already ubiquitous.  Using lvmcache (backed by dmcache) already provides the 
ability to put your cold data on the slower spinning disks and leverage SSD for 
fast operations.  The benefit here is that you can keep a lot of your hot data 
on the fast drive and LVM will automatically handle making room for the newer 
files.  A second benefit is that you are not exposing yourself to the above 
mentioned issues with JBOD.  



> Make it possible to move non-compacting sstables to slow/big storage in DTCS
> 
>
> Key: CASSANDRA-8460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8460
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Lerh Chuan Low
>Priority: Major
>  Labels: doc-impacting, dtcs
> Fix For: 4.x
>
>
> It would be nice if we could configure DTCS to have a set of extra data 
> directories where we move the sstables once they are older than 
> max_sstable_age_days. 
> This would enable users to have a quick, small SSD for hot, new data, and big 
> spinning disks for data that is rarely read and never compacted.



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

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

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 10:38 PM:


+{color:#0066cc}Dinesh Joshi{color}+ - I am actually referring to the Cassandra 
Server (see my follow-up comment above)
Consider an environment where you want mutual authentication to occur by both 
Client and Server.


was (Author: ronblechman):
+{color:#0066cc}Dinesh Joshi{color}+ - I am actually referring to the Cassandra 
Server (see my follow-up comment above)

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new SSLContext using SSLContext.getInstance().  
> Using the default SSLContext would allow a user to plug in their own custom 
> SSLSocketFactory via the java.security properties file. The custom 
> SSLSocketFactory could create a default SSLContext  that was customized to do 
> any extra validation such as certificate revocation, host name validation, 
> etc.



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

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

[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman commented on CASSANDRA-14223:
--

+{color:#0066cc}Dinesh Joshi{color}+ - I am actually referring to the Cassandra 
Server (see my follow-up comment above)

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new SSLContext using SSLContext.getInstance().  
> Using the default SSLContext would allow a user to plug in their own custom 
> SSLSocketFactory via the java.security properties file. The custom 
> SSLSocketFactory could create a default SSLContext  that was customized to do 
> any extra validation such as certificate revocation, host name validation, 
> etc.



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

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

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 10:33 PM:


My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
 The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 

For example:

SSLFactory::createSSLContext()
 try
 {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
 || Security.getProperty("ssl.ServerSocketFactory.provider") != null) {
{{   // use default SSLContext created in the socket factories}}
     ctx = SSLContext.getDefault();
 {{} else {}}
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

...


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
 The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 

For example:

 SSLFactory::createSSLContext()
try
 {
  if (Security.getProperty("ssl.SocketFactory.provider") != null}}
  || Security.getProperty("ssl.ServerSocketFactory.provider") != null) 
\{{{}}
 {{   // use default SSLContext created in the socket factories}}
     ctx = SSLContext.getDefault();
 {{} else {}}
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional 

[jira] [Updated] (CASSANDRA-14155) [TRUNK] Gossiper somewhat frequently hitting an NPE on node startup with dtests at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-14155:

Reviewer: Sam Tunnicliffe

> [TRUNK] Gossiper somewhat frequently hitting an NPE on node startup with 
> dtests at 
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
> 
>
> Key: CASSANDRA-14155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14155
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>Priority: Major
>
> Gossiper is somewhat frequently hitting an NPE on node startup with dtests at 
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors: 
> [ERROR [main] 2018-01-08 21:41:01,832 CassandraDaemon.java:675 - Exception 
> encountered during startup
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:511)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:761)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:568)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:360) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:658) 
> [main/:na], ERROR [main] 2018-01-08 21:41:01,832 CassandraDaemon.java:675 - 
> Exception encountered during startup
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:511)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:761)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:568)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:360) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:658) 
> [main/:na]]
> {code}



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

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

[jira] [Commented] (CASSANDRA-14240) Backport circleci yaml

[Nate McCall (JIRA)]

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

Nate McCall commented on CASSANDRA-14240:
-

<3 !

> Backport circleci yaml
> --
>
> Key: CASSANDRA-14240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14240
> Project: Cassandra
>  Issue Type: Task
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Trivial
> Fix For: 2.2.13, 3.0.17, 3.11.3
>
>
> Backport the circleci yaml (sha {{d6e508f33c1a7274b5826ad9d5ce814d719bd848}}) 
> to earlier branches



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

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

[jira] [Updated] (CASSANDRA-14222) Add hot reloading of SSL Certificates capability to Cassandra

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-14222:

Fix Version/s: (was: 4.x)
   4.0

> Add hot reloading of SSL Certificates capability to Cassandra
> -
>
> Key: CASSANDRA-14222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14222
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Major
>  Labels: security
> Fix For: 4.0
>
>
> Cassandra does not currently hot reload SSL certificates. For ease of 
> operation it would be useful if we add this capability. This patch would 
> watch changes to the truststore & keystore and would reload them when they're 
> changed.



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

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

[jira] [Created] (CASSANDRA-14244) Some tests in read_repair_test are flakey

[Sam Tunnicliffe (JIRA)]

Sam Tunnicliffe created CASSANDRA-14244:
---

 Summary: Some tests in read_repair_test are flakey
 Key: CASSANDRA-14244
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14244
 Project: Cassandra
  Issue Type: Test
  Components: Testing
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe


Since being refactored for CASSANDRA-14134, 
{{test_alter_rf_and_run_read_repair}} and {{test_read_repair_chance}} in 
{{read_repair_test.TestReadRepair}} are flakey and regularly fail on all 
branches. The problem is that the inital setup of these two tests doesn't 
explicitly set the {{read_repair_chance}} or {{dclocal_read_repair_chance}} 
properties on the test table. As a consequence, read repairs are sometimes 
probabilistically triggered and query results don't match the expectations.




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

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

[jira] [Updated] (CASSANDRA-14236) C* should gradually recycle open connections after hot reloading SSL Certificates

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14236:
-
Labels: security  (was: )

> C* should gradually recycle open connections after hot reloading SSL 
> Certificates
> -
>
> Key: CASSANDRA-14236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14236
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Minor
>  Labels: security
>
> Currently the way SSL certificate hot reloading is implemented, it only 
> applies the new certificates to new connections. Open connections are not 
> terminated. Immediate termination of these connections is undesirable as it 
> will cause a thundering herd problem. We need a way to gradually drain 
> existing connections so that the new SSL certificates are used by all 
> connections.



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

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

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:31 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
 The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 

For example:

 SSLFactory::createSSLContext()
try
 {
  if (Security.getProperty("ssl.SocketFactory.provider") != null}}
  || Security.getProperty("ssl.ServerSocketFactory.provider") != null) 
\{{{}}
 {{   // use default SSLContext created in the socket factories}}
     ctx = SSLContext.getDefault();
 {{} else {}}
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
 The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
SSLFactory::(createSSLContext():(
try
{
 if (Security.getProperty("ssl.SocketFactory.provider") != null}}
 || Security.getProperty("ssl.ServerSocketFactory.provider") != null) 
{{{}}
{{   // use default SSLContext created in the socket factories}}
    ctx = SSLContext.getDefault();
{{} else {}}
    // use Cassandra provided SSLContext (same as before)
    ctx = SSLContext.getInstance(options.protocol);

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:29 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
 The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
SSLFactory::(createSSLContext():(
try
{
 if (Security.getProperty("ssl.SocketFactory.provider") != null}}
 || Security.getProperty("ssl.ServerSocketFactory.provider") != null) 
{{{}}
{{   // use default SSLContext created in the socket factories}}
    ctx = SSLContext.getDefault();
{{} else {}}
    // use Cassandra provided SSLContext (same as before)
    ctx = SSLContext.getInstance(options.protocol);


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
 The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

{{2) Cassandra makes use of the customized SSLContext by a minor modification 
in SSLFactory::createSSLContext(). }}
{{ For example:}}
{{ SSLFactory::(createSSLContext():}}
{{     try}}
{{     {}}
{{  if (Security.getProperty("ssl.SocketFactory.provider") != null}}
{{      || Security.getProperty("ssl.ServerSocketFactory.provider") != 
null)}}{{    {}}
{{ // use default SSLContext created in the socket factories}}
{{     ctx = SSLContext.getDefault();}}
{{ } else {}}
{{     // use Cassandra provided SSLContext (same as before)}}
{{     ctx = SSLContext.getInstance(options.protocol);}}

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:26 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
 The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

{{2) Cassandra makes use of the customized SSLContext by a minor modification 
in SSLFactory::createSSLContext(). }}
{{ For example:}}
{{ SSLFactory::(createSSLContext():}}
{{     try}}
{{     {}}
{{  if (Security.getProperty("ssl.SocketFactory.provider") != null}}
{{      || Security.getProperty("ssl.ServerSocketFactory.provider") != 
null)}}{{    {}}
{{ // use default SSLContext created in the socket factories}}
{{     ctx = SSLContext.getDefault();}}
{{ } else {}}
{{     // use Cassandra provided SSLContext (same as before)}}
{{     ctx = SSLContext.getInstance(options.protocol);}}


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:24 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). 
The benefit here is that the customized Trust Manager could do this without 
having to reconfigure and restart Cassandra. Additionally, the custom Trust 
Manager could also determine whether or not to provide additional certificate 
validations such as CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit here is that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide addition certificate validations such as CRL validation, 
hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:24 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit here is that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide addition certificate validations such as CRL validation, 
hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory



2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:22 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set's this 
customized SSLContext to be the default  (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory



2) Cassandra makes use of the customized SSLContext by a minor modification in 
SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.

2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:10 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, supporting an 
application that allows the user to administer what types of validation one 
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:

1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.

2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the 
socket factories     ctx = SSLContext.getDefault();     }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).


 In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:


 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.


 2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null) 
{

    // use default SSLContext created in the socket factories

    ctx = SSLContext.getDefault();   

 } else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new SSLContext using SSLContext.getInstance().  
> Using the default SSLContext would allow a user to plug in their own custom 
> SSLSocketFactory via the java.security properties file. The custom 
> 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:00 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).


 In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:


 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.


 2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():
     try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null) 
{

    // use default SSLContext created in the socket factories

    ctx = SSLContext.getDefault();   

 } else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).
In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.
I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
For example:
SSLFactory::(createSSLContext():
    try
    {
 if (Security.getProperty("ssl.SocketFactory.provider") != null
     || Security.getProperty("ssl.ServerSocketFactory.provider") != null)
{

    // use default SSLContext created in the socket factories

    ctx = SSLContext.getDefault();      }
else {
    // use Cassandra provided SSLContext (same as before)
    ctx = SSLContext.getInstance(options.protocol);
...My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 4:58 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).
In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.
I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
For example:
SSLFactory::(createSSLContext():
    try
    {
 if (Security.getProperty("ssl.SocketFactory.provider") != null
     || Security.getProperty("ssl.ServerSocketFactory.provider") != null)
{

    // use default SSLContext created in the socket factories

    ctx = SSLContext.getDefault();      }
else {
    // use Cassandra provided SSLContext (same as before)
    ctx = SSLContext.getInstance(options.protocol);
...My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
 2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():

    try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the socket factories 
    ctx = SSLContext.getDefault();      }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

...

 

 

 

 


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 4:58 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
 2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():

    try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{
     // use default SSLContext created in the socket factories
     ctx = SSLContext.getDefault();      }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

...

 

 

 

 


was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
 2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():

    try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the socket factories 
    ctx = SSLContext.getDefault();      }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

...

 

 

 

 

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new SSLContext using SSLContext.getInstance().  
> Using the default SSLContext would allow a user to plug in their own custom 
> SSLSocketFactory via the java.security properties file. The custom 
> SSLSocketFactory 

[jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 4:56 PM:
---

My request is to be able to apply ANY form of customized certificate 
validation, which OCSP is just one example. For example, an application I am 
working on allows the user to administer what types of validation one would 
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
 1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
 2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
 For example:
 SSLFactory::(createSSLContext():

    try
     {
  if (Security.getProperty("ssl.SocketFactory.provider") != null
      || Security.getProperty("ssl.ServerSocketFactory.provider") != null)

{     // use default SSLContext created in the socket factories 
    ctx = SSLContext.getDefault();      }

else {
     // use Cassandra provided SSLContext (same as before)
     ctx = SSLContext.getInstance(options.protocol);

...

 

 

 

 


was (Author: ronblechman):
My request is in respecct to being able to apply ANY form of customized 
certificate validation, which OCSP is just one example. For example, an 
application I am working on allows the user to administer what types of 
validation one would like to apply (e.g. OCSP, CRLS, Host Name Validation, 
etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
For example:
SSLFactory::(createSSLContext():

    try
    {
 if (Security.getProperty("ssl.SocketFactory.provider") != null
     || Security.getProperty("ssl.ServerSocketFactory.provider") != null) {
    // use default SSLContext created in the socket factories
    ctx = SSLContext.getDefault();
     } else {
    // use Cassandra provided SSLContext (same as before)
    ctx = SSLContext.getInstance(options.protocol);

...

 

 

 

 

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new SSLContext using SSLContext.getInstance().  
> Using the default SSLContext would allow a user to plug in their own custom 
> SSLSocketFactory via the java.security properties file. The custom 
> 

[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Ron Blechman (JIRA)]

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

Ron Blechman commented on CASSANDRA-14223:
--

My request is in respecct to being able to apply ANY form of customized 
certificate validation, which OCSP is just one example. For example, an 
application I am working on allows the user to administer what types of 
validation one would like to apply (e.g. OCSP, CRLS, Host Name Validation, 
etc.).

In respect to OCSP, one could provide a customized Trust Manager that would 
have the intelligence to know whether or not to apply OCSP checking and to what 
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized 
Trust Manager could do this without having to reconfigure and restart 
Cassandra. Additionally, the custom Trust Manager could also determine whether 
or not to provide CRL validation, hostname validation, etc.

I have found and tested that this capability can be added to Cassandra today in 
a very general way through some minor code changes and the use of customized 
SSLSocketFactory and SSLServerSocketFactory:
1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and 
initialize an SSLContext  with a customized Trust Manager and set this  and are 
specified in a java.security properties file.
2) Cassandra could make use of this intelligent SSLContext by a minor 
modification in SSLFactory::createSSLContext(). 
For example:
SSLFactory::(createSSLContext():

    try
    {
 if (Security.getProperty("ssl.SocketFactory.provider") != null
     || Security.getProperty("ssl.ServerSocketFactory.provider") != null) {
    // use default SSLContext created in the socket factories
    ctx = SSLContext.getDefault();
     } else {
    // use Cassandra provided SSLContext (same as before)
    ctx = SSLContext.getInstance(options.protocol);

...

 

 

 

 

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new SSLContext using SSLContext.getInstance().  
> Using the default SSLContext would allow a user to plug in their own custom 
> SSLSocketFactory via the java.security properties file. The custom 
> SSLSocketFactory could create a default SSLContext  that was customized to do 
> any extra validation such as certificate revocation, host name validation, 
> etc.



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

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

[jira] [Updated] (CASSANDRA-12109) Configuring SSL for JMX connections forces requirement of local truststore

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-12109:
-
Labels: security  (was: )

> Configuring SSL for JMX connections forces requirement of local truststore
> --
>
> Key: CASSANDRA-12109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12109
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Lifecycle, Observability
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Major
>  Labels: security
> Fix For: 3.8
>
>
> In CASSANDRA-10091 we changed the way the JMX server is constructed such that 
> this is always done programatically, which gives us control over the 
> authentication and authorization mechanisms. Previously, when 
> {{LOCAL_JMX=no}}, Cassandra would allow the JMX setup to be done by the built 
> in JVM agent, which delegates to 
> {{sun.management.jmxremote.ConnectorBootstrap}} to do the actual JMX & RMI 
> setup. 
> This change has introduced a regression when SSL is enabled for JMX 
> connections, namely that now it is not possible to start C* with only the 
> server-side elements of the SSL setup specified. That is, if enabling SSL 
> with {{com.sun.management.jmxremote.ssl=true}}, it should only be necessary 
> to specify a keystore (via {{javax.net.ssl.keyStore}}), and a truststore 
> should only be necessary if client authentication is also enabled 
> ({{com.sun.management.jmxremote.ssl.need.client.auth=true}}). 
> As it is, C* cannot currently startup without a truststore containing the 
> server's own certificate, which is clearly a bug.



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

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

[jira] [Updated] (CASSANDRA-10091) Integrated JMX authn & authz

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-10091:
-
Labels: doc-impacting security  (was: doc-impacting)

> Integrated JMX authn & authz
> 
>
> Key: CASSANDRA-10091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Configuration, Lifecycle, Observability
>Reporter: Jan Karlsson
>Assignee: Sam Tunnicliffe
>Priority: Minor
>  Labels: doc-impacting, security
> Fix For: 3.6
>
>
> It would be useful to authenticate with JMX through Cassandra's internal 
> authentication. This would reduce the overhead of keeping passwords in files 
> on the machine and would consolidate passwords to one location. It would also 
> allow the possibility to handle JMX permissions in Cassandra.
> It could be done by creating our own JMX server and setting custom classes 
> for the authenticator and authorizer. We could then add some parameters where 
> the user could specify what authenticator and authorizer to use in case they 
> want to make their own.
> This could also be done by creating a premain method which creates a jmx 
> server. This would give us the feature without changing the Cassandra code 
> itself. However I believe this would be a good feature to have in Cassandra.
> I am currently working on a solution which creates a JMX server and uses a 
> custom authenticator and authorizer. It is currently build as a premain, 
> however it would be great if we could put this in Cassandra instead.



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

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

[jira] [Updated] (CASSANDRA-10551) Investigate JMX auth using JMXMP & SASL

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-10551:
-
Labels: security  (was: )

> Investigate JMX auth using JMXMP & SASL
> ---
>
> Key: CASSANDRA-10551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10551
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sam Tunnicliffe
>Assignee: Jan Karlsson
>Priority: Major
>  Labels: security
>
> (broken out from CASSANDRA-10091)
> We should look into whether using 
> [JMXMP|https://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/] would 
> enable JMX authentication using SASL. If so, could we then define a custom 
> SaslServer which wraps a SaslNegotiator instance provided by the configured 
> IAuthenticator. 
> An intial look at the 
> [JMXMP|http://docs.oracle.com/cd/E19698-01/816-7609/6mdjrf873/] docs, 
> particularly section *11.4.2 SASL Provider*, suggests this might be feasible.



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

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

[jira] [Updated] (CASSANDRA-9085) Bind JMX to localhost unless explicitly configured otherwise

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-9085:

Labels: security  (was: )

> Bind JMX to localhost unless explicitly configured otherwise
> 
>
> Key: CASSANDRA-9085
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9085
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Observability
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
>Priority: Critical
>  Labels: security
> Fix For: 2.0.14, 2.1.4
>
>
> Cassandra's default JMX config can lead to someone executing arbitrary code:  
> see http://www.mail-archive.com/user@cassandra.apache.org/msg41819.html



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

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

[jira] [Updated] (CASSANDRA-13314) Config file based SSL settings

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13314:
-
Labels: security  (was: )

> Config file based SSL settings
> --
>
> Key: CASSANDRA-13314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13314
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration, Tools
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
>  Labels: security
>
> As follow up of CASSANDRA-13259, I'd like to continue discussing how we can 
> make SSL less awkward to use and further move SSL related code out of our 
> code base. Currently we construct our own SSLContext in SSLFactory based on 
> EncryptionOptions passed by the MessagingService or any individual tool where 
> we need to offer SSL support. This leads to a situation where the user has 
> not only to learn how to enable the correct settings in cassandra.yaml, but 
> these settings must also be reflected in each tool's own command line 
> options. As argued in CASSANDRA-13259, these settings could be done as well 
> by setting the appropriate system and security properties 
> ([overview|http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization])
>  and we should just point the user to the right files to do that (jvm.options 
> and java.security) and make sure that daemon and all affected tools will 
> source them. 
> Since giving this a quick try on my WIP branch, I've noticed the following 
> issues in doing so:
> * Keystore passwords will show up in process list 
> (-Djavax.net.ssl.keyStorePassword=..). We should keep the password setting in 
> cassandra.yaml and clis and do a System.setProperty() if they have been 
> provided. 
> * It's only possible to configure settings for a single default 
> key-/truststore. Since we currently allow configuring both 
> ServerEncryptionOptions and ClientEncryptionOptions with different settings, 
> we'd have to make this a breaking change. I don't really see why you would 
> want to use different stores for node-to-node and node-to-client, but that 
> wouldn't be possible anymore. 
> * This would probably only make sense if we really remove the affected CLI 
> options, or we'll end up with just another way to configure this stuff. This 
> will break existing scripts and obsolete existing documentation.
> Any opinions?



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

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

[jira] [Updated] (CASSANDRA-14064) Allow using file based certificates instead of keystores

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14064:
-
Labels: security  (was: )

> Allow using file based certificates instead of keystores
> 
>
> Key: CASSANDRA-14064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14064
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Streaming and Messaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> The requirement of having to use a secure archive (keystore) for your 
> certificates and keys is not very common outside the Java ecosystem. Most 
> servers will accept individual certificate and key files and will come with 
> instructions how to generate those using openssl. This should also be an 
> option for Cassandra for users who see no reason in additionally having to 
> deal with keystores.



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

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

[jira] [Updated] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14223:
-
Labels: security  (was: )

> Provide ability to do custom certificate validations (e.g. hostname 
> validation, certificate revocation checks)
> --
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ron Blechman
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations, 
> such as hostname validatation and certificate revocation checking against 
> CRLs and/or using OCSP. 
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead 
> of forcing the creation of a new SSLContext using SSLContext.getInstance().  
> Using the default SSLContext would allow a user to plug in their own custom 
> SSLSocketFactory via the java.security properties file. The custom 
> SSLSocketFactory could create a default SSLContext  that was customized to do 
> any extra validation such as certificate revocation, host name validation, 
> etc.



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

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

[jira] [Updated] (CASSANDRA-14222) Add hot reloading of SSL Certificates capability to Cassandra

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14222:
-
Labels: security  (was: )

> Add hot reloading of SSL Certificates capability to Cassandra
> -
>
> Key: CASSANDRA-14222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14222
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> Cassandra does not currently hot reload SSL certificates. For ease of 
> operation it would be useful if we add this capability. This patch would 
> watch changes to the truststore & keystore and would reload them when they're 
> changed.



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

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

[jira] [Updated] (CASSANDRA-13971) Automatic certificate management using Vault

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-13971:
-
Labels: security  (was: )

> Automatic certificate management using Vault
> 
>
> Key: CASSANDRA-13971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13971
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Streaming and Messaging
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>  Labels: security
> Fix For: 4.x
>
>
> We've been adding security features during the last years to enable users to 
> secure their clusters, if they are willing to use them and do so correctly. 
> Some features are powerful and easy to work with, such as role based 
> authorization. Other features that require to manage a local keystore are 
> rather painful to deal with. Think about setting up SSL..
> To be fair, keystore related issues and certificate handling hasn't been 
> invented by us. We're just following Java standards there. But that doesn't 
> mean that we absolutely have to, if there are better options. I'd like to 
> give it a shoot and find out if we can automate certificate/key handling 
> (PKI) by using external APIs. In this case, the implementation will be based 
> on [Vault|https://vaultproject.io]. But certificate management services 
> offered by cloud providers may also be able to handle the use-case and I 
> intend to create a generic, pluggable API for that.



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

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

[jira] [Updated] (CASSANDRA-14102) Vault support for transparent data encryption

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14102:
-
Labels: encryption security  (was: encryption)

> Vault support for transparent data encryption
> -
>
> Key: CASSANDRA-14102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14102
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>  Labels: encryption, security
> Fix For: 4.x
>
>
> Transparent data encryption provided by CASSANDRA-9945 can currently be used 
> for commitlog and hints. The default {{KeyProvider}} implementation that we 
> ship allows to use a local keystore for storing and retrieving keys. Thanks 
> to the pluggable handling of the {{KeyStore}} provider and basic Vault 
> related classes introduced in CASSANDRA-13971, a Vault based implementation 
> can be provided as {{KeyProvider}} as well. 



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

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

[jira] [Commented] (CASSANDRA-14167) IndexOutOfBoundsException when selecting column counter and consistency quorum

[Dhawal Mody (JIRA)]

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

Dhawal Mody commented on CASSANDRA-14167:
-

I am facing the similar issue after upgrading from 3.0.15 to 3.11.1 .. 
The system.log file - has a bunch of these warnings- 
WARN  [ReadStage-15] 2018-02-20 14:39:49,929 
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
Thread[ReadStage-15,5,main]: {}
java.lang.IndexOutOfBoundsException: null
at java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_141]
at java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) 
~[na:1.8.0_141]
at 
org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
~[apache-cassandra-3.11.1.jar:3.11.1]
at org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87) 
~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:345) 
~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
~[apache-cassandra-3.11.1.jar:3.11.1]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_141]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
 [apache-cassandra-3.11.1.jar:3.11.1]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
[apache-cassandra-3.11.1.jar:3.11.1]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_141]

Can someone please advise on how to resolve this? 
This is causing application failure to write data (it uses consistency level - 
local_quoram for both reads and writes). 

> IndexOutOfBoundsException when selecting column counter and consistency quorum
> --
>
> Key: CASSANDRA-14167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14167
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11.1
> Ubuntu 14-04
>Reporter: Tristan Last
>Priority: Major
>
> This morning I upgraded my cluster from 3.11.0 to 3.11.1 and it appears when 
> I perform a query on a counter specifying the column name cassandra throws 
> the following exception:
> {code:java}
> WARN [ReadStage-1] 2018-01-15 10:58:30,121 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-1,5,main]: {}
> java.lang.IndexOutOfBoundsException: null
> java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_144]
> java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) ~[na:1.8.0_144]
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
>  

[jira] [Assigned] (CASSANDRA-14065) Docs: Fix page width exceeding the viewport

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-14065:
--

Assignee: (was: Stefan Podkowinski)

> Docs: Fix page width exceeding the viewport
> ---
>
> Key: CASSANDRA-14065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14065
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
> Attachments: 0001-Docs-optimize-css-layouting.patch, 
> 0002-site_svn-css.diff, 0003-site_svn-fixnavigation.diff, 14065-trunk.patch
>
>
> Ticket for [#175|https://github.com/apache/cassandra/pull/175] / 
> [#176|https://github.com/apache/cassandra/pull/176].
> The layout seems to adapt more natural after applying the patch with less 
> overlapping content. Seems to fix a real issue with our template.
> However, I'm not really sure about the extra.css changes, as the compile 
> website (build via jekyll) doesn't seem to reference the css file anywhere..



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

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

[jira] [Updated] (CASSANDRA-13569) Schedule schema pulls just once per endpoint

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13569:
---
Attachment: 13569-trunk.patch

> Schedule schema pulls just once per endpoint
> 
>
> Key: CASSANDRA-13569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13569
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Stefan Podkowinski
>Priority: Major
> Attachments: 13569-trunk.patch
>
>
> Schema mismatches detected through gossip will get resolved by calling 
> {{MigrationManager.maybeScheduleSchemaPull}}. This method may decide to 
> schedule execution of {{MigrationTask}}, but only after using a 
> {{MIGRATION_DELAY_IN_MS = 6}} delay (for reasons unclear to me). 
> Meanwhile, as long as the migration task hasn't been executed, we'll continue 
> to have schema mismatches reported by gossip and will have corresponding 
> {{maybeScheduleSchemaPull}} calls, which will schedule further tasks with the 
> mentioned delay. Some local testing shows that dozens of tasks for the same 
> endpoint will eventually be executed and causing the same, stormy behavior 
> for this very endpoints.
> My proposal would be to simply not schedule new tasks for the same endpoint, 
> in case we still have pending tasks waiting for execution after 
> {{MIGRATION_DELAY_IN_MS}}.



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

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

[jira] [Updated] (CASSANDRA-13569) Schedule schema pulls just once per endpoint

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13569:
---
Status: Open  (was: Patch Available)

> Schedule schema pulls just once per endpoint
> 
>
> Key: CASSANDRA-13569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13569
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Schema mismatches detected through gossip will get resolved by calling 
> {{MigrationManager.maybeScheduleSchemaPull}}. This method may decide to 
> schedule execution of {{MigrationTask}}, but only after using a 
> {{MIGRATION_DELAY_IN_MS = 6}} delay (for reasons unclear to me). 
> Meanwhile, as long as the migration task hasn't been executed, we'll continue 
> to have schema mismatches reported by gossip and will have corresponding 
> {{maybeScheduleSchemaPull}} calls, which will schedule further tasks with the 
> mentioned delay. Some local testing shows that dozens of tasks for the same 
> endpoint will eventually be executed and causing the same, stormy behavior 
> for this very endpoints.
> My proposal would be to simply not schedule new tasks for the same endpoint, 
> in case we still have pending tasks waiting for execution after 
> {{MIGRATION_DELAY_IN_MS}}.



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

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

[jira] [Assigned] (CASSANDRA-13569) Schedule schema pulls just once per endpoint

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-13569:
--

Assignee: (was: Stefan Podkowinski)

> Schedule schema pulls just once per endpoint
> 
>
> Key: CASSANDRA-13569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13569
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Stefan Podkowinski
>Priority: Major
>
> Schema mismatches detected through gossip will get resolved by calling 
> {{MigrationManager.maybeScheduleSchemaPull}}. This method may decide to 
> schedule execution of {{MigrationTask}}, but only after using a 
> {{MIGRATION_DELAY_IN_MS = 6}} delay (for reasons unclear to me). 
> Meanwhile, as long as the migration task hasn't been executed, we'll continue 
> to have schema mismatches reported by gossip and will have corresponding 
> {{maybeScheduleSchemaPull}} calls, which will schedule further tasks with the 
> mentioned delay. Some local testing shows that dozens of tasks for the same 
> endpoint will eventually be executed and causing the same, stormy behavior 
> for this very endpoints.
> My proposal would be to simply not schedule new tasks for the same endpoint, 
> in case we still have pending tasks waiting for execution after 
> {{MIGRATION_DELAY_IN_MS}}.



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

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

[jira] [Updated] (CASSANDRA-13569) Schedule schema pulls just once per endpoint

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13569:
---
Fix Version/s: (was: 3.11.x)
   (was: 4.x)
   (was: 3.0.x)

> Schedule schema pulls just once per endpoint
> 
>
> Key: CASSANDRA-13569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13569
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> Schema mismatches detected through gossip will get resolved by calling 
> {{MigrationManager.maybeScheduleSchemaPull}}. This method may decide to 
> schedule execution of {{MigrationTask}}, but only after using a 
> {{MIGRATION_DELAY_IN_MS = 6}} delay (for reasons unclear to me). 
> Meanwhile, as long as the migration task hasn't been executed, we'll continue 
> to have schema mismatches reported by gossip and will have corresponding 
> {{maybeScheduleSchemaPull}} calls, which will schedule further tasks with the 
> mentioned delay. Some local testing shows that dozens of tasks for the same 
> endpoint will eventually be executed and causing the same, stormy behavior 
> for this very endpoints.
> My proposal would be to simply not schedule new tasks for the same endpoint, 
> in case we still have pending tasks waiting for execution after 
> {{MIGRATION_DELAY_IN_MS}}.



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

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

[jira] [Resolved] (CASSANDRA-13314) Config file based SSL settings

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski resolved CASSANDRA-13314.

   Resolution: Won't Fix
Fix Version/s: (was: 4.x)

Closing this ticket for now, as we haven't moved on in the discussion for 
months and the idea is likely obsolete by now, with the current netty based 
stack.

> Config file based SSL settings
> --
>
> Key: CASSANDRA-13314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13314
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration, Tools
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
>
> As follow up of CASSANDRA-13259, I'd like to continue discussing how we can 
> make SSL less awkward to use and further move SSL related code out of our 
> code base. Currently we construct our own SSLContext in SSLFactory based on 
> EncryptionOptions passed by the MessagingService or any individual tool where 
> we need to offer SSL support. This leads to a situation where the user has 
> not only to learn how to enable the correct settings in cassandra.yaml, but 
> these settings must also be reflected in each tool's own command line 
> options. As argued in CASSANDRA-13259, these settings could be done as well 
> by setting the appropriate system and security properties 
> ([overview|http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization])
>  and we should just point the user to the right files to do that (jvm.options 
> and java.security) and make sure that daemon and all affected tools will 
> source them. 
> Since giving this a quick try on my WIP branch, I've noticed the following 
> issues in doing so:
> * Keystore passwords will show up in process list 
> (-Djavax.net.ssl.keyStorePassword=..). We should keep the password setting in 
> cassandra.yaml and clis and do a System.setProperty() if they have been 
> provided. 
> * It's only possible to configure settings for a single default 
> key-/truststore. Since we currently allow configuring both 
> ServerEncryptionOptions and ClientEncryptionOptions with different settings, 
> we'd have to make this a breaking change. I don't really see why you would 
> want to use different stores for node-to-node and node-to-client, but that 
> wouldn't be possible anymore. 
> * This would probably only make sense if we really remove the affected CLI 
> options, or we'll end up with just another way to configure this stuff. This 
> will break existing scripts and obsolete existing documentation.
> Any opinions?



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

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

[jira] [Assigned] (CASSANDRA-13724) Externalize and cleanup build.xml dependencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-13724:
--

Assignee: (was: Stefan Podkowinski)

> Externalize and cleanup build.xml dependencies
> --
>
> Key: CASSANDRA-13724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13724
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Podkowinski
>Priority: Minor
> Attachments: 13724-1st-take.patch
>
>
> As discussed in CASSANDRA-12996, the build.xml has become pretty messy and 
> could use some cleanup and additional inline comments. Maybe parts of it 
> could be even split up or externalized.



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

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

[jira] [Updated] (CASSANDRA-13724) Externalize and cleanup build.xml dependencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13724:
---
Status: Awaiting Feedback  (was: Open)

> Externalize and cleanup build.xml dependencies
> --
>
> Key: CASSANDRA-13724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13724
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Podkowinski
>Priority: Minor
> Attachments: 13724-1st-take.patch
>
>
> As discussed in CASSANDRA-12996, the build.xml has become pretty messy and 
> could use some cleanup and additional inline comments. Maybe parts of it 
> could be even split up or externalized.



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

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

[jira] [Updated] (CASSANDRA-13724) Externalize and cleanup build.xml dependencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13724:
---
Fix Version/s: (was: 4.x)
   Status: Open  (was: Patch Available)

> Externalize and cleanup build.xml dependencies
> --
>
> Key: CASSANDRA-13724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13724
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Attachments: 13724-1st-take.patch
>
>
> As discussed in CASSANDRA-12996, the build.xml has become pretty messy and 
> could use some cleanup and additional inline comments. Maybe parts of it 
> could be even split up or externalized.



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

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

[jira] [Updated] (CASSANDRA-13724) Externalize and cleanup build.xml dependencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13724:
---
Attachment: 13724-1st-take.patch

> Externalize and cleanup build.xml dependencies
> --
>
> Key: CASSANDRA-13724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13724
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 13724-1st-take.patch
>
>
> As discussed in CASSANDRA-12996, the build.xml has become pretty messy and 
> could use some cleanup and additional inline comments. Maybe parts of it 
> could be even split up or externalized.



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

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

[jira] [Updated] (CASSANDRA-13023) Add droppable tombstone metrics

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13023:
---
Attachment: (was: 13023-3.0.patch)

> Add droppable tombstone metrics
> ---
>
> Key: CASSANDRA-13023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13023
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> Currently it's only possible to inspect the ratio of droppable tombstones on 
> sstable basis using the {{sstablemetadata}} tool. It would be very useful to 
> have this information provided as part of Cassandra metrics as well, e.g. to 
> get an idea on the effectiveness of tombstone eviction during compactions 
> over time.



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

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

[jira] [Updated] (CASSANDRA-13023) Add droppable tombstone metrics

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13023:
---
Assignee: (was: Stefan Podkowinski)
  Status: Open  (was: Patch Available)

> Add droppable tombstone metrics
> ---
>
> Key: CASSANDRA-13023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13023
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Stefan Podkowinski
>Priority: Major
>
> Currently it's only possible to inspect the ratio of droppable tombstones on 
> sstable basis using the {{sstablemetadata}} tool. It would be very useful to 
> have this information provided as part of Cassandra metrics as well, e.g. to 
> get an idea on the effectiveness of tombstone eviction during compactions 
> over time.



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

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

[jira] [Assigned] (CASSANDRA-12793) invalid jvm type and architecture [cassandra-env.sh]

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-12793:
--

Assignee: (was: Stefan Podkowinski)

> invalid jvm type and architecture [cassandra-env.sh]
> 
>
> Key: CASSANDRA-12793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12793
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: ubuntu 16.04, openjdk 1.8.0_91
>Reporter: Ali Ebrahiminejad
>Priority: Minor
> Fix For: 3.11.x
>
> Attachments: 12793.patch
>
>
> In cassandra-env.sh the part that determines the type of JVM we'll be running 
> on doesn't provide the right answer for openjdk 1.8.0_91.
> value of java_ver_output is "openjdk version "1.8.0_91" OpenJDK Runtime 
> Environment (build 1.8.0_91-8u91-b14-3ubuntu1~16.04.1-b14) OpenJDK 64-Bit 
> Server VM (build 25.91-b14, mixed mode)", yet the command looks for "java 
> version" (jvm=`echo "$java_ver_output" | grep -A 1 'java version' ...) which 
> does not exist.
> I guess it should be replaced with jvm=`echo "$java_ver_output" | grep -A 1 
> '[openjdk|java] version' | awk 'NR==2 {print $1}'`



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

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

[jira] [Assigned] (CASSANDRA-13175) Integrate "Error Prone" Code Analyzer

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-13175:
--

Assignee: (was: Stefan Podkowinski)

> Integrate "Error Prone" Code Analyzer
> -
>
> Key: CASSANDRA-13175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13175
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Priority: Major
> Attachments: 0001-Add-Error-Prone-code-analyzer.patch, 
> checks-2_2.out, checks-3_0.out, checks-trunk.out
>
>
> I've been playing with [Error Prone|http://errorprone.info/] by integrating 
> it into the build process and to see what kind of warnings it would produce. 
> So far I'm positively impressed by the coverage and usefulness of some of the 
> implemented checks. See attachments for results.
> Unfortunately there are still some issues on how the analyzer is effecting 
> generated code and used guava versions, see 
> [#492|https://github.com/google/error-prone/issues/492]. In case those issues 
> have been solved and the resulting code isn't affected by the analyzer, I'd 
> suggest to add it to trunk with warn only behaviour and some less useful 
> checks disabled. Alternatively a new ant target could be added, maybe with 
> build breaking checks and CI integration.



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

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

[jira] [Updated] (CASSANDRA-13487) Generate snapshot packages through Jenkins

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13487:
---
   Resolution: Won't Fix
 Assignee: (was: Stefan Podkowinski)
Fix Version/s: (was: 3.11.x)
   (was: 4.x)
   (was: 3.0.x)
   (was: 2.2.x)
   Status: Resolved  (was: Patch Available)

> Generate snapshot packages through Jenkins
> --
>
> Key: CASSANDRA-13487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13487
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Build
>Reporter: Stefan Podkowinski
>Priority: Major
>
> Creating packages through the new docker based build scripts now work pretty 
> much independent from any local environment, as long as docker is available, 
> e.g. also on Jenkins. Having daily snapshots available for deb/rpm artifacts 
> would enable us to provide users dev-releases for testing and validating 
> fixes.
> I've created a branch for the Jenkins integration, which can be found here:
> https://github.com/spodkowinski/cassandra-builds/tree/jenkins_debrpm
> The major issue I'm currently struggling with is the handling of the actual 
> version value. We need to find a way to have Jenkins recognize the correct 
> version for the branch being build. Also we must create $version-SNAPSHOT 
> packages, as builds are not official releases and we should not have any 
> packages for versions that aren't published yet.
> The Debian build process will use the version defined in 
> {{debian/changelog}}. Adding a -SNAPSHOT suffix for the version should work, 
> but this has to be handled manually and care must be taken to change the 
> value back again for a regular release.
> With RPMs, the version must be set for {{cassandra.spec}}, which is currently 
> done by running {noformat}rpmbuild --define="version ${CASSANDRA_VERSION}" 
> -ba ./redhat/cassandra.spec{noformat}, where the version is passed as a 
> parameter by {{build-scripts/cassandra-rpm-packaging.sh}}. Maybe we could 
> grep the version from build.xml here?
> So I wonder if there any way we can keep track of the version in a single 
> place, such as build.xml or CHANGES. Afterwards we also need to enable a 
> SNAPSHOT mode, maybe by setting a Jenkins environment value.
> /cc [~mshuler]



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

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

[jira] [Updated] (CASSANDRA-13487) Generate snapshot packages through Jenkins

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13487:
---
Attachment: (was: 13487.patch)

> Generate snapshot packages through Jenkins
> --
>
> Key: CASSANDRA-13487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13487
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Build
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> Creating packages through the new docker based build scripts now work pretty 
> much independent from any local environment, as long as docker is available, 
> e.g. also on Jenkins. Having daily snapshots available for deb/rpm artifacts 
> would enable us to provide users dev-releases for testing and validating 
> fixes.
> I've created a branch for the Jenkins integration, which can be found here:
> https://github.com/spodkowinski/cassandra-builds/tree/jenkins_debrpm
> The major issue I'm currently struggling with is the handling of the actual 
> version value. We need to find a way to have Jenkins recognize the correct 
> version for the branch being build. Also we must create $version-SNAPSHOT 
> packages, as builds are not official releases and we should not have any 
> packages for versions that aren't published yet.
> The Debian build process will use the version defined in 
> {{debian/changelog}}. Adding a -SNAPSHOT suffix for the version should work, 
> but this has to be handled manually and care must be taken to change the 
> value back again for a regular release.
> With RPMs, the version must be set for {{cassandra.spec}}, which is currently 
> done by running {noformat}rpmbuild --define="version ${CASSANDRA_VERSION}" 
> -ba ./redhat/cassandra.spec{noformat}, where the version is passed as a 
> parameter by {{build-scripts/cassandra-rpm-packaging.sh}}. Maybe we could 
> grep the version from build.xml here?
> So I wonder if there any way we can keep track of the version in a single 
> place, such as build.xml or CHANGES. Afterwards we also need to enable a 
> SNAPSHOT mode, maybe by setting a Jenkins environment value.
> /cc [~mshuler]



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

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

[jira] [Updated] (CASSANDRA-12870) Calculate pending ranges for identical KS settings just once

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-12870:
---
Attachment: (was: 12870-trunk.patch)

> Calculate pending ranges for identical KS settings just once
> 
>
> Key: CASSANDRA-12870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12870
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> The {{TokenMetadata.calculatePendingRanges()}} operation can be very 
> expensive and already has been subject to micro optimization in 
> CASSANDRA-9258. Instead of further optimizing the calculation itself, I'd 
> like to prevent it from being executed as often by only calling it just once 
> for all keyspaces sharing identical replication settings. 



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

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

[jira] [Updated] (CASSANDRA-12870) Calculate pending ranges for identical KS settings just once

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-12870:
---
 Assignee: (was: Stefan Podkowinski)
Fix Version/s: (was: 4.x)
   Status: Open  (was: Patch Available)

> Calculate pending ranges for identical KS settings just once
> 
>
> Key: CASSANDRA-12870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12870
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Stefan Podkowinski
>Priority: Major
>
> The {{TokenMetadata.calculatePendingRanges()}} operation can be very 
> expensive and already has been subject to micro optimization in 
> CASSANDRA-9258. Instead of further optimizing the calculation itself, I'd 
> like to prevent it from being executed as often by only calling it just once 
> for all keyspaces sharing identical replication settings. 



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

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

[jira] [Assigned] (CASSANDRA-11684) Cleanup key ranges during compaction

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-11684:
--

Assignee: (was: Stefan Podkowinski)

> Cleanup key ranges during compaction
> 
>
> Key: CASSANDRA-11684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11684
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Stefan Podkowinski
>Priority: Major
>
> Currently cleanup is considered an optional, manual operation that users are 
> told to run to free disk space after a node was affected by topology changes. 
> However, unmanaged key ranges could also end up on a node through other ways, 
> e.g. manual added sstable files by an admin. 
> I'm also not sure unmanaged data is really that harmless and cleanup should 
> really be optional, if you don't need to reclaim the disk space. When it 
> comes to repairs, users are expected to purge a node after downtime in case 
> it was not fully covered by a repair within gc_grace afterwards, in order to 
> avoid re-introducing deleted data. But the same could happen with unmanaged 
> data, e.g. after topology changes activate unmanaged ranges again or after 
> restoring backups.
> I'd therefor suggest to avoid rewriting key ranges no longer belonging to a 
> node and older than gc_grace during compactions. 
> Maybe we could also introduce another CLEANUP_COMPACTION operation to find 
> candidates based on SSTable.first/last in case we don't have pending regular 
> or tombstone compactions.



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

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

[jira] [Assigned] (CASSANDRA-12126) CAS Reads Inconsistencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-12126:
--

Assignee: (was: Stefan Podkowinski)

> CAS Reads Inconsistencies 
> --
>
> Key: CASSANDRA-12126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12126
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: sankalp kohli
>Priority: Major
>
> While looking at the CAS code in Cassandra, I found a potential issue with 
> CAS Reads. Here is how it can happen with RF=3
> 1) You issue a CAS Write and it fails in the propose phase. A machine replies 
> true to a propose and saves the commit in accepted filed. The other two 
> machines B and C does not get to the accept phase. 
> Current state is that machine A has this commit in paxos table as accepted 
> but not committed and B and C does not. 
> 2) Issue a CAS Read and it goes to only B and C. You wont be able to read the 
> value written in step 1. This step is as if nothing is inflight. 
> 3) Issue another CAS Read and it goes to A and B. Now we will discover that 
> there is something inflight from A and will propose and commit it with the 
> current ballot. Now we can read the value written in step 1 as part of this 
> CAS read.
> If we skip step 3 and instead run step 4, we will never learn about value 
> written in step 1. 
> 4. Issue a CAS Write and it involves only B and C. This will succeed and 
> commit a different value than step 1. Step 1 value will never be seen again 
> and was never seen before. 
> If you read the Lamport “paxos made simple” paper and read section 2.3. It 
> talks about this issue which is how learners can find out if majority of the 
> acceptors have accepted the proposal. 
> In step 3, it is correct that we propose the value again since we dont know 
> if it was accepted by majority of acceptors. When we ask majority of 
> acceptors, and more than one acceptors but not majority has something in 
> flight, we have no way of knowing if it is accepted by majority of acceptors. 
> So this behavior is correct. 
> However we need to fix step 2, since it caused reads to not be linearizable 
> with respect to writes and other reads. In this case, we know that majority 
> of acceptors have no inflight commit which means we have majority that 
> nothing was accepted by majority. I think we should run a propose step here 
> with empty commit and that will cause write written in step 1 to not be 
> visible ever after. 
> With this fix, we will either see data written in step 1 on next serial read 
> or will never see it which is what we want. 



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

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

[jira] [Updated] (CASSANDRA-12126) CAS Reads Inconsistencies

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-12126:
---
Status: Open  (was: Patch Available)

> CAS Reads Inconsistencies 
> --
>
> Key: CASSANDRA-12126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12126
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: sankalp kohli
>Priority: Major
>
> While looking at the CAS code in Cassandra, I found a potential issue with 
> CAS Reads. Here is how it can happen with RF=3
> 1) You issue a CAS Write and it fails in the propose phase. A machine replies 
> true to a propose and saves the commit in accepted filed. The other two 
> machines B and C does not get to the accept phase. 
> Current state is that machine A has this commit in paxos table as accepted 
> but not committed and B and C does not. 
> 2) Issue a CAS Read and it goes to only B and C. You wont be able to read the 
> value written in step 1. This step is as if nothing is inflight. 
> 3) Issue another CAS Read and it goes to A and B. Now we will discover that 
> there is something inflight from A and will propose and commit it with the 
> current ballot. Now we can read the value written in step 1 as part of this 
> CAS read.
> If we skip step 3 and instead run step 4, we will never learn about value 
> written in step 1. 
> 4. Issue a CAS Write and it involves only B and C. This will succeed and 
> commit a different value than step 1. Step 1 value will never be seen again 
> and was never seen before. 
> If you read the Lamport “paxos made simple” paper and read section 2.3. It 
> talks about this issue which is how learners can find out if majority of the 
> acceptors have accepted the proposal. 
> In step 3, it is correct that we propose the value again since we dont know 
> if it was accepted by majority of acceptors. When we ask majority of 
> acceptors, and more than one acceptors but not majority has something in 
> flight, we have no way of knowing if it is accepted by majority of acceptors. 
> So this behavior is correct. 
> However we need to fix step 2, since it caused reads to not be linearizable 
> with respect to writes and other reads. In this case, we know that majority 
> of acceptors have no inflight commit which means we have majority that 
> nothing was accepted by majority. I think we should run a propose step here 
> with empty commit and that will cause write written in step 1 to not be 
> visible ever after. 
> With this fix, we will either see data written in step 1 on next serial read 
> or will never see it which is what we want. 



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

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

[jira] [Updated] (CASSANDRA-14243) cqlshrc.sample uses incorrect option for time formatting

[Alex Ott (JIRA)]

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

Alex Ott updated CASSANDRA-14243:
-
Flags: Patch

> cqlshrc.sample uses incorrect option for time formatting
> 
>
> Key: CASSANDRA-14243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14243
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Alex Ott
>Priority: Trivial
>
> Sample cqlshrc file in conf/cqlshrc.sample uses incorrect option 
> (datetimeformat) instead of correct one (time_format).
> The datetimeformat is the sub-option of the COPY FROM command, not cqlsh 
> itself.
>  



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

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

[jira] [Updated] (CASSANDRA-14243) cqlshrc.sample uses incorrect option for time formatting

[Alex Ott (JIRA)]

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

Alex Ott updated CASSANDRA-14243:
-
Flags:   (was: Patch)

> cqlshrc.sample uses incorrect option for time formatting
> 
>
> Key: CASSANDRA-14243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14243
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Alex Ott
>Priority: Trivial
>
> Sample cqlshrc file in conf/cqlshrc.sample uses incorrect option 
> (datetimeformat) instead of correct one (time_format).
> The datetimeformat is the sub-option of the COPY FROM command, not cqlsh 
> itself.
>  



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

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

[jira] [Commented] (CASSANDRA-14243) cqlshrc.sample uses incorrect option for time formatting

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-14243:


GitHub user alexott opened a pull request:

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

fix for CASSANDRA-14243

`datetimeformat` option that was used in the `conf/cqlshrc.sample` file is 
sub-option of
the `COPY FROM` command, not of the `cqlsh` itself.

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

$ git pull https://github.com/alexott/cassandra CASSANDRA-14243

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

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

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

This closes #197


commit 53df3c118f4bb73494020b8414401540121a4c5d
Author: Alex Ott 
Date:   2018-02-20T12:23:21Z

fix for CASSANDRA-14243

`datetimeformat` option that was used in the `conf/cqlshrc.sample` file is 
sub-option of
the `COPY FROM` command, not of the `cqlsh` itself.




> cqlshrc.sample uses incorrect option for time formatting
> 
>
> Key: CASSANDRA-14243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14243
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Alex Ott
>Priority: Trivial
>
> Sample cqlshrc file in conf/cqlshrc.sample uses incorrect option 
> (datetimeformat) instead of correct one (time_format).
> The datetimeformat is the sub-option of the COPY FROM command, not cqlsh 
> itself.
>  



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

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

[jira] [Created] (CASSANDRA-14243) cqlshrc.sample uses incorrect option for time formatting

[Alex Ott (JIRA)]

Alex Ott created CASSANDRA-14243:


 Summary: cqlshrc.sample uses incorrect option for time formatting
 Key: CASSANDRA-14243
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14243
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Alex Ott


Sample cqlshrc file in conf/cqlshrc.sample uses incorrect option 
(datetimeformat) instead of correct one (time_format).

The datetimeformat is the sub-option of the COPY FROM command, not cqlsh itself.

 



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

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

[jira] [Commented] (CASSANDRA-14055) Index redistribution breaks SASI index

[Ludovic Boutros (JIRA)]

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

Ludovic Boutros commented on CASSANDRA-14055:
-

[~jrwest],

I understand your changings and your explanations on the reference counting 
issue.
It looks good to me.

Thank you.

> Index redistribution breaks SASI index
> --
>
> Key: CASSANDRA-14055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14055
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
>Reporter: Ludovic Boutros
>Assignee: Ludovic Boutros
>Priority: Major
>  Labels: patch
> Fix For: 3.11.x, 4.x
>
> Attachments: 14055-jrwest-3.11.patch, 14055-jrwest-trunk.patch, 
> CASSANDRA-14055-jrwest.patch, CASSANDRA-14055.patch, CASSANDRA-14055.patch, 
> CASSANDRA-14055.patch
>
>
> During index redistribution process, a new view is created.
> During this creation, old indexes should be released.
> But, new indexes are "attached" to the same SSTable as the old indexes.
> This leads to the deletion of the last SASI index file and breaks the index.
> The issue is in this function : 
> [https://github.com/apache/cassandra/blob/9ee44db49b13d4b4c91c9d6332ce06a6e2abf944/src/java/org/apache/cassandra/index/sasi/conf/view/View.java#L62]



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

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