[jira] [Updated] (CASSANDRA-15295) Running into deadlock when do CommitLog initialization

2019-10-09 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15295:
-
Status: Changes Suggested  (was: Review In Progress)

Hi [~gzh1992n], thanks for the patch. When I looked at the issue closely, the 
deadlock can be avoided if we don't start a {{Thread}} in a static initializer 
block and calling a method on an partially initialized object. This is a 
classic concurrency issue. Now, the way you have solved it is by moving the 
error handling to a different class but I think it is still needs to go a bit 
further. I have mocked up a very minimal change here: 
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:15295-trunk?expand=1
 It is the minimal set of changes required to avoid the deadlock and it also 
ensures that we operate on a fully initialized object. We can incorporate your 
refactor as well but I think it is important to get the correctness issue 
resolved first. It also requires a bit more guarding in {{CommitLog::start()}} 
so it's not started twice.

I have also not completed evaluating whether this change will cause any other 
issues as we are changing initialization behavior.

> Running into deadlock when do CommitLog initialization
> --
>
> Key: CASSANDRA-15295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15295
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Commit Log
>Reporter: Zephyr Guo
>Assignee: Zephyr Guo
>Priority: Normal
> Attachments: jstack.log, pstack.log, screenshot-1.png, 
> screenshot-2.png, screenshot-3.png
>
>
> Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a 
> long time.
>  I used jstack to saw what happened. The main thread stuck in 
> *AbstractCommitLogSegmentManager.awaitAvailableSegment*
>  !screenshot-1.png! 
> The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it 
> was not actually running.  
>  !screenshot-2.png! 
> And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on 
> java class initialization.
>   !screenshot-3.png! 
> This is a deadlock obviously. CommitLog waits for a CommitLogSegment when 
> initializing. In this moment, the CommitLog class is not initialized and the 
> main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a 
> CommitLogSegment with exception and call *CommitLog.handleCommitError*(static 
> method).  COMMIT-LOG-ALLOCATOR will block on this line because CommitLog 
> class is still initializing.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-10-08 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15319:
-
  Fix Version/s: 4.x
 3.11.x
 3.0.x
 2.2.x
Source Control Link: 
https://github.com/dineshjoshi/cassandra/commit/5d401f3a3912d791aaedc4314ce5063a9eedeaec
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-10-08 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15319:
--

Thanks for the contribution. Committed!

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-10-08 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15319:
-
Status: Ready to Commit  (was: Review In Progress)

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-10-08 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15319:
-
Reviewers: Alex Petrov, Dinesh Joshi  (was: Dinesh Joshi)

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh

2019-10-07 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

[~andrew.tolbert], looks like there are a few [test 
failures|https://circleci.com/gh/dineshjoshi/cassandra/1229#tests/containers/31].
 I could not spot anything obvious. Do you mind looking into them?

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments: 0001-Update-six-to-1.12.0.patch, 
> 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, 
> coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-10190) Python 3 support for cqlsh

2019-10-07 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-10190:
-
Status: Changes Suggested  (was: Review In Progress)

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments: 0001-Update-six-to-1.12.0.patch, 
> 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, 
> coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh

2019-10-07 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

Hi [~andrew.tolbert], thanks for the review comments. I have pulled your 
changes to my branch 
[here|https://github.com/dineshjoshi/cassandra/tree/10190-rebase-20190609]. The 
circleci tests are running 
[here|https://circleci.com/workflow-run/4806c5fa-537d-4964-894a-bc4b05958679]. 
If everything looks good, I'll do a final review, squash and merge so folks can 
start testing out Python 3 compatibility.

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments: 0001-Update-six-to-1.12.0.patch, 
> 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, 
> coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-10190) Python 3 support for cqlsh

2019-10-07 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-10190:
-
Reviewers: Andy Tolbert, Dinesh Joshi, Dinesh Joshi  (was: Andy Tolbert, 
Dinesh Joshi)
   Andy Tolbert, Dinesh Joshi, Dinesh Joshi  (was: Dinesh Joshi)
   Status: Review In Progress  (was: Patch Available)

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments: 0001-Update-six-to-1.12.0.patch, 
> 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, 
> coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh

2019-10-04 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

Hi [~ptbannister], the latest set of changes seem to help with the test 
failures. There is just 1 test failure that seems to be relevant. 
[https://circleci.com/gh/dineshjoshi/cassandra/1223#tests/containers/96] and 
[https://circleci.com/gh/dineshjoshi/cassandra/1222#tests/containers/4]

{{The failure is in the describe command (test_describe - 
cqlsh_tests.test_cqlsh.TestCqlsh}}{{cqlsh_tests/test_cqlsh.py):}}
{noformat}
E   AssertionError: assert ['CREATE KEYS...d, col)', ...] == ['CREATE 
KEYSP...d, col)', ...]
E At index 21 diff: 'CREATE INDEX test_val_idx ON test.test (val);' != 
'CREATE INDEX test_col_idx ON test.test (col);'
E Use -v to get the full diff
{noformat}

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-10-01 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15319:
--

+1

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-10-01 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15319:
--

[~jmeredithco] I think the changes look good. I just left 1 comment. Once 
resolved I am +1. [~ifesdjeen] do you mind doing a second review?

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-09-26 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15319:
--

[~jmeredithco] the CircleCI links you've posted above 404. Could you please 
update the links? 

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15329) in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader

2019-09-25 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15329:
-
Reviewers: Alex Petrov, Jon Meredith  (was: Alex Petrov)

> in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader
> --
>
> Key: CASSANDRA-15329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15329
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Attachments: CASSANDRA-15329.patch
>
>
> When running the in-JVM dtests on on java 11 they fail while trying to cast 
> the Versions.class.getClassLoader to URLClassLoader, which is no longer the 
> default ClassLoader on java 11.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15329) in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader

2019-09-25 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15329:
-
Reviewers: Alex Petrov

> in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader
> --
>
> Key: CASSANDRA-15329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15329
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Attachments: CASSANDRA-15329.patch
>
>
> When running the in-JVM dtests on on java 11 they fail while trying to cast 
> the Versions.class.getClassLoader to URLClassLoader, which is no longer the 
> default ClassLoader on java 11.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting

2019-09-24 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15296:
-
  Fix Version/s: 4.0-alpha
  Since Version: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/a7f89688e5b4fdc2f8990fc42cb593da4f6a923f
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed. Thanks for the report [~dvohra] and patch [~rha].

> ZstdCompressor compression_level setting
> 
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Fix For: 4.0-alpha
>
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range 
> for compression_level is indicated to be between -131072 and 2.  The default 
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting

2019-09-24 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15296:
-
Reviewers: Dinesh Joshi, Dinesh Joshi  (was: Dinesh Joshi)
   Dinesh Joshi, Dinesh Joshi  (was: Dinesh Joshi)
   Status: Review In Progress  (was: Patch Available)

+1 LGTM

> ZstdCompressor compression_level setting
> 
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range 
> for compression_level is indicated to be between -131072 and 2.  The default 
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting

2019-09-24 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15296:
-
Status: Ready to Commit  (was: Review In Progress)

> ZstdCompressor compression_level setting
> 
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range 
> for compression_level is indicated to be between -131072 and 2.  The default 
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta

2019-09-24 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15299:
-
Description: 
CASSANDRA-13304 made an important improvement to our native protocol: it 
introduced checksumming/CRC32 to request and response bodies. It’s an important 
step forward, but it doesn’t cover the entire stream. In particular, the 
message header is not covered by a checksum or a crc, which poses a correctness 
issue if, for example, {{streamId}} gets corrupted.

Additionally, we aren’t quite using CRC32 correctly, in two ways:
1. We are calculating the CRC32 of the *decompressed* value instead of 
computing the CRC32 on the bytes written on the wire - losing the properties of 
the CRC32. In some cases, due to this sequencing, attempting to decompress a 
corrupt stream can cause a segfault by LZ4.
2. When using CRC32, the CRC32 value is written in the incorrect byte order, 
also losing some of the protections.

See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for 
explanation for the two points above.

Separately, there are some long-standing issues with the protocol - since *way* 
before CASSANDRA-13304. Importantly, both checksumming and compression operate 
on individual message bodies rather than frames of multiple complete messages. 
In reality, this has several important additional downsides. To name a couple:
# For compression, we are getting poor compression ratios for smaller messages 
- when operating on tiny sequences of bytes. In reality, for most small 
requests and responses we are discarding the compressed value as it’d be 
smaller than the uncompressed one - incurring both redundant allocations and 
compressions.
# For checksumming and CRC32 we pay a high overhead price for small messages. 4 
bytes extra is *a lot* for an empty write response, for example.

To address the correctness issue of {{streamId}} not being covered by the 
checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we 
should switch to a framing protocol with multiple messages in a single frame.

I suggest we reuse the framing protocol recently implemented for internode 
messaging in CASSANDRA-15066 to the extent that its logic can be borrowed, and 
that we do it before native protocol v5 graduates from beta. See 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
 and 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.

  was:
CASSANDRA-13304 made an important improvement to our native protocol: it 
introduced checksumming/CRC32 to request and response bodies. It’s an important 
step forward, but it doesn’t cover the entire stream. In parcicular, the 
message header is not covered by a checksum or a crc, which poses a correctness 
issue if, for example, {{streamId}} gets corrupted.

Additionally, we aren’t quite using CRC32 correctly, in two ways:
1. We are calculating the CRC32 of the *decompressed* value instead of 
computing the CRC32 on the bytes written on the wire - losing the properties of 
the CRC32. In some cases, due to this sequencing, attempting to decompress a 
corrupt stream can cause a segfault by LZ4.
2. When using CRC32, the CRC32 value is written in the incorrect byte order, 
also losing some of the protections.

See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for 
explanation for the two points above.

Separately, there are some long-standing issues with the protocol - since *way* 
before CASSANDRA-13304. Importantly, both checksumming and compression operate 
on individual message bodies rather than frames of multiple complete messages. 
In reality, this has several important additional downsides. To name a couple:
# For compression, we are getting poor compression ratios for smaller messages 
- when operating on tiny sequences of bytes. In reality, for most small 
requests and responses we are discarding the compressed value as it’d be 
smaller than the uncompressed one - incurring both redundant allocations and 
compressions.
# For checksumming and CRC32 we pay a high overhead price for small messages. 4 
bytes extra is *a lot* for an empty write response, for example.

To address the correctness issue of {{streamId}} not being covered by the 
checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we 
should switch to a framing protocol with multiple messages in a single frame.

I suggest we reuse the framing protocol recently implemented for internode 
messaging in CASSANDRA-15066 to the extent that its logic can be borrowed, and 
that we do it before native protocol v5 graduates from beta. See 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
 and 

[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-09-23 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15319:
-
Reviewers: Dinesh Joshi, Dinesh Joshi  (was: Dinesh Joshi)
   Dinesh Joshi, Dinesh Joshi  (was: Dinesh Joshi)
   Status: Review In Progress  (was: Patch Available)

Hi [~jmeredithco], overall the code looks good. There were some minor changes 
that I have mocked up in my branch. The diff is 
[here|https://github.com/jonmeredith/cassandra/compare/CASSANDRA-15319-trunk...dineshjoshi:CASSANDRA-15319-trunk-review?expand=1].
 

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-09-23 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15319:
-
Reviewers: Dinesh Joshi

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (CASSANDRA-13938) Default repair is broken, crashes other nodes participating in repair (in trunk)

2019-09-17 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-13938:
--

Yes

> Default repair is broken, crashes other nodes participating in repair (in 
> trunk)
> 
>
> Key: CASSANDRA-13938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13938
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Nate McCall
>Assignee: Joseph Lynch
>Priority: Urgent
> Fix For: 4.0-alpha
>
> Attachments: 13938.yaml, test.sh
>
>
> Running through a simple scenario to test some of the new repair features, I 
> was not able to make a repair command work. Further, the exception seemed to 
> trigger a nasty failure state that basically shuts down the netty connections 
> for messaging *and* CQL on the nodes transferring back data to the node being 
> repaired. The following steps reproduce this issue consistently.
> Cassandra stress profile (probably not necessary, but this one provides a 
> really simple schema and consistent data shape):
> {noformat}
> keyspace: standard_long
> keyspace_definition: |
>   CREATE KEYSPACE standard_long WITH replication = {'class':'SimpleStrategy', 
> 'replication_factor':3};
> table: test_data
> table_definition: |
>   CREATE TABLE test_data (
>   key text,
>   ts bigint,
>   val text,
>   PRIMARY KEY (key, ts)
>   ) WITH COMPACT STORAGE AND
>   CLUSTERING ORDER BY (ts DESC) AND
>   bloom_filter_fp_chance=0.01 AND
>   caching={'keys':'ALL', 'rows_per_partition':'NONE'} AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.00 AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> columnspec:
>   - name: key
> population: uniform(1..5000) # 50 million records available
>   - name: ts
> cluster: gaussian(1..50) # Up to 50 inserts per record
>   - name: val
> population: gaussian(128..1024) # varrying size of value data
> insert:
>   partitions: fixed(1) # only one insert per batch for individual partitions
>   select: fixed(1)/1 # each insert comes in one at a time
>   batchtype: UNLOGGED
> queries:
>   single:
> cql: select * from test_data where key = ? and ts = ? limit 1;
>   series:
> cql: select key,ts,val from test_data where key = ? limit 10;
> {noformat}
> The commands to build and run:
> {noformat}
> ccm create 4_0_test -v git:trunk -n 3 -s
> ccm stress user profile=./histo-test-schema.yml 
> ops\(insert=20,single=1,series=1\) duration=15s -rate threads=4
> # flush the memtable just to get everything on disk
> ccm node1 nodetool flush
> ccm node2 nodetool flush
> ccm node3 nodetool flush
> # disable hints for nodes 2 and 3
> ccm node2 nodetool disablehandoff
> ccm node3 nodetool disablehandoff
> # stop node1
> ccm node1 stop
> ccm stress user profile=./histo-test-schema.yml 
> ops\(insert=20,single=1,series=1\) duration=45s -rate threads=4
> # wait 10 seconds
> ccm node1 start
> # Note that we are local to ccm's nodetool install 'cause repair preview is 
> not reported yet
> node1/bin/nodetool repair --preview
> node1/bin/nodetool repair standard_long test_data
> {noformat} 
> The error outputs from the last repair command follow. First, this is stdout 
> from node1:
> {noformat}
> $ node1/bin/nodetool repair standard_long test_data
> objc[47876]: Class JavaLaunchHelper is implemented in both 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/java 
> (0x10274d4c0) and 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib
>  (0x1047b64e0). One of the two will be used. Which one is undefined.
> [2017-10-05 14:31:52,425] Starting repair command #4 
> (7e1a9150-a98e-11e7-ad86-cbd2801b8de2), repairing keyspace standard_long with 
> repair options (parallelism: parallel, primary range: false, incremental: 
> true, job threads: 1, ColumnFamilies: [test_data], dataCenters: [], hosts: 
> [], previewKind: NONE, # of ranges: 3, pull repair: false, force repair: 
> false)
> [2017-10-05 14:32:07,045] Repair session 7e2e8e80-a98e-11e7-ad86-cbd2801b8de2 
> for range [(3074457345618258602,-9223372036854775808], 
> (-9223372036854775808,-3074457345618258603], 
> (-3074457345618258603,3074457345618258602]] failed with error Stream failed
> [2017-10-05 14:32:07,048] null
> [2017-10-05 14:32:07,050] Repair command #4 finished in 14 seconds
> error: Repair job has failed with the error message: [2017-10-05 
> 14:32:07,048] null
> -- StackTrace --
> java.lang.RuntimeException: Repair job has failed with the error message: 
> [2017-10-05 14:32:07,048] null
> at 

[jira] [Comment Edited] (CASSANDRA-15324) Unable to compute ceiling for max when histogram

2019-09-12 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi edited comment on CASSANDRA-15324 at 9/12/19 7:49 AM:
---

Your issue is likely related to your data model. Its better to discuss it on 
the [user mailing list|http://cassandra.apache.org/community/]. It would also 
be helpful to include information about your data model and any other relevant 
information to help debug the issue and point you in the right direction.


was (Author: djoshi3):
Your issue is likely related to your data model. Its better to discuss it on 
the [user mailing list|http://cassandra.apache.org/community/].

> Unable to compute ceiling for max when histogram
> 
>
> Key: CASSANDRA-15324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15324
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Local/Compaction/STCS
>Reporter: HsuML
>Priority: Normal
>
> I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the 
> record count of all table are about 8.2 billion. I imported data through my 
> java loaders, and I found out the system.log has error message. What happened 
> and how can I solve the error?
> Exception in thread Thread[CompactionExecutor:113041,1,main] 
> java.lang.IllegalStateException: Unable to compute ceiling for max when 
> histogram overflowed
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram.java:220)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata.getEstimatedDroppableTombstoneRatio(StatsMetadata.java:115)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getEstimatedDroppableTombstoneRatio(SSTableReader.java:1926)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:424)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:99)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:183)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:153)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:260)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_191]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [na:1.8.0_191]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.4.jar:3.11.4]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15324) Unable to compute ceiling for max when histogram

