[jira] [Updated] (CASSANDRA-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-14616:
-
Reviewer: Stefania
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Jeremy
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14890) cassandra-stress hang for 200 seconds if `n` is not specified
[
https://issues.apache.org/jira/browse/CASSANDRA-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-14890:
-
Reviewer: (was: Stefania)
> cassandra-stress hang for 200 seconds if `n` is not specified
> -
>
> Key: CASSANDRA-14890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14890
> Project: Cassandra
> Issue Type: Bug
> Components: Stress
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>
> if parameter {{n}} is not specified, cassandra-stress will hang (wait) for
> 200 seconds between warm-up and sending traffic.
> For example, the following command will hang 200 seconds before sending the
> traffic:
> {noformat}
> $ ./tools/bin/cassandra-stress write
> ...
> Created keyspaces. Sleeping 1s for propagation.
> Sleeping 2s...
> Warming up WRITE with 0 iterations...
> Failed to connect over JMX; not collecting these stats
> {noformat}
> It's waiting for this:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/util/Uncertainty.java#L72]
> As there's no warm-up traffic (CASSANDRA-13773), it will wait until:
> {noformat}
> (measurements >= waiter.maxMeasurements)
> {noformat}
> {{maxMeasurements}} is 200 by default:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/settings/SettingsCommand.java#L153]
--
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-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-14616:
-
Status: Ready to Commit (was: Patch Available)
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Jeremy
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687400#comment-16687400
]
Stefania commented on CASSANDRA-14616:
--
[~jay.zhuang] , [~Yarnspinner] , thanks for fixing this problem and writing the
test.
I checked both patches, they are both good. Perhap's Jay's approach of assuming
50,000 iterations for duration tests is slightly preferable since that was the
old behavior.
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Jeremy
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687347#comment-16687347
]
Jay Zhuang commented on CASSANDRA-14616:
The failed the utest is because of CASSANDRA-14891
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Jeremy
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14890) cassandra-stress hang for 200 seconds if `n` is not specified
[
https://issues.apache.org/jira/browse/CASSANDRA-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-14890:
-
Reviewer: Stefania
> cassandra-stress hang for 200 seconds if `n` is not specified
> -
>
> Key: CASSANDRA-14890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14890
> Project: Cassandra
> Issue Type: Bug
> Components: Stress
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>
> if parameter {{n}} is not specified, cassandra-stress will hang (wait) for
> 200 seconds between warm-up and sending traffic.
> For example, the following command will hang 200 seconds before sending the
> traffic:
> {noformat}
> $ ./tools/bin/cassandra-stress write
> ...
> Created keyspaces. Sleeping 1s for propagation.
> Sleeping 2s...
> Warming up WRITE with 0 iterations...
> Failed to connect over JMX; not collecting these stats
> {noformat}
> It's waiting for this:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/util/Uncertainty.java#L72]
> As there's no warm-up traffic (CASSANDRA-13773), it will wait until:
> {noformat}
> (measurements >= waiter.maxMeasurements)
> {noformat}
> {{maxMeasurements}} is 200 by default:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/settings/SettingsCommand.java#L153]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14891) [utest] LegacySSTableTest.testInaccurateSSTableMinMax test failed
Jay Zhuang created CASSANDRA-14891:
--
Summary: [utest] LegacySSTableTest.testInaccurateSSTableMinMax
test failed
Key: CASSANDRA-14891
URL: https://issues.apache.org/jira/browse/CASSANDRA-14891
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Jay Zhuang
{noformat}
junit.framework.AssertionFailedError
at
org.apache.cassandra.db.SinglePartitionSliceCommandTest.getUnfilteredsFromSinglePartition(SinglePartitionSliceCommandTest.java:404)
at
org.apache.cassandra.io.sstable.LegacySSTableTest.ttestInaccurateSSTableMinMax(LegacySSTableTest.java:323)
{noformat}
Related to CASSANDRA-14861
--
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-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Zhuang reassigned CASSANDRA-14616:
--
Assignee: Jeremy Quinn
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Jeremy Quinn
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Zhuang updated CASSANDRA-14616:
---
Reproduced In: 3.11.0, 4.0
Status: Patch Available (was: Open)
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Jeremy
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Zhuang reassigned CASSANDRA-14616:
--
Assignee: Jeremy (was: Jeremy Quinn)
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Jeremy
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14616) cassandra-stress write hangs with default options
[
https://issues.apache.org/jira/browse/CASSANDRA-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687300#comment-16687300
]
Jay Zhuang commented on CASSANDRA-14616:
Hi [~Yarnspinner], the fix looks good. I had the similar fix which re-enables
{{warm-up}} to 50k as before
([{{StressAction.java}}|https://github.com/apache/cassandra/commit/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117#diff-fd2f2d2364937fcb1c0d73c8314f1418L90])
|Branch|uTest|dTest|
|[14890-3.0|https://github.com/cooldoger/cassandra/tree/14890-3.0]|[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/]|
|[14890-3.11|https://github.com/cooldoger/cassandra/tree/14890-3.11]|[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/]|
|[14890-trunk|https://github.com/cooldoger/cassandra/tree/14890-trunk]|[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/]|
Here is a dTest to reproduce the problem:
|[14890|https://github.com/cooldoger/cassandra-dtest/tree/14890]|
> cassandra-stress write hangs with default options
> -
>
> Key: CASSANDRA-14616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14616
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Priority: Major
>
> Cassandra stress sits there for incredibly long time after connecting to JMX.
> To reproduce {code}./tools/bin/cassandra-stress write{code}
> If you give it a -n its not as bad which is why dtests etc dont seem to be
> impacted. Does not occur in 3.0 branch but does in 3.11 and trunk
--
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-14890) cassandra-stress hang for 200 seconds if `n` is not specified
[
https://issues.apache.org/jira/browse/CASSANDRA-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Zhuang updated CASSANDRA-14890:
---
Resolution: Duplicate
Status: Resolved (was: Patch Available)
Resolve as duplication to CASSANDRA-14616.
> cassandra-stress hang for 200 seconds if `n` is not specified
> -
>
> Key: CASSANDRA-14890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14890
> Project: Cassandra
> Issue Type: Bug
> Components: Stress
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>
> if parameter {{n}} is not specified, cassandra-stress will hang (wait) for
> 200 seconds between warm-up and sending traffic.
> For example, the following command will hang 200 seconds before sending the
> traffic:
> {noformat}
> $ ./tools/bin/cassandra-stress write
> ...
> Created keyspaces. Sleeping 1s for propagation.
> Sleeping 2s...
> Warming up WRITE with 0 iterations...
> Failed to connect over JMX; not collecting these stats
> {noformat}
> It's waiting for this:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/util/Uncertainty.java#L72]
> As there's no warm-up traffic (CASSANDRA-13773), it will wait until:
> {noformat}
> (measurements >= waiter.maxMeasurements)
> {noformat}
> {{maxMeasurements}} is 200 by default:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/settings/SettingsCommand.java#L153]
--
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-14890) cassandra-stress hang for 200 seconds if `n` is not specified
[
https://issues.apache.org/jira/browse/CASSANDRA-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Zhuang updated CASSANDRA-14890:
---
Summary: cassandra-stress hang for 200 seconds if `n` is not specified
(was: cassandra-stress hang for 200 seconds if n is not specified)
> cassandra-stress hang for 200 seconds if `n` is not specified
> -
>
> Key: CASSANDRA-14890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14890
> Project: Cassandra
> Issue Type: Bug
> Components: Stress
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>
> if parameter {{n}} is not specified, cassandra-stress will hang (wait) for
> 200 seconds between warm-up and sending traffic.
> For example, the following command will hang 200 seconds before sending the
> traffic:
> {noformat}
> $ ./tools/bin/cassandra-stress write
> ...
> Created keyspaces. Sleeping 1s for propagation.
> Sleeping 2s...
> Warming up WRITE with 0 iterations...
> Failed to connect over JMX; not collecting these stats
> {noformat}
> It's waiting for this:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/util/Uncertainty.java#L72]
> As there's no warm-up traffic (CASSANDRA-13773), it will wait until:
> {noformat}
> (measurements >= waiter.maxMeasurements)
> {noformat}
> {{maxMeasurements}} is 200 by default:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/settings/SettingsCommand.java#L153]
--
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-14890) cassandra-stress hang for 200 seconds if n is not specified
[
https://issues.apache.org/jira/browse/CASSANDRA-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687254#comment-16687254
]
Jay Zhuang commented on CASSANDRA-14890:
Here is a patch to re-enable {{warm-up}} if `n` is not set
([{{StressAction.java}}|https://github.com/apache/cassandra/commit/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117#diff-fd2f2d2364937fcb1c0d73c8314f1418L90]):
| Branch | uTest | dTest |
| [14890-3.0|https://github.com/cooldoger/cassandra/tree/14890-3.0] |
[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/]
|
| [14890-3.11|https://github.com/cooldoger/cassandra/tree/14890-3.11] |
[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/]
|
| [14890-trunk|https://github.com/cooldoger/cassandra/tree/14890-trunk] |
[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/]
|
Here is the dTest to reproduce the problem:
|[14890|https://github.com/cooldoger/cassandra-dtest/tree/14890]|
[~Stefania] would you please review?
> cassandra-stress hang for 200 seconds if n is not specified
> ---
>
> Key: CASSANDRA-14890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14890
> Project: Cassandra
> Issue Type: Bug
> Components: Stress
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>
> if parameter {{n}} is not specified, cassandra-stress will hang (wait) for
> 200 seconds between warm-up and sending traffic.
> For example, the following command will hang 200 seconds before sending the
> traffic:
> {noformat}
> $ ./tools/bin/cassandra-stress write
> ...
> Created keyspaces. Sleeping 1s for propagation.
> Sleeping 2s...
> Warming up WRITE with 0 iterations...
> Failed to connect over JMX; not collecting these stats
> {noformat}
> It's waiting for this:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/util/Uncertainty.java#L72]
> As there's no warm-up traffic (CASSANDRA-13773), it will wait until:
> {noformat}
> (measurements >= waiter.maxMeasurements)
> {noformat}
> {{maxMeasurements}} is 200 by default:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/settings/SettingsCommand.java#L153]
--
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-14890) cassandra-stress hang for 200 seconds if n is not specified
[
https://issues.apache.org/jira/browse/CASSANDRA-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687254#comment-16687254
]
Jay Zhuang edited comment on CASSANDRA-14890 at 11/14/18 10:51 PM:
---
Here is a patch to re-enable {{warm-up}} if `n` is not set
([{{StressAction.java}}|https://github.com/apache/cassandra/commit/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117#diff-fd2f2d2364937fcb1c0d73c8314f1418L90]):
|Branch|uTest|dTest|
|[14890-3.0|https://github.com/cooldoger/cassandra/tree/14890-3.0]|[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/]|
|[14890-3.11|https://github.com/cooldoger/cassandra/tree/14890-3.11]|[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/]|
|[14890-trunk|https://github.com/cooldoger/cassandra/tree/14890-trunk]|[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/]|
Here is a dTest to reproduce the problem:
|[14890|https://github.com/cooldoger/cassandra-dtest/tree/14890]|
[~Stefania] would you please review?
was (Author: jay.zhuang):
Here is a patch to re-enable {{warm-up}} if `n` is not set
([{{StressAction.java}}|https://github.com/apache/cassandra/commit/6a1b1f26b7174e8c9bf86a96514ab626ce2a4117#diff-fd2f2d2364937fcb1c0d73c8314f1418L90]):
| Branch | uTest | dTest |
| [14890-3.0|https://github.com/cooldoger/cassandra/tree/14890-3.0] |
[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.0]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/661/]
|
| [14890-3.11|https://github.com/cooldoger/cassandra/tree/14890-3.11] |
[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-3.11]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/662/]
|
| [14890-trunk|https://github.com/cooldoger/cassandra/tree/14890-trunk] |
[!https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14890-trunk]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/663/]
|
Here is the dTest to reproduce the problem:
|[14890|https://github.com/cooldoger/cassandra-dtest/tree/14890]|
[~Stefania] would you please review?
> cassandra-stress hang for 200 seconds if n is not specified
> ---
>
> Key: CASSANDRA-14890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14890
> Project: Cassandra
> Issue Type: Bug
> Components: Stress
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>
> if parameter {{n}} is not specified, cassandra-stress will hang (wait) for
> 200 seconds between warm-up and sending traffic.
> For example, the following command will hang 200 seconds before sending the
> traffic:
> {noformat}
> $ ./tools/bin/cassandra-stress write
> ...
> Created keyspaces. Sleeping 1s for propagation.
> Sleeping 2s...
> Warming up WRITE with 0 iterations...
> Failed to connect over JMX; not collecting these stats
> {noformat}
> It's waiting for this:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/util/Uncertainty.java#L72]
> As there's no warm-up traffic (CASSANDRA-13773), it will wait until:
> {noformat}
> (measurements >= waiter.maxMeasurements)
> {noformat}
> {{maxMeasurements}} is 200 by default:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/settings/SettingsCommand.java#L153]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CASSANDRA-14890) cassandra-stress hang for 200 seconds if n is not specified
[
https://issues.apache.org/jira/browse/CASSANDRA-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Zhuang updated CASSANDRA-14890:
---
Status: Patch Available (was: Open)
> cassandra-stress hang for 200 seconds if n is not specified
> ---
>
> Key: CASSANDRA-14890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14890
> Project: Cassandra
> Issue Type: Bug
> Components: Stress
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>
> if parameter {{n}} is not specified, cassandra-stress will hang (wait) for
> 200 seconds between warm-up and sending traffic.
> For example, the following command will hang 200 seconds before sending the
> traffic:
> {noformat}
> $ ./tools/bin/cassandra-stress write
> ...
> Created keyspaces. Sleeping 1s for propagation.
> Sleeping 2s...
> Warming up WRITE with 0 iterations...
> Failed to connect over JMX; not collecting these stats
> {noformat}
> It's waiting for this:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/util/Uncertainty.java#L72]
> As there's no warm-up traffic (CASSANDRA-13773), it will wait until:
> {noformat}
> (measurements >= waiter.maxMeasurements)
> {noformat}
> {{maxMeasurements}} is 200 by default:
> [https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/tools/stress/src/org/apache/cassandra/stress/settings/SettingsCommand.java#L153]
--
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-14869) Range.subtractContained produces incorrect results when used on full ring
[
https://issues.apache.org/jira/browse/CASSANDRA-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687167#comment-16687167
]
Jeff Jirsa commented on CASSANDRA-14869:
([~ifesdjeen], you could just push it into a branch and run it through circleci
just to have a passing dtest link for posterity)
> Range.subtractContained produces incorrect results when used on full ring
> -
>
> Key: CASSANDRA-14869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14869
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: range bug.jpg
>
>
> Currently {{Range.subtractContained}} returns incorrect results if minuend
> range covers full ring and:
> * subtrahend range wraps around. For example, {{(50, 50] - (10, 100]}}
> returns {{\{(50,10], (100,50]\}}} instead of {{(100,10]}}
> * subtrahend range covers the full ring as well. For example {{(50, 50] - (0,
> 0]}} returns {{\{(0,50], (50,0]\}}} instead of {{\{\}}}
--
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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686996#comment-16686996
]
Ariel Weisberg commented on CASSANDRA-11323:
Thanks [~BorisO]. 2.2 is getting critical bug fixes only so this can only go
into 3.0, 3.11, and trunk. Can you make patches for those three versions?
The log message could probably be more informative like "%d bytes required for
next commit log segment, but only %d bytes available. " It also seems like we
want this to occur for everything except ignore? Or maybe even then? I think
the only concern would be if we log it repeatedly when ignore is the policy due
to some high volume exception. You could use the NoSpamLogger to avoid that
issue.
Another issue is that this error is generated even if the exception is
something else. So we should probably have the log message specify that free
space is not necessarily the cause of this exception. And if we are getting
even more transparent, maybe we should specify the commit log directory path
just so people at a glance know what volume is in use.
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686975#comment-16686975
]
Ariel Weisberg commented on CASSANDRA-11939:
Thanks [~adeb0001]. I will try and look at the patches this week.
I don't think we have the clearest policy about modifying nodetool output, and
2.2 is getting critical bug fixes only. Mostly I just need to figure out
where/if we can make this change.
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Assignee: Amanda R Debrot
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-2.2.txt, 11939-3.0.txt,
> 11939-3.0.txt, 11939-3.11.txt, 11939-3.11.txt, 11939-output.txt,
> 11939-trunk.txt, 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg reassigned CASSANDRA-11939:
--
Assignee: Amanda R Debrot
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Assignee: Amanda R Debrot
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-2.2.txt, 11939-3.0.txt,
> 11939-3.0.txt, 11939-3.11.txt, 11939-3.11.txt, 11939-output.txt,
> 11939-trunk.txt, 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg reassigned CASSANDRA-11323:
--
Assignee: Boris Onufriyev
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686929#comment-16686929 ] Joseph Lynch commented on CASSANDRA-14821: -- [~ifesdjeen] please let myself or [~vinaykumarcse] know of any high value areas you think we could add some coverage using these in JVM dtests, we'd like to give them a try (and think they will be much easier to use than traditional dtests!). > Make it possible to run multi-node coordinator/replica tests in a single JVM > > > Key: CASSANDRA-14821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14821 > Project: Cassandra > Issue Type: Test >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > This patch proposes an in-JVM Distributed Tester that can help to write > distributed tests in a single JVM and be able to control node behaviour in a > fine-grained way and set up nodes exactly how one needs it: configuration > settings, parameters, which are also controllable in runtime on a per node > basis, so each node can have its own unique state. > It fires up multiple Cassandra Instances in a single JVM. It is done through > having distinct class loaders in order to work around the singleton problem > in Cassandra. In order to be able to pass some information between the nodes, > a common class loader is used that loads up java standard library and several > helper classes. Tests look a lot like CQLTester tests would usually look like. > Each Cassandra Instance, with its distinct class loader is using > serialisation and class loading mechanisms in order to run instance-local > queries and execute node state manipulation code, hooks, callbacks etc. > First version mocks out Messaging Service and simplifies schema management by > simply running schema change commands on each of the instances separately. > Internode communication is mocked by passing ByteBuffers through shared class > loader. > |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| -- 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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-11323:
---
Reviewers: Ariel Weisberg
Reviewer: Ariel Weisberg
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-11939:
---
Reviewers: Ariel Weisberg
Reviewer: Ariel Weisberg
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-2.2.txt, 11939-3.0.txt,
> 11939-3.0.txt, 11939-3.11.txt, 11939-3.11.txt, 11939-output.txt,
> 11939-trunk.txt, 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amanda R Debrot updated CASSANDRA-11939:
Attachment: 11939-2.2.txt
11939-3.0.txt
11939-3.11.txt
11939-trunk.txt
Status: Patch Available (was: Open)
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-2.2.txt, 11939-3.0.txt,
> 11939-3.0.txt, 11939-3.11.txt, 11939-3.11.txt, 11939-output.txt,
> 11939-trunk.txt, 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-13781) Cassandra 3.10 jvm.options default -XX:+UseNUMA may core OpenJDK on some aarch64 machines at os::Linux::libnuma_init()
[
https://issues.apache.org/jira/browse/CASSANDRA-13781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686702#comment-16686702
]
Marcus Eriksson commented on CASSANDRA-13781:
-
this seems to have been fixed in recent JDKs:
https://bugs.openjdk.java.net/browse/JDK-8198794 - [~bairyz] have you retried
this recently?
> Cassandra 3.10 jvm.options default -XX:+UseNUMA may core OpenJDK on some
> aarch64 machines at os::Linux::libnuma_init()
> --
>
> Key: CASSANDRA-13781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13781
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration
>Reporter: Yangzheng Bai
>Priority: Major
> Labels: easyfix
>
> We tried Oracle JDK, Linaro JDK, Zulu JDK and default OpenJDK, all of them
> cored at the same place: os::Linux::libnuma_init() ->
> os::Linux::rebuild_cpu_to_node_map()
> Removed -XX:+UseNUMA option solved the problem. Therefore we should remove
> -XX:+UseNUMA as an default option on aarch64 machines because x86_64 and
> aarch64 may have different implementations on how NUMA is reported. And
> -XX:+UseNUMA is currently not supporting G1GC anyway
> (https://bugs.openjdk.java.net/browse/JDK-8046147), adding it as default
> option may not have performance gain for future Java default G1GC.
> {noformat}
> root@1pqd-1:/usr/share/cassandra/lib# /usr/sbin/cassandra -R -f
> *** Error in `java': free(): invalid pointer: 0x800058c0 ***
> Aborted (core dumped)
> (gdb) bt
> #0 0x8719d528 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1 0x8719e9e0 in __GI_abort () at abort.c:89
> #2 0x871d48c4 in __libc_message (do_abort=do_abort@entry=2,
> fmt=fmt@entry=0x87285550 "*** Error in `%s': %s: 0x%s ***\n") at
> ../sysdeps/posix/libc_fatal.c:175
> #3 0x871da2ec in malloc_printerr (action=,
> str=0x87285720 "free(): invalid pointer",
> ptr=, ar_ptr=) at malloc.c:5006
> #4 0x871db088 in _int_free (av=0x872ad9a0 ,
> p=, have_lock=0) at malloc.c:3867
> #5 0x86dbccc4 in os::Linux::rebuild_cpu_to_node_map() ()
>from /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #6 0x86dbd048 in os::Linux::libnuma_init() () from
> /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #7 0x86dc34ac in os::init_2() () from
> /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #8 0x86f0f374 in Threads::create_vm(JavaVMInitArgs*, bool*) ()
>from /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #9 0x86bb7b80 in JNI_CreateJavaVM () from
> /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #10 0x872ba75c in InitializeJVM (ifn=,
> penv=0x86533a38, pvm=0x86533a30)
> at
> /home/buildslave/workspace/jdk8-build-release/BUILD_TYPE/release/JVM_VARIANT/server/label/aarch64-06/jdk8u-server-release-1704/jdk/src/share/bin/java.c:1215
> #11 JavaMain (_args=)
> at
> /home/buildslave/workspace/jdk8-build-release/BUILD_TYPE/release/JVM_VARIANT/server/label/aarch64-06/jdk8u-server-release-1704/jdk/src/share/bin/java.c:376
> #12 0x87133fc4 in start_thread (arg=0x872ba6d0 ) at
> pthread_create.c:335
> #13 0x87232290 in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:89
> {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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Onufriyev updated CASSANDRA-11323:
Status: Patch Available (was: Open)
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Onufriyev updated CASSANDRA-11323:
Attachment: 11323-2.2.txt
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
>Reporter: T Jake Luciani
>Priority: Trivial
> Labels: fallout
> Attachments: 11323-2.2.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amanda R Debrot updated CASSANDRA-11939:
Attachment: 11939-trunk.txt
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-3.0.txt, 11939-3.11.txt,
> 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686574#comment-16686574
]
Amanda R Debrot commented on CASSANDRA-11939:
-
Hi,
I took a look at this Jira and have attached the change for versions 2.2, 3.0,
3.11 and trunk. Please review and let me know if any there are any issues.
Thanks!
here is the output from these patches: [^11939-output.txt]
||2.2||3.0||3.11||trunk||
|[^11939-2.2.txt]|[^11939-3.0.txt]|[^11939-3.11.txt]|[^11939-trunk.txt]|
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-3.0.txt, 11939-3.11.txt,
> 11939-output.txt, 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amanda R Debrot updated CASSANDRA-11939:
Attachment: 11939-output.txt
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-3.0.txt, 11939-3.11.txt,
> 11939-output.txt, 11939-trunk.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-11939) Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
[
https://issues.apache.org/jira/browse/CASSANDRA-11939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amanda R Debrot updated CASSANDRA-11939:
Attachment: 11939-2.2.txt
11939-3.0.txt
11939-3.11.txt
> Read and Write Latency columns are swapped in proxyhistograms vs cfhistograms
> -
>
> Key: CASSANDRA-11939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11939
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: J.B. Langston
>Priority: Minor
> Labels: lhf
> Attachments: 11939-2.2.txt, 11939-3.0.txt, 11939-3.11.txt
>
>
> It’s triggering my ocd that read and write latency columns are swapped in
> proxyhistograms vs cfhistograms. I guess the argument against changing it now
> is that it could screw with some peoples scripts or expectations, but it does
> make it hard to eyeball when you’re trying to compare local latencies vs
> coordinator latencies.
> {code}
> Percentile SSTables Write Latency Read LatencyPartition Size
> Cell Count
> (micros) (micros) (bytes)
> 50% 4.00 17.00770.00 8239
> 4
> 75% 5.00 24.00924.00 17084
> 17
> 95% 5.00 35.00 61214.00 51012
> 24
> 98% 6.00 35.00 126934.00105778
> 24
> 99% 6.00 72.00 152321.00152321
> 35
> Min 0.00 9.00 36.0021
> 0
> Max 6.00 86.00 263210.00 20924300
> 1109
> Percentile Read Latency Write Latency Range Latency
> (micros) (micros) (micros)
> 50% 1331.00535.00 11864.00
> 75% 17084.00642.00 20501.00
> 95%219342.00 1331.00 20501.00
> 98%315852.00 2759.00 20501.00
> 99%379022.00 3311.00 20501.00
> Min 373.00 73.00 9888.00
> Max379022.00 9887.00 20501.00
> {code}
> Ideally read and write latencies should be in the same order and the first
> and second columns on both so they’re directly aligned. The sstables column
> should be moved to the 3rd column to make way.
--
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-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686337#comment-16686337
]
Marcus Eriksson commented on CASSANDRA-14806:
-
bq. Another option would probably to generate two versions of the config.yml
yeah that sounds better I think, let me know if you want me to do those final
changes
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
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-14869) Range.subtractContained produces incorrect results when used on full ring
[
https://issues.apache.org/jira/browse/CASSANDRA-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686251#comment-16686251
]
Alex Petrov commented on CASSANDRA-14869:
-
Did you run dtests results for this change across all branches?
> Range.subtractContained produces incorrect results when used on full ring
> -
>
> Key: CASSANDRA-14869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14869
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: range bug.jpg
>
>
> Currently {{Range.subtractContained}} returns incorrect results if minuend
> range covers full ring and:
> * subtrahend range wraps around. For example, {{(50, 50] - (10, 100]}}
> returns {{\{(50,10], (100,50]\}}} instead of {{(100,10]}}
> * subtrahend range covers the full ring as well. For example {{(50, 50] - (0,
> 0]}} returns {{\{(0,50], (50,0]\}}} instead of {{\{\}}}
--
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-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686236#comment-16686236 ] Benedict commented on CASSANDRA-14821: -- (y) ship it > Make it possible to run multi-node coordinator/replica tests in a single JVM > > > Key: CASSANDRA-14821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14821 > Project: Cassandra > Issue Type: Test >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > This patch proposes an in-JVM Distributed Tester that can help to write > distributed tests in a single JVM and be able to control node behaviour in a > fine-grained way and set up nodes exactly how one needs it: configuration > settings, parameters, which are also controllable in runtime on a per node > basis, so each node can have its own unique state. > It fires up multiple Cassandra Instances in a single JVM. It is done through > having distinct class loaders in order to work around the singleton problem > in Cassandra. In order to be able to pass some information between the nodes, > a common class loader is used that loads up java standard library and several > helper classes. Tests look a lot like CQLTester tests would usually look like. > Each Cassandra Instance, with its distinct class loader is using > serialisation and class loading mechanisms in order to run instance-local > queries and execute node state manipulation code, hooks, callbacks etc. > First version mocks out Messaging Service and simplifies schema management by > simply running schema change commands on each of the instances separately. > Internode communication is mocked by passing ByteBuffers through shared class > loader. > |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| -- 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-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686235#comment-16686235
]
Alex Petrov commented on CASSANDRA-14821:
-
Moved code to its own tree, now it's under {{test/distributed}}; added them to
circleci.
> Make it possible to run multi-node coordinator/replica tests in a single JVM
>
>
> Key: CASSANDRA-14821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14821
> Project: Cassandra
> Issue Type: Test
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Major
>
> This patch proposes an in-JVM Distributed Tester that can help to write
> distributed tests in a single JVM and be able to control node behaviour in a
> fine-grained way and set up nodes exactly how one needs it: configuration
> settings, parameters, which are also controllable in runtime on a per node
> basis, so each node can have its own unique state.
> It fires up multiple Cassandra Instances in a single JVM. It is done through
> having distinct class loaders in order to work around the singleton problem
> in Cassandra. In order to be able to pass some information between the nodes,
> a common class loader is used that loads up java standard library and several
> helper classes. Tests look a lot like CQLTester tests would usually look like.
> Each Cassandra Instance, with its distinct class loader is using
> serialisation and class loading mechanisms in order to run instance-local
> queries and execute node state manipulation code, hooks, callbacks etc.
> First version mocks out Messaging Service and simplifies schema management by
> simply running schema change commands on each of the instances separately.
> Internode communication is mocked by passing ByteBuffers through shared class
> loader.
> |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]|
--
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-14821) Make it possible to run multi-node coordinator/replica tests in a single JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-14821: Description: This patch proposes an in-JVM Distributed Tester that can help to write distributed tests in a single JVM and be able to control node behaviour in a fine-grained way and set up nodes exactly how one needs it: configuration settings, parameters, which are also controllable in runtime on a per node basis, so each node can have its own unique state. It fires up multiple Cassandra Instances in a single JVM. It is done through having distinct class loaders in order to work around the singleton problem in Cassandra. In order to be able to pass some information between the nodes, a common class loader is used that loads up java standard library and several helper classes. Tests look a lot like CQLTester tests would usually look like. Each Cassandra Instance, with its distinct class loader is using serialisation and class loading mechanisms in order to run instance-local queries and execute node state manipulation code, hooks, callbacks etc. First version mocks out Messaging Service and simplifies schema management by simply running schema change commands on each of the instances separately. Internode communication is mocked by passing ByteBuffers through shared class loader. |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| was: This patch proposes an in-JVM Distributed Tester that can help to write distributed tests in a single JVM and be able to control node behaviour in a fine-grained way and set up nodes exactly how one needs it: configuration settings, parameters, which are also controllable in runtime on a per node basis, so each node can have its own unique state. It fires up multiple Cassandra Instances in a single JVM. It is done through having distinct class loaders in order to work around the singleton problem in Cassandra. In order to be able to pass some information between the nodes, a common class loader is used that loads up java standard library and several helper classes. Tests look a lot like CQLTester tests would usually look like. Each Cassandra Instance, with its distinct class loader is using serialisation and class loading mechanisms in order to run instance-local queries and execute node state manipulation code, hooks, callbacks etc. First version mocks out Messaging Service and simplifies schema management by simply running schema change commands on each of the instances separately. Internode communication is mocked by passing ByteBuffers through shared class loader. |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/3d76-0b8e-40d6-83e0-867129747cc2]| > Make it possible to run multi-node coordinator/replica tests in a single JVM > > > Key: CASSANDRA-14821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14821 > Project: Cassandra > Issue Type: Test >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > This patch proposes an in-JVM Distributed Tester that can help to write > distributed tests in a single JVM and be able to control node behaviour in a > fine-grained way and set up nodes exactly how one needs it: configuration > settings, parameters, which are also controllable in runtime on a per node > basis, so each node can have its own unique state. > It fires up multiple Cassandra Instances in a single JVM. It is done through > having distinct class loaders in order to work around the singleton problem > in Cassandra. In order to be able to pass some information between the nodes, > a common class loader is used that loads up java standard library and several > helper classes. Tests look a lot like CQLTester tests would usually look like. > Each Cassandra Instance, with its distinct class loader is using > serialisation and class loading mechanisms in order to run instance-local > queries and execute node state manipulation code, hooks, callbacks etc. > First version mocks out Messaging Service and simplifies schema management by > simply running schema change commands on each of the instances separately. > Internode communication is mocked by passing ByteBuffers through shared class > loader. > |[patch|https://github.com/ifesdjeen/cassandra/tree/14821]|[tests|https://circleci.com/workflow-run/b371e72d-9dc8-455d-acb3-45cd8be1386b]| -- 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-14554) LifecycleTransaction encounters ConcurrentModificationException when used in multi-threaded context
[
https://issues.apache.org/jira/browse/CASSANDRA-14554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686209#comment-16686209
]
Benedict commented on CASSANDRA-14554:
--
{quote}If you are confident that child transactions are the best solution I'm
not opposed but the same can be achieved with a synchronized transaction and a
reference to the txn kept by the writers.
{quote}
Well, we've seen a few edge cases now where the synchronised version was
difficult to reason about and left problematic behaviours, and it might be more
brittle in future.
But if you're confident you can resolve the remaining issues through
synchronisation (and we can establish if trunk is (effectively) synchronised,
or should be), that has the advantage of already being (almost) done.
> LifecycleTransaction encounters ConcurrentModificationException when used in
> multi-threaded context
> ---
>
> Key: CASSANDRA-14554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14554
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Major
>
> When LifecycleTransaction is used in a multi-threaded context, we encounter
> this exception -
> {quote}java.util.ConcurrentModificationException: null
> at
> java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:742)
> at java.lang.Iterable.forEach(Iterable.java:74)
> at
> org.apache.cassandra.db.lifecycle.LogReplicaSet.maybeCreateReplica(LogReplicaSet.java:78)
> at org.apache.cassandra.db.lifecycle.LogFile.makeRecord(LogFile.java:320)
> at org.apache.cassandra.db.lifecycle.LogFile.add(LogFile.java:285)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.trackNew(LogTransaction.java:136)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.trackNew(LifecycleTransaction.java:529)
> {quote}
> During streaming we create a reference to a {{LifeCycleTransaction}} and
> share it between threads -
> [https://github.com/apache/cassandra/blob/5cc68a87359dd02412bdb70a52dfcd718d44a5ba/src/java/org/apache/cassandra/db/streaming/CassandraStreamReader.java#L156]
> This is used in a multi-threaded context inside {{CassandraIncomingFile}}
> which is an {{IncomingStreamMessage}}. This is being deserialized in parallel.
> {{LifecycleTransaction}} is not meant to be used in a multi-threaded context
> and this leads to streaming failures due to object sharing. On trunk, this
> object is shared across all threads that transfer sstables in parallel for
> the given {{TableId}} in a {{StreamSession}}. There are two options to solve
> this - make {{LifecycleTransaction}} and the associated objects thread safe,
> scope the transaction to a single {{CassandraIncomingFile}}. The consequences
> of the latter option is that if we experience streaming failure we may have
> redundant SSTables on disk. This is ok as compaction should clean this up. A
> third option is we synchronize access in the streaming infrastructure.
--
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