2019-09-12 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15324:
-
Resolution: Invalid
Status: Resolved  (was: Awaiting Feedback)

> Unable to compute ceiling for max when histogram
> 
>
> Key: CASSANDRA-15324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15324
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Local/Compaction/STCS
>Reporter: HsuML
>Priority: Normal
>
> I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the 
> record count of all table are about 8.2 billion. I imported data through my 
> java loaders, and I found out the system.log has error message. What happened 
> and how can I solve the error?
> Exception in thread Thread[CompactionExecutor:113041,1,main] 
> java.lang.IllegalStateException: Unable to compute ceiling for max when 
> histogram overflowed
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram.java:220)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata.getEstimatedDroppableTombstoneRatio(StatsMetadata.java:115)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getEstimatedDroppableTombstoneRatio(SSTableReader.java:1926)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:424)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:99)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:183)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:153)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:260)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_191]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [na:1.8.0_191]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.4.jar:3.11.4]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Commented] (CASSANDRA-15324) Unable to compute ceiling for max when histogram

2019-09-12 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15324:
--

Your issue is likely related to your data model. Its better to discuss it on 
the [user mailing list|http://cassandra.apache.org/community/].

> Unable to compute ceiling for max when histogram
> 
>
> Key: CASSANDRA-15324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15324
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Local/Compaction/STCS
>Reporter: HsuML
>Priority: Normal
>
> I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the 
> record count of all table are about 8.2 billion. I imported data through my 
> java loaders, and I found out the system.log has error message. What happened 
> and how can I solve the error?
> Exception in thread Thread[CompactionExecutor:113041,1,main] 
> java.lang.IllegalStateException: Unable to compute ceiling for max when 
> histogram overflowed
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram.java:220)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata.getEstimatedDroppableTombstoneRatio(StatsMetadata.java:115)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getEstimatedDroppableTombstoneRatio(SSTableReader.java:1926)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:424)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:99)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:183)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:153)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:260)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_191]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [na:1.8.0_191]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.4.jar:3.11.4]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Commented] (CASSANDRA-15324) Unable to compute ceiling for max when histogram

2019-09-12 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15324:
--

Have you seen CASSANDRA-11063?

> Unable to compute ceiling for max when histogram
> 
>
> Key: CASSANDRA-15324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15324
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Local/Compaction/STCS
>Reporter: HsuML
>Priority: Normal
>
> I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the 
> record count of all table are about 8.2 billion. I imported data through my 
> java loaders, and I found out the system.log has error message. What happened 
> and how can I solve the error?
> Exception in thread Thread[CompactionExecutor:113041,1,main] 
> java.lang.IllegalStateException: Unable to compute ceiling for max when 
> histogram overflowed
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram.java:220)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata.getEstimatedDroppableTombstoneRatio(StatsMetadata.java:115)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getEstimatedDroppableTombstoneRatio(SSTableReader.java:1926)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:424)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:99)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:183)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:153)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:260)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_191]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [na:1.8.0_191]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.4.jar:3.11.4]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15324) Unable to compute ceiling for max when histogram

2019-09-12 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15324:
-
Status: Awaiting Feedback  (was: Triage Needed)

> Unable to compute ceiling for max when histogram
> 
>
> Key: CASSANDRA-15324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15324
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Local/Compaction/STCS
>Reporter: HsuML
>Priority: Normal
>
> I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the 
> record count of all table are about 8.2 billion. I imported data through my 
> java loaders, and I found out the system.log has error message. What happened 
> and how can I solve the error?
> Exception in thread Thread[CompactionExecutor:113041,1,main] 
> java.lang.IllegalStateException: Unable to compute ceiling for max when 
> histogram overflowed
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram.java:220)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata.getEstimatedDroppableTombstoneRatio(StatsMetadata.java:115)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getEstimatedDroppableTombstoneRatio(SSTableReader.java:1926)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:424)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:99)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:183)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:153)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:260)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_191]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [na:1.8.0_191]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.4.jar:3.11.4]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15324) Unable to compute ceiling for max when histogram

2019-09-12 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15324:
-
Component/s: (was: Documentation/Blog)
 Local/Compaction/STCS
 Local/Compaction

> Unable to compute ceiling for max when histogram
> 
>
> Key: CASSANDRA-15324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15324
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Local/Compaction/STCS
>Reporter: HsuML
>Priority: Normal
>
> I have 9 cassandra nodes. When I create a keyspace that has 15 tables and the 
> record count of all table are about 8.2 billion. I imported data through my 
> java loaders, and I found out the system.log has error message. What happened 
> and how can I solve the error?
> Exception in thread Thread[CompactionExecutor:113041,1,main] 
> java.lang.IllegalStateException: Unable to compute ceiling for max when 
> histogram overflowed
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram.java:220)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.metadata.StatsMetadata.getEstimatedDroppableTombstoneRatio(StatsMetadata.java:115)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.getEstimatedDroppableTombstoneRatio(SSTableReader.java:1926)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.worthDroppingTombstones(AbstractCompactionStrategy.java:424)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:99)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:183)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:153)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:260)
>  ~[apache-cassandra-3.11.4.jar:3.11.4]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_191]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[na:1.8.0_191]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [na:1.8.0_191]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.4.jar:3.11.4]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-09-09 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15319:
-
Test and Documentation Plan: This adds additional features to In-JVM tests 
framework.
 Status: Patch Available  (was: Open)

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-09-09 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15319:
-
Change Category: Semantic
 Complexity: Normal
 Status: Open  (was: Triage Needed)

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Assigned] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.

2019-09-09 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi reassigned CASSANDRA-15319:


Assignee: Jon Meredith

> Add support for network topology and tracing to in-JVM dtests.
> --
>
> Key: CASSANDRA-15319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15319
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> While working on CASSANDRA-15318, testing it properly with an in-JVM test 
> requires setting up the network topology and tracing requests to check which 
> nodes performed forwarding.
>   
> In support of testing, make it possible to create in-JVM clusters with nodes 
> appearing in different datacenter/racks and add support for executing queries 
> with tracing enabled.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15318) sendMessagesToNonlocalDC() should shuffle targets

2019-09-09 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15318:
-
Change Category: Quality Assurance
 Complexity: Normal
 Status: Open  (was: Triage Needed)

> sendMessagesToNonlocalDC() should shuffle targets
> -
>
> Key: CASSANDRA-15318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> To better spread load and reduce the impact of a node failure before 
> detection (or other issues like issues host replacement), when forwarding 
> messages to other data centers the forwarding non-local dc nodes should be 
> selected at random rather than always selecting the first node in the list of 
> endpoints for a token.
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15318) sendMessagesToNonlocalDC() should shuffle targets

2019-09-09 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15318:
-
Test and Documentation Plan: Jon's added tests.
 Status: Patch Available  (was: Open)

> sendMessagesToNonlocalDC() should shuffle targets
> -
>
> Key: CASSANDRA-15318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> To better spread load and reduce the impact of a node failure before 
> detection (or other issues like issues host replacement), when forwarding 
> messages to other data centers the forwarding non-local dc nodes should be 
> selected at random rather than always selecting the first node in the list of 
> endpoints for a token.
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15318) sendMessagesToNonlocalDC() should shuffle targets

2019-09-09 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15318:
-
Reviewers: Dinesh Joshi

> sendMessagesToNonlocalDC() should shuffle targets
> -
>
> Key: CASSANDRA-15318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> To better spread load and reduce the impact of a node failure before 
> detection (or other issues like issues host replacement), when forwarding 
> messages to other data centers the forwarding non-local dc nodes should be 
> selected at random rather than always selecting the first node in the list of 
> endpoints for a token.
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting

2019-09-02 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15296:
-
Bug Category: Parent values: Code(13163)
  Status: Open  (was: Triage Needed)

> ZstdCompressor compression_level setting
> 
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range 
> for compression_level is indicated to be between -131072 and 2.  The default 
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting

2019-09-02 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15296:
-
Test and Documentation Plan: This is a documentation bug.
 Status: Patch Available  (was: Open)

> ZstdCompressor compression_level setting
> 
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range 
> for compression_level is indicated to be between -131072 and 2.  The default 
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting

2019-09-02 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15296:
-
   Complexity: Low Hanging Fruit
Discovered By: User Report
Reviewers: Dinesh Joshi
 Severity: Low
  Description: 
The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range for 
compression_level is indicated to be between -131072 and 2.  The default value 
is outside the range. Is it by design or a bug?

{code:java}

- ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
values between ``-131072`` and ``2``.

// Compressor Defaults
public static final int DEFAULT_COMPRESSION_LEVEL = 3;

{code}

https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9

  was:

The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range for 
compression_level is indicated to be between -131072 and 2.  The default value 
is outside the range. Is it by design or a bug?

{code:java}

- ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
values between ``-131072`` and ``2``.

// Compressor Defaults
public static final int DEFAULT_COMPRESSION_LEVEL = 3;

{code}

https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9


> ZstdCompressor compression_level setting
> 
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range 
> for compression_level is indicated to be between -131072 and 2.  The default 
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Commented] (CASSANDRA-15296) ZstdCompressor compression_level setting

2019-09-02 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15296:
--

Hi [~rha] and [~dvohra]. Thanks for reporting this issue. It looks like this 
might be a typo in the documentation.

> ZstdCompressor compression_level setting
> 
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Normal
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range 
> for compression_level is indicated to be between -131072 and 2.  The default 
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts 
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Commented] (CASSANDRA-13938) Default repair is broken, crashes other nodes participating in repair (in trunk)

2019-08-29 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-13938:
--

[~jolynch] I have assigned this to you. Thanks for volunteering :)

> Default repair is broken, crashes other nodes participating in repair (in 
> trunk)
> 
>
> Key: CASSANDRA-13938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13938
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Nate McCall
>Assignee: Joseph Lynch
>Priority: Urgent
> Fix For: 4.0-alpha
>
> Attachments: 13938.yaml, test.sh
>
>
> Running through a simple scenario to test some of the new repair features, I 
> was not able to make a repair command work. Further, the exception seemed to 
> trigger a nasty failure state that basically shuts down the netty connections 
> for messaging *and* CQL on the nodes transferring back data to the node being 
> repaired. The following steps reproduce this issue consistently.
> Cassandra stress profile (probably not necessary, but this one provides a 
> really simple schema and consistent data shape):
> {noformat}
> keyspace: standard_long
> keyspace_definition: |
>   CREATE KEYSPACE standard_long WITH replication = {'class':'SimpleStrategy', 
> 'replication_factor':3};
> table: test_data
> table_definition: |
>   CREATE TABLE test_data (
>   key text,
>   ts bigint,
>   val text,
>   PRIMARY KEY (key, ts)
>   ) WITH COMPACT STORAGE AND
>   CLUSTERING ORDER BY (ts DESC) AND
>   bloom_filter_fp_chance=0.01 AND
>   caching={'keys':'ALL', 'rows_per_partition':'NONE'} AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.00 AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> columnspec:
>   - name: key
> population: uniform(1..5000) # 50 million records available
>   - name: ts
> cluster: gaussian(1..50) # Up to 50 inserts per record
>   - name: val
> population: gaussian(128..1024) # varrying size of value data
> insert:
>   partitions: fixed(1) # only one insert per batch for individual partitions
>   select: fixed(1)/1 # each insert comes in one at a time
>   batchtype: UNLOGGED
> queries:
>   single:
> cql: select * from test_data where key = ? and ts = ? limit 1;
>   series:
> cql: select key,ts,val from test_data where key = ? limit 10;
> {noformat}
> The commands to build and run:
> {noformat}
> ccm create 4_0_test -v git:trunk -n 3 -s
> ccm stress user profile=./histo-test-schema.yml 
> ops\(insert=20,single=1,series=1\) duration=15s -rate threads=4
> # flush the memtable just to get everything on disk
> ccm node1 nodetool flush
> ccm node2 nodetool flush
> ccm node3 nodetool flush
> # disable hints for nodes 2 and 3
> ccm node2 nodetool disablehandoff
> ccm node3 nodetool disablehandoff
> # stop node1
> ccm node1 stop
> ccm stress user profile=./histo-test-schema.yml 
> ops\(insert=20,single=1,series=1\) duration=45s -rate threads=4
> # wait 10 seconds
> ccm node1 start
> # Note that we are local to ccm's nodetool install 'cause repair preview is 
> not reported yet
> node1/bin/nodetool repair --preview
> node1/bin/nodetool repair standard_long test_data
> {noformat} 
> The error outputs from the last repair command follow. First, this is stdout 
> from node1:
> {noformat}
> $ node1/bin/nodetool repair standard_long test_data
> objc[47876]: Class JavaLaunchHelper is implemented in both 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/java 
> (0x10274d4c0) and 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib
>  (0x1047b64e0). One of the two will be used. Which one is undefined.
> [2017-10-05 14:31:52,425] Starting repair command #4 
> (7e1a9150-a98e-11e7-ad86-cbd2801b8de2), repairing keyspace standard_long with 
> repair options (parallelism: parallel, primary range: false, incremental: 
> true, job threads: 1, ColumnFamilies: [test_data], dataCenters: [], hosts: 
> [], previewKind: NONE, # of ranges: 3, pull repair: false, force repair: 
> false)
> [2017-10-05 14:32:07,045] Repair session 7e2e8e80-a98e-11e7-ad86-cbd2801b8de2 
> for range [(3074457345618258602,-9223372036854775808], 
> (-9223372036854775808,-3074457345618258603], 
> (-3074457345618258603,3074457345618258602]] failed with error Stream failed
> [2017-10-05 14:32:07,048] null
> [2017-10-05 14:32:07,050] Repair command #4 finished in 14 seconds
> error: Repair job has failed with the error message: [2017-10-05 
> 14:32:07,048] null
> -- StackTrace --
> java.lang.RuntimeException: Repair job has failed with the 

[jira] [Assigned] (CASSANDRA-13938) Default repair is broken, crashes other nodes participating in repair (in trunk)

2019-08-29 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi reassigned CASSANDRA-13938:


Assignee: Joseph Lynch  (was: Jason Brown)

> Default repair is broken, crashes other nodes participating in repair (in 
> trunk)
> 
>
> Key: CASSANDRA-13938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13938
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Nate McCall
>Assignee: Joseph Lynch
>Priority: Urgent
> Fix For: 4.0-alpha
>
> Attachments: 13938.yaml, test.sh
>
>
> Running through a simple scenario to test some of the new repair features, I 
> was not able to make a repair command work. Further, the exception seemed to 
> trigger a nasty failure state that basically shuts down the netty connections 
> for messaging *and* CQL on the nodes transferring back data to the node being 
> repaired. The following steps reproduce this issue consistently.
> Cassandra stress profile (probably not necessary, but this one provides a 
> really simple schema and consistent data shape):
> {noformat}
> keyspace: standard_long
> keyspace_definition: |
>   CREATE KEYSPACE standard_long WITH replication = {'class':'SimpleStrategy', 
> 'replication_factor':3};
> table: test_data
> table_definition: |
>   CREATE TABLE test_data (
>   key text,
>   ts bigint,
>   val text,
>   PRIMARY KEY (key, ts)
>   ) WITH COMPACT STORAGE AND
>   CLUSTERING ORDER BY (ts DESC) AND
>   bloom_filter_fp_chance=0.01 AND
>   caching={'keys':'ALL', 'rows_per_partition':'NONE'} AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.00 AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> columnspec:
>   - name: key
> population: uniform(1..5000) # 50 million records available
>   - name: ts
> cluster: gaussian(1..50) # Up to 50 inserts per record
>   - name: val
> population: gaussian(128..1024) # varrying size of value data
> insert:
>   partitions: fixed(1) # only one insert per batch for individual partitions
>   select: fixed(1)/1 # each insert comes in one at a time
>   batchtype: UNLOGGED
> queries:
>   single:
> cql: select * from test_data where key = ? and ts = ? limit 1;
>   series:
> cql: select key,ts,val from test_data where key = ? limit 10;
> {noformat}
> The commands to build and run:
> {noformat}
> ccm create 4_0_test -v git:trunk -n 3 -s
> ccm stress user profile=./histo-test-schema.yml 
> ops\(insert=20,single=1,series=1\) duration=15s -rate threads=4
> # flush the memtable just to get everything on disk
> ccm node1 nodetool flush
> ccm node2 nodetool flush
> ccm node3 nodetool flush
> # disable hints for nodes 2 and 3
> ccm node2 nodetool disablehandoff
> ccm node3 nodetool disablehandoff
> # stop node1
> ccm node1 stop
> ccm stress user profile=./histo-test-schema.yml 
> ops\(insert=20,single=1,series=1\) duration=45s -rate threads=4
> # wait 10 seconds
> ccm node1 start
> # Note that we are local to ccm's nodetool install 'cause repair preview is 
> not reported yet
> node1/bin/nodetool repair --preview
> node1/bin/nodetool repair standard_long test_data
> {noformat} 
> The error outputs from the last repair command follow. First, this is stdout 
> from node1:
> {noformat}
> $ node1/bin/nodetool repair standard_long test_data
> objc[47876]: Class JavaLaunchHelper is implemented in both 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/java 
> (0x10274d4c0) and 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib
>  (0x1047b64e0). One of the two will be used. Which one is undefined.
> [2017-10-05 14:31:52,425] Starting repair command #4 
> (7e1a9150-a98e-11e7-ad86-cbd2801b8de2), repairing keyspace standard_long with 
> repair options (parallelism: parallel, primary range: false, incremental: 
> true, job threads: 1, ColumnFamilies: [test_data], dataCenters: [], hosts: 
> [], previewKind: NONE, # of ranges: 3, pull repair: false, force repair: 
> false)
> [2017-10-05 14:32:07,045] Repair session 7e2e8e80-a98e-11e7-ad86-cbd2801b8de2 
> for range [(3074457345618258602,-9223372036854775808], 
> (-9223372036854775808,-3074457345618258603], 
> (-3074457345618258603,3074457345618258602]] failed with error Stream failed
> [2017-10-05 14:32:07,048] null
> [2017-10-05 14:32:07,050] Repair command #4 finished in 14 seconds
> error: Repair job has failed with the error message: [2017-10-05 
> 14:32:07,048] null
> -- StackTrace --
> java.lang.RuntimeException: Repair job has failed with the error message: 
> [2017-10-05 14:32:07,048] null
> at 

[jira] [Updated] (CASSANDRA-15294) Allow easy use of custom security providers

2019-08-29 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15294:
-
Status: Awaiting Feedback  (was: Triage Needed)

> Allow easy use of custom security providers
> ---
>
> Key: CASSANDRA-15294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15294
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Joseph Lynch
>Priority: Normal
>
> As more users are switching to using {{AES-GCM}} TLS they are increasingly 
> running into extremely poor performance with the JDK implementations (e.g. 
> [JDK-8046943|https://bugs.openjdk.java.net/browse/JDK-8046943]). It's not 
> just TLS either, generally speaking Java crypto can be really slow, including 
> for example MD5 hashing which powers our digests (CASSANDRA-14611).
> There have been a few community attempts to fix this via customer java 
> security providers, for example Google's 
> [conscrypt|https://github.com/google/conscrypt] and recently Amazon's 
> [ACCP|https://github.com/corretto/amazon-corretto-crypto-provider] which are 
> basically portions of OpenSSL/BoringSSL that are statically linked in and 
> exposed via JNI. These approaches are similar in spirit to what 
> [netty-tcnative|https://github.com/netty/netty-tcnative] is doing for TLS in 
> C* trunk.
> Since there may be tradeoffs to using various providers for various functions 
> (e.g. {{conscrypt}} may be faster or slower than {{accp}} in certain use 
> cases and in other cases you may want to use JDK providers for ease of 
> upgrading) it would be useful if Cassandra supported pluggable providers per 
> use case. For example we could use {{conscrypt}} for TLS, {{accp}} for MD5 
> digesting, and the {{SUN}} provider for everything else. There is a small 
> amount of JVM wiring that needs to be done for this and it could unlock 
> 10-25% CPU capacity improvements.
> We can then use this pluggability to test different providers and if one is 
> strictly dominant we can just check that one in in libs and default to it.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Commented] (CASSANDRA-15294) Allow easy use of custom security providers

2019-08-29 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15294:
--

[~jolynch], given the advantages, I think this is worth adding. Do you want to 
propose a patch?

> Allow easy use of custom security providers
> ---
>
> Key: CASSANDRA-15294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15294
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Joseph Lynch
>Priority: Normal
>
> As more users are switching to using {{AES-GCM}} TLS they are increasingly 
> running into extremely poor performance with the JDK implementations (e.g. 
> [JDK-8046943|https://bugs.openjdk.java.net/browse/JDK-8046943]). It's not 
> just TLS either, generally speaking Java crypto can be really slow, including 
> for example MD5 hashing which powers our digests (CASSANDRA-14611).
> There have been a few community attempts to fix this via customer java 
> security providers, for example Google's 
> [conscrypt|https://github.com/google/conscrypt] and recently Amazon's 
> [ACCP|https://github.com/corretto/amazon-corretto-crypto-provider] which are 
> basically portions of OpenSSL/BoringSSL that are statically linked in and 
> exposed via JNI. These approaches are similar in spirit to what 
> [netty-tcnative|https://github.com/netty/netty-tcnative] is doing for TLS in 
> C* trunk.
> Since there may be tradeoffs to using various providers for various functions 
> (e.g. {{conscrypt}} may be faster or slower than {{accp}} in certain use 
> cases and in other cases you may want to use JDK providers for ease of 
> upgrading) it would be useful if Cassandra supported pluggable providers per 
> use case. For example we could use {{conscrypt}} for TLS, {{accp}} for MD5 
> digesting, and the {{SUN}} provider for everything else. There is a small 
> amount of JVM wiring that needs to be done for this and it could unlock 
> 10-25% CPU capacity improvements.
> We can then use this pluggability to test different providers and if one is 
> strictly dominant we can just check that one in in libs and default to it.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15288) Read sidecar.yaml from sidecar.config System Property instead of classpath

2019-08-23 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15288:
-
  Fix Version/s: 4.x
Source Control Link: 
https://github.com/apache/cassandra-sidecar/commit/14485bd7ad649d9417b4320eab34631251545d0b
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed. Thanks for the patch [~andrew.tolbert]. Thanks [~vinaykumarcse] for 
the review.

> Read sidecar.yaml from sidecar.config System Property instead of classpath
> --
>
> Key: CASSANDRA-15288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15288
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Sidecar
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
>  Labels: pull-request-available
> Fix For: 4.x
>
>
> I was experimenting earlier with running multiple sidecar instances against 
> multiple local C* nodes (using a ccm cluster) and noticed that the 
> distribution of sidecar did not include the conf directory and instead was 
> loading sidecar.yaml from the classpath. I noticed the lines in build.gradle:
> {code:java}
> // Config file location should be in file:/// format for local files,
> // when we have the fix for adding /conf directory to classpaht, we can get 
> away with below default JvmArg
> {code}
> From this statement I assume the expectation was that eventually the 
> sidecar.config system property would be used to locate the sidecar.yaml file.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-23 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15272:
-
  Fix Version/s: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/3a4e00615b14275e5dac535a304add9e1cf4e4eb
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
> Fix For: 4.0
>
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Commented] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-23 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15272:
--

[~jmeredithco], committed. Thanks for the review.

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
> Fix For: 4.0
>
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15288) Read sidecar.yaml from sidecar.config System Property instead of classpath

2019-08-23 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15288:
-
Status: Ready to Commit  (was: Review In Progress)

+1

> Read sidecar.yaml from sidecar.config System Property instead of classpath
> --
>
> Key: CASSANDRA-15288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15288
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Sidecar
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
>  Labels: pull-request-available
>
> I was experimenting earlier with running multiple sidecar instances against 
> multiple local C* nodes (using a ccm cluster) and noticed that the 
> distribution of sidecar did not include the conf directory and instead was 
> loading sidecar.yaml from the classpath. I noticed the lines in build.gradle:
> {code:java}
> // Config file location should be in file:/// format for local files,
> // when we have the fix for adding /conf directory to classpaht, we can get 
> away with below default JvmArg
> {code}
> From this statement I assume the expectation was that eventually the 
> sidecar.config system property would be used to locate the sidecar.yaml file.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Commented] (CASSANDRA-15124) Virtual tables API endpoints for sidecar

2019-08-22 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi commented on CASSANDRA-15124:
--

Hi [~cnlwsu]. thanks for the patch. I have left some feedback for you on the 
PR. 

> Virtual tables API endpoints for sidecar
> 
>
> Key: CASSANDRA-15124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15124
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Sidecar
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Expose the existing virtual tables in sidecar api



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15124) Virtual tables API endpoints for sidecar

2019-08-22 Thread Dinesh Joshi (Jira)


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

Dinesh Joshi updated CASSANDRA-15124:
-
Reviewers: Andy Tolbert, Dinesh Joshi, Vinay Chella, Dinesh Joshi  (was: 
Andy Tolbert, Dinesh Joshi, Vinay Chella)
   Andy Tolbert, Dinesh Joshi, Vinay Chella, Dinesh Joshi  (was: 
Andy Tolbert, Dinesh Joshi, Vinay Chella)
   Status: Review In Progress  (was: Patch Available)

> Virtual tables API endpoints for sidecar
> 
>
> Key: CASSANDRA-15124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15124
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Sidecar
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Expose the existing virtual tables in sidecar api



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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



[jira] [Updated] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-13 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15272:
-
Reviewers: Jon Meredith  (was: Dinesh Joshi, Jon Meredith)

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-13 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15272:
-
Status: Ready to Commit  (was: Review In Progress)

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-13 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15272:
-
Reviewers: Jon Meredith, Dinesh Joshi  (was: Dinesh Joshi, Jon Meredith)
   Status: Review In Progress  (was: Patch Available)
Reviewers: Jon Meredith, Dinesh Joshi  (was: Jon Meredith)

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-13 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15272:
--

Thanks for the review [~jmeredithco]. I have updated the branch with your 
review feedback. Please take a look.

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-13 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15272:
-
Reviewers: Jon Meredith

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Comment Edited] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-12 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-15272 at 8/12/19 5:24 PM:
---

Patch: 
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:15272-trunk?expand=1
CircleCI Test Run: 
https://circleci.com/workflow-run/03f4cd80-e5b9-481e-8620-943de5d72707


was (Author: djoshi3):
Patch: 
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:15272-trunk?expand=1
CircleCI Test Run: 
https://circleci.com/workflow-run/dcb04e6a-5f3f-4528-8f00-ec85324e63d0

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Comment Edited] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-11 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-15272 at 8/11/19 5:48 PM:
---

Patch: 
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:15272-trunk?expand=1
CircleCI Test Run: 
https://circleci.com/workflow-run/dcb04e6a-5f3f-4528-8f00-ec85324e63d0


was (Author: djoshi3):
Patch: 
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:15272-trunk?expand=1

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-11 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15272:
-
Test and Documentation Plan: This re-enables couple InJVM tests.
 Status: Patch Available  (was: Open)

Patch: 
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:15272-trunk?expand=1

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-11 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15272:
-
 Complexity: Low Hanging Fruit
Change Category: Quality Assurance
 Status: Open  (was: Triage Needed)

> Enhance & reenable RepairTest
> -
>
> Key: CASSANDRA-15272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
>
> Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
> CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new 
> test that tests the compression=off path for SSTables. It will help catch any 
> regressions in repair on this path. This does not fix the issue with the 
> compressed sstable streaming (CASSANDRA-13938). That should be addressed in 
> the original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Created] (CASSANDRA-15272) Enhance & reenable RepairTest

2019-08-11 Thread Dinesh Joshi (JIRA)
Dinesh Joshi created CASSANDRA-15272:


 Summary: Enhance & reenable RepairTest
 Key: CASSANDRA-15272
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15272
 Project: Cassandra
  Issue Type: Improvement
  Components: Consistency/Repair
Reporter: Dinesh Joshi
Assignee: Dinesh Joshi


Currently the In-JVM RepairTest is not enabled on trunk (See for more info: 
CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new test 
that tests the compression=off path for SSTables. It will help catch any 
regressions in repair on this path. This does not fix the issue with the 
compressed sstable streaming (CASSANDRA-13938). That should be addressed in the 
original ticket.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (CASSANDRA-15214) OOMs caught and not rethrown

2019-08-05 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15214:
--

Sounds great. [~benedict] who would be able to take up the audit? Is this 
something I can help with?

> OOMs caught and not rethrown
> 
>
> Key: CASSANDRA-15214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15214
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client, Messaging/Internode
>Reporter: Benedict
>Priority: Normal
> Fix For: 4.0
>
>
> Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, 
> so presently there is no way to ensure that an OOM reaches the JVM handler to 
> trigger a crash/heapdump.
> It may be that the simplest most consistent way to do this would be to have a 
> single thread spawned at startup that waits for any exceptions we must 
> propagate to the Runtime.
> We could probably submit a patch upstream to Netty, but for a guaranteed 
> future proof approach, it may be worth paying the cost of a single thread.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Comment Edited] (CASSANDRA-15214) OOMs caught and not rethrown

2019-08-05 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-15214 at 8/5/19 8:07 PM:
--

I think this issue might be related to 
https://bugs.openjdk.java.net/browse/JDK-8027434. Other projects that use the 
JVM have run into a similar issue and the usual solution is to use 
[jvmkill|https://github.com/airlift/jvmkill]. The issue at hand is that when a 
JVM runs out of memory (heap or otherwise), it enters an undefined state. In 
this situation, I would not expect the handlers to work as expected. I think we 
should either use jvmkill or 
[jvmquake|https://github.com/Netflix-Skunkworks/jvmquake] to solve this issue 
as it has proven to be reliable and Netflix, Facebook and other large JVM users 
are actively using it.


was (Author: djoshi3):
I think this issue might be related to 
https://bugs.openjdk.java.net/browse/JDK-8027434. Other projects that use the 
JVM have run into a similar issue and the usual solution is to use 
[jvmkill|https://github.com/airlift/jvmkill]. The issue at hand is when a JVM 
has run out of memory (heap or otherwise), it enters an undefined state. In 
this situation, I would not expect the handlers to work as expected either. I 
think we should either use jvmkill or 
[jvmquake|https://github.com/Netflix-Skunkworks/jvmquake] to solve this issue 
as it has proven to be reliable and Netflix, Facebook and other large JVM users 
are actively using it.

> OOMs caught and not rethrown
> 
>
> Key: CASSANDRA-15214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15214
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client, Messaging/Internode
>Reporter: Benedict
>Priority: Normal
> Fix For: 4.0
>
>
> Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, 
> so presently there is no way to ensure that an OOM reaches the JVM handler to 
> trigger a crash/heapdump.
> It may be that the simplest most consistent way to do this would be to have a 
> single thread spawned at startup that waits for any exceptions we must 
> propagate to the Runtime.
> We could probably submit a patch upstream to Netty, but for a guaranteed 
> future proof approach, it may be worth paying the cost of a single thread.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (CASSANDRA-15214) OOMs caught and not rethrown

2019-08-05 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15214:
--

I think this issue might be related to 
https://bugs.openjdk.java.net/browse/JDK-8027434. Other projects that use the 
JVM have run into a similar issue and the usual solution is to use 
[jvmkill|https://github.com/airlift/jvmkill]. The issue at hand is when a JVM 
has run out of memory (heap or otherwise), it enters an undefined state. In 
this situation, I would not expect the handlers to work as expected either. I 
think we should either use jvmkill or 
[jvmquake|https://github.com/Netflix-Skunkworks/jvmquake] to solve this issue 
as it has proven to be reliable and Netflix, Facebook and other large JVM users 
are actively using it.

> OOMs caught and not rethrown
> 
>
> Key: CASSANDRA-15214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15214
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client, Messaging/Internode
>Reporter: Benedict
>Priority: Normal
> Fix For: 4.0
>
>
> Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, 
> so presently there is no way to ensure that an OOM reaches the JVM handler to 
> trigger a crash/heapdump.
> It may be that the simplest most consistent way to do this would be to have a 
> single thread spawned at startup that waits for any exceptions we must 
> propagate to the Runtime.
> We could probably submit a patch upstream to Netty, but for a guaranteed 
> future proof approach, it may be worth paying the cost of a single thread.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (CASSANDRA-15249) Add documentation on release lifecycle

2019-07-29 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15249:
--

Thanks for driving this [~sumanth.pasupuleti]. I see there are open questions 
at the bottom of the document. I think it would be a good idea to resolve them. 
Additionally, since this will be up on the official Apache Cassandra website 
and has to do with the release process, I think we should run it by the PMC.

> Add documentation on release lifecycle
> --
>
> Key: CASSANDRA-15249
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15249
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0
>
> Attachments: release_lifecycle.patch
>
>
> Relevant dev list mail thread: 
> https://lists.apache.org/thread.html/1a768d057d1af5a0f373c4c399a23e65cb04c61bbfff612634b9437c@%3Cdev.cassandra.apache.org%3E
> Google doc with community collaboration on documenting release lifecycle 
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-14888) Several mbeans are not unregistered when dropping a keyspace and table

2019-07-28 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-14888:
-
Status: Review In Progress  (was: Patch Available)

> Several mbeans are not unregistered when dropping a keyspace and table
> --
>
> Key: CASSANDRA-14888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Alex Deparvu
>Priority: Urgent
>  Labels: patch-available
> Fix For: 4.0.x
>
> Attachments: CASSANDRA-14888.patch
>
>
> CasCommit, CasPrepare, CasPropose, ReadRepairRequests, 
> ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, 
> PartitionsValidated, RepairPrepareTime, RepairSyncTime, 
> RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, 
> WriteFailedIdealCL
> Basically for 3 years people haven't known what they are doing because the 
> entire thing is kind of obscure. Fix it and also add a dtest that detects if 
> any mbeans are left behind after dropping a table and keyspace.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (CASSANDRA-14888) Several mbeans are not unregistered when dropping a keyspace and table

2019-07-28 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-14888:
--

[~stillalex], thank you for the patch. I have imported it to a branch in my 
repo. 
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:14888-trunk?expand=1
 I will review it shortly and provide you feedback.

> Several mbeans are not unregistered when dropping a keyspace and table
> --
>
> Key: CASSANDRA-14888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Alex Deparvu
>Priority: Urgent
>  Labels: patch-available
> Fix For: 4.0.x
>
> Attachments: CASSANDRA-14888.patch
>
>
> CasCommit, CasPrepare, CasPropose, ReadRepairRequests, 
> ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, 
> PartitionsValidated, RepairPrepareTime, RepairSyncTime, 
> RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, 
> WriteFailedIdealCL
> Basically for 3 years people haven't known what they are doing because the 
> entire thing is kind of obscure. Fix it and also add a dtest that detects if 
> any mbeans are left behind after dropping a table and keyspace.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-14888) Several mbeans are not unregistered when dropping a keyspace and table

2019-07-28 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-14888:
-
Reviewers: Dinesh Joshi

> Several mbeans are not unregistered when dropping a keyspace and table
> --
>
> Key: CASSANDRA-14888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Alex Deparvu
>Priority: Urgent
>  Labels: patch-available
> Fix For: 4.0.x
>
> Attachments: CASSANDRA-14888.patch
>
>
> CasCommit, CasPrepare, CasPropose, ReadRepairRequests, 
> ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, 
> PartitionsValidated, RepairPrepareTime, RepairSyncTime, 
> RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, 
> WriteFailedIdealCL
> Basically for 3 years people haven't known what they are doing because the 
> entire thing is kind of obscure. Fix it and also add a dtest that detects if 
> any mbeans are left behind after dropping a table and keyspace.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh

2019-07-27 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

Hi [~ptbannister], thanks for the changes and sorry about the slow responses on 
my end. I had a few questions and comments regarding 
[this|https://github.com/ptbannister/cassandra/commit/db10edd766f9d568f7df79f6d8cd16bc496dd6c3]
 change.

I see you're trying to prevent a {{NoneType}} comparison. What test 
specifically broke due to this change? Could you add a unit test to ensure that 
this function works correctly with {{NoneType}} arguments? I want to also point 
out that the behavior of this code is same under Python 2.7 and 3.6. Since 
{{cassandra.metadata.Token}} implements {{__lt__()}} and {{__gt__()}} methods, 
you will get an error if you try comparing it with {{NoneType}} so I'm a bit 
puzzled why you needed this change. I agree that this piece of code is error 
prone in the face of {{NoneType}} arguments and we should fix it. I'm just 
trying to understand did we actually break something during migration?

Other than this question, the only feedback I have so far is to remove 
commented out code from {{bin/cqlsh}}.

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Commented] (CASSANDRA-14888) Several mbeans are not unregistered when dropping a keyspace and table

2019-07-26 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-14888:
--

Yes, I’ll be happy to review it.

> Several mbeans are not unregistered when dropping a keyspace and table
> --
>
> Key: CASSANDRA-14888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Alex Deparvu
>Priority: Urgent
>  Labels: patch-available
> Fix For: 4.0.x
>
> Attachments: CASSANDRA-14888.patch
>
>
> CasCommit, CasPrepare, CasPropose, ReadRepairRequests, 
> ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, 
> PartitionsValidated, RepairPrepareTime, RepairSyncTime, 
> RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, 
> WriteFailedIdealCL
> Basically for 3 years people haven't known what they are doing because the 
> entire thing is kind of obscure. Fix it and also add a dtest that detects if 
> any mbeans are left behind after dropping a table and keyspace.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Updated] (CASSANDRA-14888) Several mbeans are not unregistered when dropping a keyspace and table

2019-07-26 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-14888:
-
Test and Documentation Plan: Review and tests
 Status: Patch Available  (was: Open)

> Several mbeans are not unregistered when dropping a keyspace and table
> --
>
> Key: CASSANDRA-14888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Alex Deparvu
>Priority: Urgent
>  Labels: patch-available
> Fix For: 4.0.x
>
> Attachments: CASSANDRA-14888.patch
>
>
> CasCommit, CasPrepare, CasPropose, ReadRepairRequests, 
> ShortReadProtectionRequests, AntiCompactionTime, BytesValidated, 
> PartitionsValidated, RepairPrepareTime, RepairSyncTime, 
> RepairedDataInconsistencies, ViewLockAcquireTime, ViewReadTime, 
> WriteFailedIdealCL
> Basically for 3 years people haven't known what they are doing because the 
> entire thing is kind of obscure. Fix it and also add a dtest that detects if 
> any mbeans are left behind after dropping a table and keyspace.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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



[jira] [Comment Edited] (CASSANDRA-10190) Python 3 support for cqlsh

2019-06-14 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-10190 at 6/14/19 7:19 AM:
---

Hi [~ptbannister], thank you for making the changes. The latest set of changes 
look good. [I ran the 
dtests|https://circleci.com/workflow-run/9ce3ae71-70d4-4fd7-b590-1449323408ff]. 
There are some cqlsh related failures in the vnodes case. Could you please take 
a look?

Additionally, as part of this change, it would be desirable to run cqlsh tests 
with Python 2.7 as well as Python 3. I think it would be trivial to do it if we 
can override the Python interpreter's path by providing it as a parameter. WDYT?


was (Author: djoshi3):
Hi [~ptbannister], thank you for making the changes. The latest set of changes 
look good. I ran the dtests. There are some cqlsh related failures in the 
vnodes case. Could you please take a look?

Additionally, as part of this change, I think it would be desirable to run 
cqlsh tests with Python 2.7 as well as Python 3. I think it would be trivial to 
do it if we can override the Python interpreter's path by providing it as a 
parameter. WDYT?

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-06-14 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

Hi [~ptbannister], thank you for making the changes. The latest set of changes 
look good. I ran the dtests. There are some cqlsh related failures in the 
vnodes case. Could you please take a look?

Additionally, as part of this change, I think it would be desirable to run 
cqlsh tests with Python 2.7 as well as Python 3. I think it would be trivial to 
do it if we can override the Python interpreter's path by providing it as a 
parameter. WDYT?

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-06-05 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-10190 at 6/5/19 8:22 AM:
--

Hi [~ptbannister], I have gone over your patch and here are some minor comments 
-

{{cqlsh.py}}
 * Why is {{FrozenType}} commented out?
 * You've replaced occurrences of {{%r}} with {{"'{}'"}}. However, we should 
use "\{!r}" instead which is equivalent to {{%r}}. Please remove the single 
quotes surrounding the object names.
 * Remove {{six}} import from L42. This is a premature import and breaks Python 
2. {{six}} is imported on L150 once we have discovered the Python libraries 
path for cqlsh.
 * Python version check could be a bit more readable like this 
{{sys.version_info.major != 3 and (sys.version_info.major == 2 and 
sys.version_info.minor != 7)}} instead of using indexes.

{{copyutil.py}}
 * L2514 remove commented out code.

{{cqlsh}}
 * Nit: L51: python -> Python


was (Author: djoshi3):
Hi [~ptbannister], I have gone over your patch and here are some minor comments 
-

{{cqlsh.py}}
 * Why is {{FrozenType}} commented out?
 * You've replaced occurrences of {{%r}} with {{"'{}'"}}. However, we should 
use \{{"{!r}"}} instead which is equivalent to {{%r}}. Please remove the single 
quotes surrounding the object names.
 * Remove {{six}} import from L42. This is a premature import and breaks Python 
2. {{six}} is imported on L150 once we have discovered the Python libraries 
path for cqlsh.
 * Python version check could be a bit more readable like this 
{{sys.version_info.major != 3 and (sys.version_info.major == 2 and 
sys.version_info.minor != 7)}} instead of using indexes.

{{copyutil.py}}
 * L2514 remove commented out code.

{{cqlsh}}
 * Nit: L51: python -> Python

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-06-05 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-10190 at 6/5/19 8:22 AM:
--

Hi [~ptbannister], I have gone over your patch and here are some minor comments 
-

{{cqlsh.py}}
 * Why is {{FrozenType}} commented out?
 * You've replaced occurrences of {{%r}} with {{"'{}'"}}. However, we should 
use \{{"{!r}"}} instead which is equivalent to {{%r}}. Please remove the single 
quotes surrounding the object names.
 * Remove {{six}} import from L42. This is a premature import and breaks Python 
2. {{six}} is imported on L150 once we have discovered the Python libraries 
path for cqlsh.
 * Python version check could be a bit more readable like this 
{{sys.version_info.major != 3 and (sys.version_info.major == 2 and 
sys.version_info.minor != 7)}} instead of using indexes.

{{copyutil.py}}
 * L2514 remove commented out code.

{{cqlsh}}
 * Nit: L51: python -> Python


was (Author: djoshi3):
Hi [~ptbannister], I have gone over your patch and here are some minor comments 
-

{{cqlsh.py}}
 * Why is {{FrozenType}} commented out?
 * You've replaced occurrences of {{%r}} with \{{"'{}'"}}. However, we should 
use \{{"{!r}"}} instead which is equivalent to \{{%r}}. Please remove the 
single quotes surrounding the object names.
 * Remove {{six}} import from L42. This is a premature import and breaks Python 
2. {{six}} is imported on L150 once we have discovered the Python libraries 
path for cqlsh.
 * Python version check could be a bit more readable like this 
{{sys.version_info.major != 3 and (sys.version_info.major == 2 and 
sys.version_info.minor != 7)}} instead of using indexes.

{{copyutil.py}}
 * L2514 remove commented out code.

{{cqlsh}}
 * Nit: L51: python -> Python

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-06-05 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-10190 at 6/5/19 8:21 AM:
--

Hi [~ptbannister], I have gone over your patch and here are some minor comments 
-

{{cqlsh.py}}
 * Why is {{FrozenType}} commented out?
 * You've replaced occurrences of {{%r}} with \{{"'{}'"}}. However, we should 
use \{{"{!r}"}} instead which is equivalent to \{{%r}}. Please remove the 
single quotes surrounding the object names.
 * Remove {{six}} import from L42. This is a premature import and breaks Python 
2. {{six}} is imported on L150 once we have discovered the Python libraries 
path for cqlsh.
 * Python version check could be a bit more readable like this 
{{sys.version_info.major != 3 and (sys.version_info.major == 2 and 
sys.version_info.minor != 7)}} instead of using indexes.

{{copyutil.py}}
 * L2514 remove commented out code.

{{cqlsh}}
 * Nit: L51: python -> Python


was (Author: djoshi3):
Hi [~ptbannister], I have gone over your patch and here are some minor comments 
-

{{cqlsh.py}}
* Why is {{FrozenType}} commented out?
* You've replaced occurrences of %r with "'{}'". However, we should use "{!r}" 
instead which is equivalent to %r. Please remove the single quotes surrounding 
the object names.
* Remove {{six}} import from L42. This is a premature import and breaks Python 
2. {{six}} is imported on L150 once we have discovered the Python libraries 
path for cqlsh.
* Python version check could be a bit more readable like this 
{{sys.version_info.major != 3 and (sys.version_info.major == 2 and 
sys.version_info.minor != 7)}} instead of using indexes.

{{copyutil.py}}
* L2514 remove commented out code.

{{cqlsh}}
* Nit: L51: python -> Python


> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-06-05 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

Hi [~ptbannister], I have gone over your patch and here are some minor comments 
-

{{cqlsh.py}}
* Why is {{FrozenType}} commented out?
* You've replaced occurrences of %r with "'{}'". However, we should use "{!r}" 
instead which is equivalent to %r. Please remove the single quotes surrounding 
the object names.
* Remove {{six}} import from L42. This is a premature import and breaks Python 
2. {{six}} is imported on L150 once we have discovered the Python libraries 
path for cqlsh.
* Python version check could be a bit more readable like this 
{{sys.version_info.major != 3 and (sys.version_info.major == 2 and 
sys.version_info.minor != 7)}} instead of using indexes.

{{copyutil.py}}
* L2514 remove commented out code.

{{cqlsh}}
* Nit: L51: python -> Python


> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-05-21 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

[~spo...@gmail.com], if you look at the {{README}}, the ultimate intent is to 
have this integrated in the test pipeline. However, we ran into some issues. 
The current state allows for manually verifying cqlsh with Python 2 & 3.

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-15132) one-way TLS authentication for client encryption is broken

2019-05-21 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15132:
--

[~jsanda], apologies for not being clear in my original question. My 
understanding is that currently, trunk logs an unnecessary log entry (which 
definitely is an annoyance). Other than this log entry spamming the logs, is 
there anything else broken?

> one-way TLS authentication for client encryption is broken
> --
>
> Key: CASSANDRA-15132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15132
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Encryption
>Reporter: John Sanda
>Priority: Normal
>
> CASSANDRA-14652 caused a regression for client/native transport encryption. 
> It broken one-way TLS authentication where only the client authenticates the 
> coordinator node's certificate chain. This would be configured in 
> cassandra.yaml as such:
> {noformat}
> client_encryption_options:
>   enabled: true
>   keystore: /path/to/keystore
>   keystore_password: my_keystore_password
>   optional: false
>   require_client_auth: false
> {noformat}
> With the changes in CASSANDRA-14652, ServerConnection.java always assumes 
> that there will always be a client certificate chain, which will not be the 
> case with the above configuration.
> Here is the error that shows up in the logs:
> {noformat}
> ERROR [Native-Transport-Requests-1] 2019-05-17 18:20:20,016 
> ServerConnection.java:147 - Failed to get peer certificates for peer 
> /127.0.0.1:50736
> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> at 
> sun.security.ssl.SSLSessionImpl.getPeerCertificateChain(SSLSessionImpl.java:501)
>  ~[na:1.8.0_202]
> at 
> org.apache.cassandra.transport.ServerConnection.certificates(ServerConnection.java:143)
>  [main/:na]
> at 
> org.apache.cassandra.transport.ServerConnection.getSaslNegotiator(ServerConnection.java:127)
>  [main/:na]
> at 
> org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:75)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [main/:na]
> 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_202]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
> {noformat}



--
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-15132) one-way TLS authentication for client encryption is broken

2019-05-20 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15132:
-
Status: Awaiting Feedback  (was: Triage Needed)

Hi [~jsanda], thanks for reporting this issue and also for the patch. Other 
than an additional log entry, I don't think this breaks anything, does it?

> one-way TLS authentication for client encryption is broken
> --
>
> Key: CASSANDRA-15132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15132
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Encryption
>Reporter: John Sanda
>Priority: Normal
>
> CASSANDRA-14652 caused a regression for client/native transport encryption. 
> It broken one-way TLS authentication where only the client authenticates the 
> coordinator node's certificate chain. This would be configured in 
> cassandra.yaml as such:
> {noformat}
> client_encryption_options:
>   enabled: true
>   keystore: /path/to/keystore
>   keystore_password: my_keystore_password
>   optional: false
>   require_client_auth: false
> {noformat}
> With the changes in CASSANDRA-14652, ServerConnection.java always assumes 
> that there will always be a client certificate chain, which will not be the 
> case with the above configuration.
> Here is the error that shows up in the logs:
> {noformat}
> ERROR [Native-Transport-Requests-1] 2019-05-17 18:20:20,016 
> ServerConnection.java:147 - Failed to get peer certificates for peer 
> /127.0.0.1:50736
> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> at 
> sun.security.ssl.SSLSessionImpl.getPeerCertificateChain(SSLSessionImpl.java:501)
>  ~[na:1.8.0_202]
> at 
> org.apache.cassandra.transport.ServerConnection.certificates(ServerConnection.java:143)
>  [main/:na]
> at 
> org.apache.cassandra.transport.ServerConnection.getSaslNegotiator(ServerConnection.java:127)
>  [main/:na]
> at 
> org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:75)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [main/:na]
> 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_202]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
> {noformat}



--
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-15124) Virtual tables API endpoints for sidecar

2019-05-16 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15124:
-
Reviewers: Dinesh Joshi, Vinay Chella

> Virtual tables API endpoints for sidecar
> 
>
> Key: CASSANDRA-15124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15124
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Sidecar
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Expose the existing virtual tables in sidecar api



--
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-14629) Abstract Virtual Table for very large result sets

2019-05-16 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-14629:
-
Reviewers: Dinesh Joshi, Vinay Chella  (was: Dinesh Joshi)

> Abstract Virtual Table for very large result sets
> -
>
> Key: CASSANDRA-14629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14629
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
>  Labels: pull-request-available, virtual-tables
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For virtual tables that are very large we cannot use existing 
> abstractvirtualtable since it would OOM the node possibly. An example would 
> be a table to view the internal cache contents or to view contents of 
> sstables.



--
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-15108) Support building Cassandra with JDK 11

2019-05-10 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15108:
--

I see, thanks for the clarification. Could we just add a comment that clarifies 
this so someone does not inadvertently change this code?

> Support building Cassandra with JDK 11
> --
>
> Key: CASSANDRA-15108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15108
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
>
> With the changes in java 8 support and licensing, we should be able to build 
> and run Cassandra with java 11.



--
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-15108) Support building Cassandra with JDK 11

2019-05-10 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-15108 at 5/10/19 5:36 PM:
---

I see, thanks for the clarification. Could we just add a comment that clarifies 
this so someone does not inadvertently change this code? You can add the 
comment on the commit. +1.


was (Author: djoshi3):
I see, thanks for the clarification. Could we just add a comment that clarifies 
this so someone does not inadvertently change this code?

> Support building Cassandra with JDK 11
> --
>
> Key: CASSANDRA-15108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15108
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
>
> With the changes in java 8 support and licensing, we should be able to build 
> and run Cassandra with java 11.



--
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-15108) Support building Cassandra with JDK 11

2019-05-09 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15108:
--

Hi [~bdeggleston], I think the PR is looking good. There is just one 
suggestion. Instead of using double checked locking, you can use 
{{computeIfAbsent}} API. I've made the relevant change here: 
https://github.com/beobal/cassandra/compare/15108...dineshjoshi:15108-trunk-review?expand=1

> Support building Cassandra with JDK 11
> --
>
> Key: CASSANDRA-15108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15108
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
>
> With the changes in java 8 support and licensing, we should be able to build 
> and run Cassandra with java 11.



--
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-15066) Improvements to Internode Messaging

2019-04-27 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-15066 at 4/27/19 6:30 AM:
---

[~ifesdjeen] thank you for the notes. They're very useful. I'm going over the 
code, primarily for my own curiosity.

[~jolynch] [~vinaykumarcse] thanks for testing the patch and the results. Is 
there a jira for the read perf issue? It would be great to have it linked here, 
assuming we want to fix it part of this patch.


was (Author: djoshi3):
[~ifesdjeen] thank you for the notes. They're very useful. I'm going over the 
code, primarily for my own curiosity.

[~jolynch] [~vinaykumarcse] thanks for testing the patch and the results. Is 
there a jira for the read perf issue? It would be great to have it linked here 
for posterity, assuming we want to fix it part of this patch.

> Improvements to Internode Messaging
> ---
>
> Key: CASSANDRA-15066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15066
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Benedict
>Assignee: Benedict
>Priority: High
> Fix For: 4.0
>
> Attachments: 20k_backfill.png, 60k_RPS.png, 
> 60k_RPS_CPU_bottleneck.png, backfill_cass_perf_ft_msg_tst.svg, 
> baseline_patch_vs_30x.png, increasing_reads_latency.png, 
> many_reads_cass_perf_ft_msg_tst.svg
>
>
> CASSANDRA-8457 introduced asynchronous networking to internode messaging, but 
> there have been several follow-up endeavours to improve some semantic issues. 
>  CASSANDRA-14503 and CASSANDRA-13630 are the latest such efforts, and were 
> combined some months ago into a single overarching refactor of the original 
> work, to address some of the issues that have been discovered.  Given the 
> criticality of this work to the project, we wanted to bring some more eyes to 
> bear to ensure the release goes ahead smoothly.  In doing so, we uncovered a 
> number of issues with messaging, some of which long standing, that we felt 
> needed to be addressed.  This patch widens the scope of CASSANDRA-14503 and 
> CASSANDRA-13630 in an effort to close the book on the messaging service, at 
> least for the foreseeable future.
> The patch includes a number of clarifying refactors that touch outside of the 
> {{net.async}} package, and a number of semantic changes to the {{net.async}} 
> packages itself.  We believe it clarifies the intent and behaviour of the 
> code while improving system stability, which we will outline in comments 
> below.
> https://github.com/belliottsmith/cassandra/tree/messaging-improvements



--
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-15066) Improvements to Internode Messaging

2019-04-27 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15066:
--

[~ifesdjeen] thank you for the notes. They're very useful. I'm going over the 
code, primarily for my own curiosity.

[~jolynch] [~vinaykumarcse] thanks for testing the patch and the results. Is 
there a jira for the read perf issue? It would be great to have it linked here 
for posterity, assuming we want to fix it part of this patch.

> Improvements to Internode Messaging
> ---
>
> Key: CASSANDRA-15066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15066
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Benedict
>Assignee: Benedict
>Priority: High
> Fix For: 4.0
>
> Attachments: 20k_backfill.png, 60k_RPS.png, 
> 60k_RPS_CPU_bottleneck.png, backfill_cass_perf_ft_msg_tst.svg, 
> baseline_patch_vs_30x.png, increasing_reads_latency.png, 
> many_reads_cass_perf_ft_msg_tst.svg
>
>
> CASSANDRA-8457 introduced asynchronous networking to internode messaging, but 
> there have been several follow-up endeavours to improve some semantic issues. 
>  CASSANDRA-14503 and CASSANDRA-13630 are the latest such efforts, and were 
> combined some months ago into a single overarching refactor of the original 
> work, to address some of the issues that have been discovered.  Given the 
> criticality of this work to the project, we wanted to bring some more eyes to 
> bear to ensure the release goes ahead smoothly.  In doing so, we uncovered a 
> number of issues with messaging, some of which long standing, that we felt 
> needed to be addressed.  This patch widens the scope of CASSANDRA-14503 and 
> CASSANDRA-13630 in an effort to close the book on the messaging service, at 
> least for the foreseeable future.
> The patch includes a number of clarifying refactors that touch outside of the 
> {{net.async}} package, and a number of semantic changes to the {{net.async}} 
> packages itself.  We believe it clarifies the intent and behaviour of the 
> code while improving system stability, which we will outline in comments 
> below.
> https://github.com/belliottsmith/cassandra/tree/messaging-improvements



--
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-10190) Python 3 support for cqlsh

2019-04-26 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

[~ptbannister] I found a few issues and fixed them. Here's a branch with the 
changes and rebased on the current trunk - 
https://github.com/dineshjoshi/cassandra/tree/10190-review

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-15104) Dtest change python2 grammar to python3

2019-04-26 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15104:
--

No worries! In the future, you can ask on the dev@ list or ping us on IRC 
(#cassandra-dev). More info here: http://cassandra.apache.org/community/

> Dtest change python2 grammar to python3 
> 
>
> Key: CASSANDRA-15104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15104
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Normal
>
> We know that for  some code are written in python2, such as dtest.py (line 
> :91) , and some major version of python2 will be dropped. So if it is nessary 
> to change some of the code to python3 style ?



--
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-10190) Python 3 support for cqlsh

2019-04-26 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-10190:
-
Reviewers: Dinesh Joshi

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-04-26 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-10190:
--

[~ptbannister] I went over the tests in 
https://github.com/ptbannister/cassandra/tree/10190-rebase-20190329 and looks 
like we have reached parity with Python 2.7. Could you please create a PR for 
review? 

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-10190) Python 3 support for cqlsh

2019-04-26 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-10190:
-
Test and Documentation Plan: Tests are already included.
 Status: Patch Available  (was: Open)

> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
>  Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh. 
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a 
> .python-version containing "2.7". But it would be nice if cqlsh supported 
> modern Python versions out of the box.



--
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-15104) Dtest change python2 grammar to python3

2019-04-25 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15104:
--

Hi [~maxwellguo], are you talking about this tests in this repo? 
https://github.com/apache/cassandra-dtest They're already compatible with 
Python 3.

> Dtest change python2 grammar to python3 
> 
>
> Key: CASSANDRA-15104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15104
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Normal
>
> We know that for  some code are written in python2, such as dtest.py (line 
> :91) , and some major version of python2 will be dropped. So if it is nessary 
> to change some of the code to python3 style ?



--
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-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

2019-04-17 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15083:
--

hi [~michaelsembwever], this looks very good! I was able to run and debug the 
project OOTB. Could you please update {{ide.rst}} to include instructions to 
set {{JAVA8_HOME}} and also mention that build, run, debug and profile actions 
work OOTB. Please feel free to do it on commit. +1.

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
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-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

2019-04-15 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15083:
--

So ran into two issues. First, {{JAVA8_HOME}} isn't declared.
 !nb-e1.png! 

When I did set it, I got this -
 !nb-e2.png! 

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
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-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

2019-04-15 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15083:
-
Attachment: nb-e2.png
nb-e1.png

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
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-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

2019-04-15 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15083:
-
Reviewers: Dinesh Joshi

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
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-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

2019-04-15 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15083:
-
Status: Awaiting Feedback  (was: Triage Needed)

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
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-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

2019-04-15 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi reassigned CASSANDRA-15083:


Assignee: mck

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
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-15073) Apache NetBeans project files

2019-04-11 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15073:
--

LGTM, +1 Thank you for working on this, [~michaelsembwever].

> Apache NetBeans project files
> -
>
> Key: CASSANDRA-15073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15073
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Attachments: netbeans-errors-2.png, netbeans-errors.png, 
> netbeans-ss.png
>
>
> Provide necessary project files so to be able to open the Cassandra project 
> in Apache NetBeans.
> No additional project functionality is required beyond being able to edit the 
> project's source files. Building the project is still expected to be done via 
> `ant` on the command-line.



--
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-15073) Apache NetBeans project files

2019-04-11 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi edited comment on CASSANDRA-15073 at 4/11/19 10:55 PM:


[~michaelsembwever] looks a lot better now. No errors in the actual files but 
the top level project still has an error icon but everything else works as 
expected. I think the error icon is a bug. I couldn't find an explanation for 
it. Anyway, I was able to execute the {{CassandraDaemon}} class.

 !netbeans-ss.png! 

I was also able to get {{CassandraDaemon}} to start up but had to add a few 
jvmargs in the {{ide-file-target.xml}}. Not an expert in this but here are the 
arguments –
 
{code:xml}













{code}

Could we make it so that it makes it easier for the user to run Cassandra 
daemon? I am sorry I am expanding the scope of this ticket, but I think it 
would be a very useful addition from a developer's perspective. If it is too 
complicated, we can document it and move on.


was (Author: djoshi3):
[~michaelsembwever] looks a lot better now. No errors in the actual files but 
the top level project still has an error icon but everything else works as 
expected. I think the error icon is a bug. I couldn't find an explanation for 
it. Anyway, I was able to execute the {{CassandraDaemon}} class.

 !netbeans-ss.png! 

I was also able to get {{CassandraDaemon}} to start up but had to add a few 
jvmargs in the {{ide-file-target.xml}}. Not an expert in this but here are the 
arguments –
 
{code:xml}
   












{code}

Could we make it so that it makes it easier for the user to run Cassandra 
daemon? I am sorry I am expanding the scope of this ticket, but I think it 
would be a very useful addition from a developer's perspective. If it is too 
complicated, we can document it and move on.

> Apache NetBeans project files
> -
>
> Key: CASSANDRA-15073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15073
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Attachments: netbeans-errors-2.png, netbeans-errors.png, 
> netbeans-ss.png
>
>
> Provide necessary project files so to be able to open the Cassandra project 
> in Apache NetBeans.
> No additional project functionality is required beyond being able to edit the 
> project's source files. Building the project is still expected to be done via 
> `ant` on the command-line.



--
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-15073) Apache NetBeans project files

2019-04-11 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-15073:
--

[~michaelsembwever] looks a lot better now. No errors in the actual files but 
the top level project still has an error icon but everything else works as 
expected. I think the error icon is a bug. I couldn't find an explanation for 
it. Anyway, I was able to execute the {{CassandraDaemon}} class.

 !netbeans-ss.png! 

I was also able to get {{CassandraDaemon}} to start up but had to add a few 
jvmargs in the {{ide-file-target.xml}}. Not an expert in this but here are the 
arguments –
 
{code:xml}
   












{code}

Could we make it so that it makes it easier for the user to run Cassandra 
daemon? I am sorry I am expanding the scope of this ticket, but I think it 
would be a very useful addition from a developer's perspective. If it is too 
complicated, we can document it and move on.

> Apache NetBeans project files
> -
>
> Key: CASSANDRA-15073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15073
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Attachments: netbeans-errors-2.png, netbeans-errors.png, 
> netbeans-ss.png
>
>
> Provide necessary project files so to be able to open the Cassandra project 
> in Apache NetBeans.
> No additional project functionality is required beyond being able to edit the 
> project's source files. Building the project is still expected to be done via 
> `ant` on the command-line.



--
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-15073) Apache NetBeans project files

2019-04-11 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi updated CASSANDRA-15073:
-
Attachment: netbeans-ss.png

> Apache NetBeans project files
> -
>
> Key: CASSANDRA-15073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15073
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Attachments: netbeans-errors-2.png, netbeans-errors.png, 
> netbeans-ss.png
>
>
> Provide necessary project files so to be able to open the Cassandra project 
> in Apache NetBeans.
> No additional project functionality is required beyond being able to edit the 
> project's source files. Building the project is still expected to be done via 
> `ant` on the command-line.



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

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



  1   2   3   4   5   6   7   >