[jira] [Updated] (CASSANDRA-13738) Load is over calculated after each IndexSummaryRedistribution
[
https://issues.apache.org/jira/browse/CASSANDRA-13738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-13738:
Description:
For example, here is one of our cluster with about 500GB per node, but
{{nodetool status}} shows far more load than it actually is and keeps
increasing, restarting the process will reset the load, but keeps increasing
afterwards:
{noformat}
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID
Rack
UN IP1* 13.52 TB 256 100.0%
c4c31e0a-3f01-49f7-8a22-33043737975d rac1
UN IP2* 14.25 TB 256 100.0%
efec4980-ec9e-4424-8a21-ce7ddaf80aa0 rac1
UN IP3* 13.52 TB 256 100.0%
7dbcfdfc-9c07-4b1a-a4b9-970b715ebed8 rac1
UN IP4* 22.13 TB 256 100.0%
8879e6c4-93e3-4cc5-b957-f999c6b9b563 rac1
UN IP5* 18.02 TB 256 100.0%
4a1eaf22-4a83-4736-9e1c-12f898d685fa rac1
UN IP6* 11.68 TB 256 100.0%
d633c591-28af-42cc-bc5e-47d1c8bcf50f rac1
{noformat}
!sizeIssue.png|test!
The root cause is if the SSTable index summary is redistributed (typically
executes hourly), the updated SSTable size is added again.
was:
For example, here is one of our cluster with about 500GB per node, but
{{nodetool status}} shows far more load than it actually is and keeps
increasing, restarting the process will reset the load, but keeps increasing
afterwards:
{noformat}
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID
Rack
UN IP1* 13.52 TB 256 100.0%
c4c31e0a-3f01-49f7-8a22-33043737975d rac1
UN IP2* 14.25 TB 256 100.0%
efec4980-ec9e-4424-8a21-ce7ddaf80aa0 rac1
UN IP3* 13.52 TB 256 100.0%
7dbcfdfc-9c07-4b1a-a4b9-970b715ebed8 rac1
UN IP4* 22.13 TB 256 100.0%
8879e6c4-93e3-4cc5-b957-f999c6b9b563 rac1
UN IP5* 18.02 TB 256 100.0%
4a1eaf22-4a83-4736-9e1c-12f898d685fa rac1
UN IP6* 11.68 TB 256 100.0%
d633c591-28af-42cc-bc5e-47d1c8bcf50f rac1
{noformat}
!sizeIssue.png|test!
The root cause is if the SSTable index summary is redistributed (typically
executes hourly), the updated SSTable size is added again.
> Load is over calculated after each IndexSummaryRedistribution
> -
>
> Key: CASSANDRA-13738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13738
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Normal
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0
>
> Attachments: sizeIssue.png
>
>
> For example, here is one of our cluster with about 500GB per node, but
> {{nodetool status}} shows far more load than it actually is and keeps
> increasing, restarting the process will reset the load, but keeps increasing
> afterwards:
> {noformat}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN IP1* 13.52 TB 256 100.0%
> c4c31e0a-3f01-49f7-8a22-33043737975d rac1
> UN IP2* 14.25 TB 256 100.0%
> efec4980-ec9e-4424-8a21-ce7ddaf80aa0 rac1
> UN IP3* 13.52 TB 256 100.0%
> 7dbcfdfc-9c07-4b1a-a4b9-970b715ebed8 rac1
> UN IP4* 22.13 TB 256 100.0%
> 8879e6c4-93e3-4cc5-b957-f999c6b9b563 rac1
> UN IP5* 18.02 TB 256 100.0%
> 4a1eaf22-4a83-4736-9e1c-12f898d685fa rac1
> UN IP6* 11.68 TB 256 100.0%
> d633c591-28af-42cc-bc5e-47d1c8bcf50f rac1
> {noformat}
> !sizeIssue.png|test!
> The root cause is if the SSTable index summary is redistributed (typically
> executes hourly), the updated SSTable size is added again.
--
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] [Comment Edited] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050751#comment-17050751 ] David Capwell edited comment on CASSANDRA-15564 at 3/4/20 3:52 AM: --- Since the feedback looks close I created a rebased branch [here|https://github.com/dcapwell/cassandra/commits/bug/repairCoordinatorJmxConsistency-rebase]. The branch has 2 commits: rebase against trunk, and fix regression caused by rebasing (conflict with CASSANDRA-15553) [Circle CI with LOWER config|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency-rebase] was (Author: dcapwell): Since the feedback looks close I created a rebased branch [here|https://github.com/dcapwell/cassandra/commits/bug/repairCoordinatorJmxConsistency-rebase]. The branch has 2 commits: rebase against trunk, fix regression caused by rebasing (conflict with CASSANDRA-15553) [Circle CI with LOWER config|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency-rebase] > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 11h 10m > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- 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] [Comment Edited] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050751#comment-17050751 ] David Capwell edited comment on CASSANDRA-15564 at 3/4/20 3:52 AM: --- Since the feedback looks close I created a rebased branch [here|https://github.com/dcapwell/cassandra/commits/bug/repairCoordinatorJmxConsistency-rebase]. The branch has 2 commits: rebase against trunk, fix regression caused by rebasing (conflict with CASSANDRA-15553) [Circle CI with LOWER config|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency-rebase] was (Author: dcapwell): Since the feedback looks close I created a rebased branch [here|https://github.com/dcapwell/cassandra/commits/bug/repairCoordinatorJmxConsistency-rebase] [Circle CI with LOWER config|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency-rebase] > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 11h 10m > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- 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-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050751#comment-17050751 ] David Capwell commented on CASSANDRA-15564: --- Since the feedback looks close I created a rebased branch [here|https://github.com/dcapwell/cassandra/commits/bug/repairCoordinatorJmxConsistency-rebase] [Circle CI with LOWER config|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency-rebase] > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 11h 10m > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- 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-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050748#comment-17050748 ] David Capwell commented on CASSANDRA-15564: --- bq. tryStoreParentRepairStart - the naming convention with methods like these would be maybeStoreParentRepairStart, try implies error handling, which isn't really applicable here matches org.apache.cassandra.utils.memory.BufferPool#tryGet (returns null) and org.apache.cassandra.io.sstable.SSTable#tryComponentFromFilename (returns null, but only if throws). Seems like we are not too consistent as a project but we should at least be for a sub-module; I see repair favors maybe (org.apache.cassandra.repair.consistent.LocalSessions#maybeSetRepairing); made the change. Pushed changed for most comments; [~bdeggleston] feedback applied [here|https://github.com/dcapwell/cassandra/commit/c24622240f8e827a77753daa3ec626afbd383c74] The only change not made was "response time" vs "service time" > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 11h 10m > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- 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] [Comment Edited] (CASSANDRA-15358) Cassandra alpha 4 testing - Nodes crashing due to bufferpool allocator issue
[
https://issues.apache.org/jira/browse/CASSANDRA-15358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050728#comment-17050728
]
David Capwell edited comment on CASSANDRA-15358 at 3/4/20 3:22 AM:
---
Sorry its been so long...
I put this under load several times without the patch and replicated with easy,
and with the patch I am no longer able to replicate. I want to do one more
test where I set the pool to be 0 or 1mb, just to see if I can flesh out any
more issues.
As far as I can tell the core change which appears to fix the issue is
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:15358#diff-613d97c28af63fff3cf1f52baa7f6caaR647];
we switch from heap buffers to direct buffers when out of space and
org.apache.cassandra.utils.memory.BufferPool.LocalPool#put(java.nio.ByteBuffer)
will just release right away.
General comments:
* +1 to removing ALLOCATE_ON_HEAP_WHEN_EXAHUSTED and DISABLED
* I don't think it makes sense to have the get methods take a BufferType, if
you write
{code}
get(42, BufferType.ON_HEAP) instanceOf HeapByteBuffer
{code}
you expect that to return true (it does) AND that its buffered (it is not). I
feel that every call to BufferPool with BufferType.ON_HEAP should instead just
allocate the ByteBuffer directly; I do know that ChunkCache relies on this
(figures out what type to do based off
org.apache.cassandra.io.util.ChunkReader#preferredBufferType) but I don't feel
it should in these cases. This is not a blocking comment and I am 100% fine if
a different JIRA addresses.
To be clear, I have not +1 because I want to test more, my goal is to sign off
this week
was (Author: dcapwell):
Sorry its been so long...
* +1 to removing ALLOCATE_ON_HEAP_WHEN_EXAHUSTED and DISABLED
* The core change which appears to fix the issue is
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:15358#diff-613d97c28af63fff3cf1f52baa7f6caaR647];
we switch from heap buffers to direct buffers and
org.apache.cassandra.utils.memory.BufferPool.LocalPool#put(java.nio.ByteBuffer)
will just release right away.
General comments:
1) I don't think it makes sense to have the get methods take a BufferType, if
you write
{code}
get(42, BufferType.ON_HEAP) instanceOf HeapByteBuffer
{code}
you expect that to return true (it does) AND that its buffered (it is not). I
feel that every call to BufferPool with BufferType.ON_HEAP should instead just
allocate the ByteBuffer directly.
The BufferType is my only real feedback. I put this under load several times
without the patch and replicated with easy, and with the patch I am no longer
able to replicate. I want to do one more test where I set the pool to be 0 or
1mb, just to see if I can flesh out any more issues.
> Cassandra alpha 4 testing - Nodes crashing due to bufferpool allocator issue
>
>
> Key: CASSANDRA-15358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15358
> Project: Cassandra
> Issue Type: Bug
> Components: Test/benchmark
>Reporter: Santhosh Kumar Ramalingam
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Labels: 4.0, alpha
> Fix For: 4.0, 4.0-beta
>
> Attachments: all_errors.txt, debug_logs_during_repair.txt,
> repair_1_trace.txt, verbose_logs.diff, verbose_logs.txt
>
>
> Hitting a bug with cassandra 4 alpha version. The same bug is repeated with
> difefrent version of Java(8,11 &12) [~benedict]
>
> Stack trace:
> {code:java}
> INFO [main] 2019-10-11 16:07:12,024 Server.java:164 - Starting listening for
> CQL clients on /1.3.0.6:9042 (unencrypted)...
> WARN [OptionalTasks:1] 2019-10-11 16:07:13,961 CassandraRoleManager.java:343
> - CassandraRoleManager skipped default role setup: some nodes were not ready
> INFO [OptionalTasks:1] 2019-10-11 16:07:13,961 CassandraRoleManager.java:369
> - Setup task failed with error, rescheduling
> WARN [Messaging-EventLoop-3-2] 2019-10-11 16:07:22,038 NoSpamLogger.java:94 -
> 10.3x.4x.5x:7000->1.3.0.5:7000-LARGE_MESSAGES-[no-channel] dropping message
> of type PING_REQ whose timeout expired before reaching the network
> WARN [OptionalTasks:1] 2019-10-11 16:07:23,963 CassandraRoleManager.java:343
> - CassandraRoleManager skipped default role setup: some nodes were not ready
> INFO [OptionalTasks:1] 2019-10-11 16:07:23,963 CassandraRoleManager.java:369
> - Setup task failed with error, rescheduling
> INFO [Messaging-EventLoop-3-6] 2019-10-11 16:07:32,759 NoSpamLogger.java:91 -
> 10.3x.4x.5x:7000->1.3.0.2:7000-URGENT_MESSAGES-[no-channel] failed to connect
> io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..)
> failed: Connection refused: /1.3.0.2:7000
> Caused by: java.net.ConnectException:
[jira] [Commented] (CASSANDRA-14258) document process of changing token count by adding a new DC
[ https://issues.apache.org/jira/browse/CASSANDRA-14258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050736#comment-17050736 ] Rahul Singh commented on CASSANDRA-14258: - [~TanakaRM] did you make any progress on this? Heres a suggested outline * Overview of Single vs. VNode * Overview of new DC approach to change token count ** Example from single to 8 vnodes ** Example from 256 to 16 vnodes > document process of changing token count by adding a new DC > --- > > Key: CASSANDRA-14258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14258 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Tanaka >Priority: Normal > > also provide warnings around not adding instances of different sizes to try > to migrate and why it's horrible. -- 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-15358) Cassandra alpha 4 testing - Nodes crashing due to bufferpool allocator issue
[
https://issues.apache.org/jira/browse/CASSANDRA-15358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050728#comment-17050728
]
David Capwell commented on CASSANDRA-15358:
---
Sorry its been so long...
* +1 to removing ALLOCATE_ON_HEAP_WHEN_EXAHUSTED and DISABLED
* The core change which appears to fix the issue is
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:15358#diff-613d97c28af63fff3cf1f52baa7f6caaR647];
we switch from heap buffers to direct buffers and
org.apache.cassandra.utils.memory.BufferPool.LocalPool#put(java.nio.ByteBuffer)
will just release right away.
General comments:
1) I don't think it makes sense to have the get methods take a BufferType, if
you write
{code}
get(42, BufferType.ON_HEAP) instanceOf HeapByteBuffer
{code}
you expect that to return true (it does) AND that its buffered (it is not). I
feel that every call to BufferPool with BufferType.ON_HEAP should instead just
allocate the ByteBuffer directly.
The BufferType is my only real feedback. I put this under load several times
without the patch and replicated with easy, and with the patch I am no longer
able to replicate. I want to do one more test where I set the pool to be 0 or
1mb, just to see if I can flesh out any more issues.
> Cassandra alpha 4 testing - Nodes crashing due to bufferpool allocator issue
>
>
> Key: CASSANDRA-15358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15358
> Project: Cassandra
> Issue Type: Bug
> Components: Test/benchmark
>Reporter: Santhosh Kumar Ramalingam
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Labels: 4.0, alpha
> Fix For: 4.0, 4.0-beta
>
> Attachments: all_errors.txt, debug_logs_during_repair.txt,
> repair_1_trace.txt, verbose_logs.diff, verbose_logs.txt
>
>
> Hitting a bug with cassandra 4 alpha version. The same bug is repeated with
> difefrent version of Java(8,11 &12) [~benedict]
>
> Stack trace:
> {code:java}
> INFO [main] 2019-10-11 16:07:12,024 Server.java:164 - Starting listening for
> CQL clients on /1.3.0.6:9042 (unencrypted)...
> WARN [OptionalTasks:1] 2019-10-11 16:07:13,961 CassandraRoleManager.java:343
> - CassandraRoleManager skipped default role setup: some nodes were not ready
> INFO [OptionalTasks:1] 2019-10-11 16:07:13,961 CassandraRoleManager.java:369
> - Setup task failed with error, rescheduling
> WARN [Messaging-EventLoop-3-2] 2019-10-11 16:07:22,038 NoSpamLogger.java:94 -
> 10.3x.4x.5x:7000->1.3.0.5:7000-LARGE_MESSAGES-[no-channel] dropping message
> of type PING_REQ whose timeout expired before reaching the network
> WARN [OptionalTasks:1] 2019-10-11 16:07:23,963 CassandraRoleManager.java:343
> - CassandraRoleManager skipped default role setup: some nodes were not ready
> INFO [OptionalTasks:1] 2019-10-11 16:07:23,963 CassandraRoleManager.java:369
> - Setup task failed with error, rescheduling
> INFO [Messaging-EventLoop-3-6] 2019-10-11 16:07:32,759 NoSpamLogger.java:91 -
> 10.3x.4x.5x:7000->1.3.0.2:7000-URGENT_MESSAGES-[no-channel] failed to connect
> io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..)
> failed: Connection refused: /1.3.0.2:7000
> Caused by: java.net.ConnectException: finishConnect(..) failed: Connection
> refused
> at io.netty.channel.unix.Errors.throwConnectException(Errors.java:124)
> at io.netty.channel.unix.Socket.finishConnect(Socket.java:243)
> at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.doFinishConnect(AbstractEpollChannel.java:667)
> at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.finishConnect(AbstractEpollChannel.java:644)
> at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.epollOutReady(AbstractEpollChannel.java:524)
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:414)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:326)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> WARN [Messaging-EventLoop-3-3] 2019-10-11 16:11:32,639 NoSpamLogger.java:94 -
> 1.3.4.6:7000->1.3.4.5:7000-URGENT_MESSAGES-[no-channel] dropping message of
> type GOSSIP_DIGEST_SYN whose timeout expired before reaching the network
> INFO [Messaging-EventLoop-3-18] 2019-10-11 16:11:33,077 NoSpamLogger.java:91
> - 1.3.4.5:7000->1.3.4.4:7000-URGENT_MESSAGES-[no-channel] failed to connect
>
> ERROR [Messaging-EventLoop-3-11] 2019-10-10 01:34:34,407
> InboundMessageHandler.java:657 -
>
[jira] [Commented] (CASSANDRA-15087) Find a place for the professional services page
[ https://issues.apache.org/jira/browse/CASSANDRA-15087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050725#comment-17050725 ] Rahul Singh commented on CASSANDRA-15087: - Outlining next actions * Double check to see if companies are still in business * Start with a simple page with a listing of company name, link to company, short description * Iterate with logos, social media links etc > Find a place for the professional services page > --- > > Key: CASSANDRA-15087 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15087 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > We've got a link to our old wiki on the Cassandra homepage for third party > support. We link to the old Wiki, which will eventually be sunset. We should > migrate this information to a page in the static site and link to it there. > > Current link : > [https://cwiki.apache.org/confluence/display/CASSANDRA2/ThirdPartySupport] -- 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-15306) Investigate why we are allocating 8MiB chunks and reaching the maximum BufferPool size
[
https://issues.apache.org/jira/browse/CASSANDRA-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050724#comment-17050724
]
David Capwell commented on CASSANDRA-15306:
---
Given the fact this is compaction this wold most likely be
org.apache.cassandra.cache.ChunkCache I think.
org.apache.cassandra.utils.memory.BufferPool.LocalPool#get will attempt to grow
until this limit is reached and then will avoid using the pool and rely on GC
to cleanup buffers, currently buffers are heap but CASSANDRA-15358 wants to
switch to direct (needed by netty).
To replicate you can set file_cache_size_in_mb to a very small value, say 0 or
1 (never tried with such a value so may see other issues); this pool is shared
between internode networking and check cache
> Investigate why we are allocating 8MiB chunks and reaching the maximum
> BufferPool size
> --
>
> Key: CASSANDRA-15306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15306
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging, Test/benchmark
>Reporter: Joey Lynch
>Priority: Normal
> Fix For: 4.0-beta
>
>
> While throwing some light traffic at {{4.0-alpha1}} I saw a lot of the
> following in the logs
> {noformat}
> INFO [CompactionExecutor:8] 2019-09-06 11:40:31,419 NoSpamLogger.java:91 -
> Maximum memory usage reached (512.000MiB), cannot allocate chunk of 8.000MiB
> INFO [CompactionExecutor:8] 2019-09-06 11:55:31,419 NoSpamLogger.java:91 -
> Maximum memory usage reached (512.000MiB), cannot allocate chunk of 8.000MiB
> INFO [CompactionExecutor:15] 2019-09-06 12:10:31,419 NoSpamLogger.java:91 -
> Maximum memory usage reached (512.000MiB), cannot allocate chunk of 8.000MiB
> INFO [CompactionExecutor:18] 2019-09-06 12:25:31,421 NoSpamLogger.java:91 -
> Maximum memory usage reached (512.000MiB), cannot allocate chunk of 8.000MiB
> {noformat}
> This was with about 150 WPS against a LCS table containing 4kib partitions.
> It seemed that compaction proceeded just fine but I don't remember seeing
> this in previous testing runs and I'd like to make sure it's not a bug
> (otherwise we may want to reduce the logging).
--
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-15087) Find a place for the professional services page
[ https://issues.apache.org/jira/browse/CASSANDRA-15087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Singh updated CASSANDRA-15087: Description: We've got a link to our old wiki on the Cassandra homepage for third party support. We link to the old Wiki, which will eventually be sunset. We should migrate this information to a page in the static site and link to it there. Current link : [https://cwiki.apache.org/confluence/display/CASSANDRA2/ThirdPartySupport] was:We've got a link to our old wiki on the Cassandra homepage for third party support. We link to the old Wiki, which will eventually be sunset. We should migrate this information to a page in the static site and link to it there. > Find a place for the professional services page > --- > > Key: CASSANDRA-15087 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15087 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > We've got a link to our old wiki on the Cassandra homepage for third party > support. We link to the old Wiki, which will eventually be sunset. We should > migrate this information to a page in the static site and link to it there. > > Current link : > [https://cwiki.apache.org/confluence/display/CASSANDRA2/ThirdPartySupport] -- 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] [Assigned] (CASSANDRA-15087) Find a place for the professional services page
[ https://issues.apache.org/jira/browse/CASSANDRA-15087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Singh reassigned CASSANDRA-15087: --- Assignee: Rahul Singh > Find a place for the professional services page > --- > > Key: CASSANDRA-15087 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15087 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > We've got a link to our old wiki on the Cassandra homepage for third party > support. We link to the old Wiki, which will eventually be sunset. We > should migrate this information to a page in the static site and link to it > there. -- 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-13960) update cassandra.yaml links to point to new docs instead of the wiki
[
https://issues.apache.org/jira/browse/CASSANDRA-13960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050723#comment-17050723
]
Rahul Singh commented on CASSANDRA-13960:
-
[~gnlima] how're you doing on this ?
Outling next actions
* Move relevant info if applicable from
** [http://wiki.apache.org/cassandra/StorageConfiguration]
**
[https://cwiki.apache.org/confluence/display/CASSANDRA2/StorageConfiguration]
** -[http://wiki.apache.org/cassandra/Operations]-
** -[http://wiki.apache.org/cassandra/HintedHandoff]-
** [https://cwiki.apache.org/confluence/display/CASSANDRA2/HintedHandoff]
* Replace cassandra.yaml references to new links
** [http://cassandra.apache.org/doc/latest/operating/index.html]
**
[http://cassandra.apache.org/doc/latest/operating/hints.html|http://cassandra.apache.org/doc/latest/operating/hints.html?highlight=storage]
**
[http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html]
> update cassandra.yaml links to point to new docs instead of the wiki
>
>
> Key: CASSANDRA-13960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13960
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Gabriel Nobrega
>Priority: Low
> Labels: lhf
>
> The wiki is dead, let's clean up the links and be sure we have the right into
> on cassandra.apache.org.
> {code}
> # NOTE:
> # See http://wiki.apache.org/cassandra/StorageConfiguration for
> # full explanations of configuration directives
> # /NOTE
> {code}
--
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-13823) The Getting Started page should have instructions on setting up a cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-13823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050719#comment-17050719 ] Rahul Singh commented on CASSANDRA-13823: - [~sumanth.pasupuleti] any progress on this ? One easy way to push a ticket forward is to make an outline as your next physical action. Here's a suggestion * Overview of Installation Methods ** Local using Binaries ** Local using CCM ** Local using VM ** Local using Containers ** > The Getting Started page should have instructions on setting up a cluster > - > > Key: CASSANDRA-13823 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13823 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: lhf > > Currently the docs don't have an easy to follow guide on setting up a > cluster. I think it would benefit from a nice easy to follow walkthrough. > https://cassandra.apache.org/doc/latest/getting_started/index.html -- This message was sent by Atlassian Jira (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-12584) document SASI functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-12584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050715#comment-17050715 ] Rahul Singh commented on CASSANDRA-12584: - This can be condensed to a few hundred words to start. * Overview ** Overview of SASI vs. Secondary Index ** Overview of different indexing options *** prefix *** suffix *** suffix_all_case *** contains *** sparse ** Overview of analyzers * Examples ** Wildcard ** LIKE ** stop words > document SASI functionality > --- > > Key: CASSANDRA-12584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12584 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > It doesn't look like SASI indexes are documented in tree. -- 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] [Assigned] (CASSANDRA-12584) document SASI functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-12584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Singh reassigned CASSANDRA-12584: --- Assignee: Rahul Singh > document SASI functionality > --- > > Key: CASSANDRA-12584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12584 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > It doesn't look like SASI indexes are documented in tree. -- 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-12692) document read path
[ https://issues.apache.org/jira/browse/CASSANDRA-12692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050703#comment-17050703 ] Rahul Singh commented on CASSANDRA-12692: - * Need to assemble a decent visual of the read path first * The text is mostly accurate but will need to make sure any changes since 3x are reflected. > document read path > -- > > Key: CASSANDRA-12692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12692 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > I'm not seeing any docs for the read path. We should port this over from the > wiki, assuming it's correct: > [-https://wiki.apache.org/cassandra/ReadPathForUsers-] > [https://cwiki.apache.org/confluence/display/CASSANDRA2/ReadPathForUsers] -- 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-12692) document read path
[ https://issues.apache.org/jira/browse/CASSANDRA-12692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Singh updated CASSANDRA-12692: Description: I'm not seeing any docs for the read path. We should port this over from the wiki, assuming it's correct: [-https://wiki.apache.org/cassandra/ReadPathForUsers-] [https://cwiki.apache.org/confluence/display/CASSANDRA2/ReadPathForUsers] was: I'm not seeing any docs for the read path. We should port this over from the wiki, assuming it's correct: https://wiki.apache.org/cassandra/ReadPathForUsers > document read path > -- > > Key: CASSANDRA-12692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12692 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > I'm not seeing any docs for the read path. We should port this over from the > wiki, assuming it's correct: > [-https://wiki.apache.org/cassandra/ReadPathForUsers-] > [https://cwiki.apache.org/confluence/display/CASSANDRA2/ReadPathForUsers] -- 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] [Assigned] (CASSANDRA-12692) document read path
[ https://issues.apache.org/jira/browse/CASSANDRA-12692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Singh reassigned CASSANDRA-12692: --- Assignee: Rahul Singh (was: Jon Haddad) > document read path > -- > > Key: CASSANDRA-12692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12692 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Rahul Singh >Priority: Low > > I'm not seeing any docs for the read path. We should port this over from the > wiki, assuming it's correct: > https://wiki.apache.org/cassandra/ReadPathForUsers -- 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-15481) Data Modeling
[ https://issues.apache.org/jira/browse/CASSANDRA-15481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050691#comment-17050691 ] DeepakVohra commented on CASSANDRA-15481: - Removed configuration file. > Data Modeling > - > > Key: CASSANDRA-15481 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15481 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > Fix For: 4.0 > > > Added a page on data modeling. > https://github.com/apache/cassandra/pull/410 -- 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-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050658#comment-17050658 ] David Capwell commented on CASSANDRA-15564: --- thanks for the feedback! Ill try to address everything tomorrow but there is one I want to address sooner. bq. setting creationTimeMillies in the ctor is going to change how repair times are reported in some cases, since there may be a significant delay between runnable creation and starting in some cases. It would be good to also report this, which I don't think we do Yes, this is now "response time" where as before it was "service time"; this is actually split in the parent JIRA and is more fine grain (each transition is stored separately and exposed, also know the last time "progress" was seen). bq. but we shouldn't combine them, since they can each reveal different problems. I agree they show different problems, I guess to me I see this as "who should view this KPI" which should be the users operating the cluster, and I "feel" "response time" is actually better. I would hate to change this, but it is a change in behavior that isn't fully needed in this patch (and the parent JIRA gives more fine grain detail anyway)... [~clohfink] thoughts here? Until CASSANDRA-15399 is in which would you prefer? > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 11h 10m > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- 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-15619) Counter tables should use a 4KB chunk length by default
[ https://issues.apache.org/jira/browse/CASSANDRA-15619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15619: --- Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Counter tables should use a 4KB chunk length by default > --- > > Key: CASSANDRA-15619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15619 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Counters >Reporter: Jon Haddad >Priority: Normal > > One of the issues I found when using counters is throughput gets > significantly limited due to the default chunk length. When tuning from 64 > to 4, I saw a massive improvement in both throughput and latency. > Our default chunk length is 16, which is fine for general purpose tables, but > since tables with counters are special purpose we should give users this > optimization automatically. -- 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] [Created] (CASSANDRA-15619) Counter tables should use a 4KB chunk length by default
Jon Haddad created CASSANDRA-15619: -- Summary: Counter tables should use a 4KB chunk length by default Key: CASSANDRA-15619 URL: https://issues.apache.org/jira/browse/CASSANDRA-15619 Project: Cassandra Issue Type: Improvement Components: Feature/Counters Reporter: Jon Haddad One of the issues I found when using counters is throughput gets significantly limited due to the default chunk length. When tuning from 64 to 4, I saw a massive improvement in both throughput and latency. Our default chunk length is 16, which is fine for general purpose tables, but since tables with counters are special purpose we should give users this optimization automatically. -- 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-15481) Data Modeling
[ https://issues.apache.org/jira/browse/CASSANDRA-15481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050657#comment-17050657 ] Jon Haddad commented on CASSANDRA-15481: Hey Deepak, I took a quick look and noticed it's got the config file commited in there, mind removing that? It's generated automatically and shouldn't be part of the patch. > Data Modeling > - > > Key: CASSANDRA-15481 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15481 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > Fix For: 4.0 > > > Added a page on data modeling. > https://github.com/apache/cassandra/pull/410 -- 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-15476) Transient Replication - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15476: --- Fix Version/s: 4.0-alpha Source Control Link: https://github.com/apache/cassandra/commit/9688d7d490ba6581c203c229b945cca5b7c657f4 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Transient Replication - New Feature > --- > > Key: CASSANDRA-15476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15476 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > Fix For: 4.0-alpha > > > Added a page on transient replication, a new feature. > https://github.com/apache/cassandra/pull/405 -- 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-15476) Transient Replication - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15476: --- Reviewers: Jon Haddad, Jon Haddad (was: Jon Haddad) Jon Haddad, Jon Haddad (was: Jon Haddad) Status: Review In Progress (was: Patch Available) > Transient Replication - New Feature > --- > > Key: CASSANDRA-15476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15476 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on transient replication, a new feature. > https://github.com/apache/cassandra/pull/405 -- 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
[cassandra] branch trunk updated: Added documentation for transient replication.
This is an automated email from the ASF dual-hosted git repository.
rustyrazorblade pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 9688d7d Added documentation for transient replication.
9688d7d is described below
commit 9688d7d490ba6581c203c229b945cca5b7c657f4
Author: dvohra
AuthorDate: Mon Jan 6 18:16:44 2020 -0800
Added documentation for transient replication.
Patch by dvohra; Reviewed by Jon Haddad for CASSANDRA-15476.
---
doc/source/_templates/indexcontent.html | 2 +-
doc/source/new/index.rst| 1 +
doc/source/new/transientreplication.rst | 155
3 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/doc/source/_templates/indexcontent.html
b/doc/source/_templates/indexcontent.html
index 7f7eede..5851258 100644
--- a/doc/source/_templates/indexcontent.html
+++ b/doc/source/_templates/indexcontent.html
@@ -1,6 +1,6 @@
{% extends "defindex.html" %}
{% block tables %}
-This documentation is currently a work-in-progress and
contains a number of TODO sections.
+This documentation is a work-in-progress.
Contributions are welcome.
Main documentation
diff --git a/doc/source/new/index.rst b/doc/source/new/index.rst
index c88120d..5ef867b 100644
--- a/doc/source/new/index.rst
+++ b/doc/source/new/index.rst
@@ -28,4 +28,5 @@ This section covers the new features in Apache Cassandra 4.0.
fqllogging
messaging
streaming
+ transientreplication
diff --git a/doc/source/new/transientreplication.rst
b/doc/source/new/transientreplication.rst
new file mode 100644
index 000..438f437
--- /dev/null
+++ b/doc/source/new/transientreplication.rst
@@ -0,0 +1,155 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+.. or more contributor license agreements. See the NOTICE file
+.. distributed with this work for additional information
+.. regarding copyright ownership. The ASF licenses this file
+.. to you under the Apache License, Version 2.0 (the
+.. "License"); you may not use this file except in compliance
+.. with the License. You may obtain a copy of the License at
+..
+.. http://www.apache.org/licenses/LICENSE-2.0
+..
+.. Unless required by applicable law or agreed to in writing, software
+.. distributed under the License is distributed on an "AS IS" BASIS,
+.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+.. See the License for the specific language governing permissions and
+.. limitations under the License.
+
+Transient Replication
+-
+
+**Note**:
+
+Transient Replication (`CASSANDRA-14404
+`_) is an experimental
feature designed for expert Apache Cassandra users who are able to validate
every aspect of the database for their application and deployment.
+That means being able to check that operations like reads, writes,
decommission, remove, rebuild, repair, and replace all work with your queries,
data, configuration, operational practices, and availability requirements.
+Apache Cassandra 4.0 has the initial implementation of transient replication.
Future releases of Cassandra will make this feature suitable for a wider
audience.
+It is anticipated that a future version will support monotonic reads with
transient replication as well as LWT, logged batches, and counters. Being
experimental, Transient replication is **not** recommended for production use.
+
+Objective
+^
+
+The objective of transient replication is to decouple storage requirements
from data redundancy (or consensus group size) using incremental repair, in
order to reduce storage overhead.
+Certain nodes act as full replicas (storing all the data for a given token
range), and some nodes act as transient replicas, storing only unrepaired data
for the same token ranges.
+
+The optimization that is made possible with transient replication is called
"Cheap quorums", which implies that data redundancy is increased without
corresponding increase in storage usage.
+
+Transient replication is useful when sufficient full replicas are unavailable
to receive and store all the data.
+Transient replication allows you to configure a subset of replicas to only
replicate data that hasn't been incrementally repaired.
+As an optimization, we can avoid writing data to a transient replica if we
have successfully written data to the full replicas.
+
+After incremental repair, transient data stored on transient replicas can be
discarded.
+
+Enabling Transient Replication
+^^
+
+Transient replication is not enabled by default. Transient replication must
be enabled on each node in a cluster separately by setting the following
configuration property in ``cassandra.yaml``.
+
+::
+
+ enable_transient_replication: true
+
+Transient replication may be configured with
[jira] [Updated] (CASSANDRA-15476) Transient Replication - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15476: --- Status: Ready to Commit (was: Review In Progress) > Transient Replication - New Feature > --- > > Key: CASSANDRA-15476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15476 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on transient replication, a new feature. > https://github.com/apache/cassandra/pull/405 -- 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-15610) Upgrade Sidecar Gradle Dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-15610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15610: --- Fix Version/s: 4.0-alpha Source Control Link: https://github.com/apache/cassandra-sidecar/commit/29317751434cd1b3a129fd4e44628b28c421c6bd Resolution: Fixed Status: Resolved (was: Ready to Commit) > Upgrade Sidecar Gradle Dependencies > --- > > Key: CASSANDRA-15610 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15610 > Project: Cassandra > Issue Type: Improvement > Components: Sidecar >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > There's a few out of date dependencies in the Gradle config, some of which > are hindering us from fully supporting Java 11. > * Gradle can be upgraded to 6.2 > * Findbugs is abandoned and is Java 8 only, spotbugs is the supported > replacement > * Old guava transitive dependency from the Java Driver (out of scope for now, > will create follow up) > * Java driver is 3.6, 3.8 is more current (out of scope for now, will create > follow up) > There's probably more to do but this is a quick starting point. -- 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
[cassandra-sidecar] branch master updated: Upgraded gradle and replaced FindBugs with SpotBugs.
This is an automated email from the ASF dual-hosted git repository.
rustyrazorblade pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-sidecar.git
The following commit(s) were added to refs/heads/master by this push:
new 2931775 Upgraded gradle and replaced FindBugs with SpotBugs.
2931775 is described below
commit 29317751434cd1b3a129fd4e44628b28c421c6bd
Author: Jon Haddad
AuthorDate: Tue Mar 3 15:24:50 2020 -0800
Upgraded gradle and replaced FindBugs with SpotBugs.
* Upgrading from findbugs (JDK 8 only) to Spotbugs. FindBugs was abandoned
years ago and will not be updated.
* Upgraded Gradle to version 6.2.1
Patch by Jon Haddad; Reviewed by Dinesh Joshi for CASSANDRA-15610.
---
CHANGES.txt | 1 +
build.gradle | 24 ++--
gradle/wrapper/gradle-wrapper.properties | 2 +-
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index d08bc9e..49d7800 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
1.0.0
-
+ * Upgraded Gradle and replaced FindBugs with SpotBugs (CASSANDRA-15610)
* Improving local HealthCheckTest reliability (CASSANDRA-15615)
* Read sidecar.yaml from sidecar.config System Property instead of classpath
(CASSANDRA-15288)
* Add integration tests task (CASSANDRA-15031)
diff --git a/build.gradle b/build.gradle
index 947a6bd..3d362e8 100644
--- a/build.gradle
+++ b/build.gradle
@@ -1,10 +1,19 @@
+
+buildscript {
+dependencies {
+// findBugs needs a newer version of Guava in the buildscript.
+// otherwise it throws an exception
+classpath "com.google.guava:guava:28.2-jre"
+}
+}
+
plugins {
id 'java'
id 'application'
id 'idea'
id 'checkstyle'
id 'jacoco'
-id 'findbugs'
+id "com.github.spotbugs" version "3.0.0"
id 'org.hidetake.swagger.generator' version '2.16.0'
}
@@ -73,6 +82,7 @@ dependencies {
compile 'org.slf4j:slf4j-api:1.7.25'
compile 'ch.qos.logback:logback-core:1.2.3'
compile 'ch.qos.logback:logback-classic:1.2.3'
+
compile 'com.datastax.cassandra:cassandra-driver-core:3.6+'
compile group: 'com.google.inject', name: 'guice', version: '4.2.2'
compile group: 'org.apache.commons', name: 'commons-configuration2',
version: '2.4'
@@ -153,11 +163,13 @@ checkstyle {
configFile file("checkstyle.xml")
}
-tasks.withType(FindBugs) {
-reports {
-xml.enabled false
-html.enabled true
-}
+spotbugs {
+toolVersion = '4.0.0'
+}
+
+tasks.withType(com.github.spotbugs.SpotBugsTask) {
+reports.xml.enabled = false
+reports.html.enabled = true
}
// copyDist gets called on every build
diff --git a/gradle/wrapper/gradle-wrapper.properties
b/gradle/wrapper/gradle-wrapper.properties
index 44e7c4d..4a6ebce 100644
--- a/gradle/wrapper/gradle-wrapper.properties
+++ b/gradle/wrapper/gradle-wrapper.properties
@@ -1,5 +1,5 @@
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-5.2.1-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-6.2.1-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050629#comment-17050629
]
Blake Eggleston commented on CASSANDRA-15564:
-
This is almost there, and shaping up nicely. It's nice to see some attention
being paid to organizing RepairRunnable.
All my remaining feedback is for RepairRunnable, and is almost all minor:
* I think {{unsafeRun}} could be folded into run. If you'd like to keep it
separate, maybe rename it to runMayThrow or something? unsafe* usually implies
we're making some internal function visible for testing.
* {{getColumnFamilies}} can use guava's {{Lists.newArrayList(Iterable i)}}
instead of manually creating the list.
* {{maybeCreateTraceState}}, totally stylistic and up to you, but I personally
like to omit braces for short "if then bail out" type blocks like the one here
and in {{getColumnFamilies}}. Four lines seems like a bit much for simple
things like that, but again, totally up to you.
* {{populateNeighborsAndRanges}}
** the indentation needs to be fixed on line 390
** could this be folded into getNeighborsAndRanges? It doesn't seem like it
needs it's own methods.
* {{tryStoreParentRepairStart}} - the naming convention with methods like
these would be {{maybeStoreParentRepairStart}}, try implies error handling,
which isn't really applicable here
* {{repair}} you can just pass the NeighborsAndRanges object in here
* setting {{creationTimeMillies}} in the ctor is going to change how repair
times are reported in some cases, since there may be a significant delay
between runnable creation and starting in some cases. It would be good to
_also_ report this, which I don't think we do, but we shouldn't combine them,
since they can each reveal different problems.
> Refactor repair coordinator so errors are consistent
>
>
> Key: CASSANDRA-15564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15564
> Project: Cassandra
> Issue Type: Sub-task
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 11h 10m
> Remaining Estimate: 0h
>
> This is to split the change in CASSANDRA-15399 so the refactor is isolated
> out.
> Currently the repair coordinator special cases the exit cases at each call
> site; this makes it so that errors can be inconsistent and there are cases
> where proper complete isn't done (proper notifications, and forgetting to
> update ActiveRepairService).
> [Circle
> CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency]
--
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-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15273: --- Fix Version/s: (was: 3.11.x) (was: 4.x) (was: 3.0.x) (was: 2.2.x) 4.0-alpha 3.11.7 3.0.21 2.2.17 Since Version: 0.8 beta 1 Source Control Link: https://github.com/apache/cassandra/commit/9105dcd99e61537e8d177b41b7d38c5569412230 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as 9105dcd99e61537e8d177b41b7d38c5569412230 > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Aleksandr Yatskin >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > Attachments: > 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch > > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- 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
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1900510a72670edec295505c5d8bc18b6cd52afd Merge: ef7e171 d9b38a1 Author: Mick Semb Wever AuthorDate: Tue Mar 3 22:46:49 2020 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 CHANGES.txt | 1 + redhat/cassandra | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --cc CHANGES.txt index 7224b24,77b9fdf..967675f --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,17 -1,10 +1,18 @@@ -3.0.21 +3.11.7 +Merged from 3.0: * Run evictFromMembership in GossipStage (CASSANDRA-15592) Merged from 2.2: + * Fix Red Hat init script on newer systemd versions (CASSANDRA-15273) * Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567) -3.0.20 + +3.11.6 + * Fix bad UDT sstable metadata serialization headers written by C* 3.0 on upgrade and in sstablescrub (CASSANDRA-15035) + * Fix nodetool compactionstats showing extra pending task for TWCS - patch implemented (CASSANDRA-15409) + * Fix SELECT JSON formatting for the "duration" type (CASSANDRA-15075) + * Fix LegacyLayout to have same behavior as 2.x when handling unknown column names (CASSANDRA-15081) + * Update nodetool help stop output (CASSANDRA-15401) +Merged from 3.0: * Run in-jvm upgrade dtests in circleci (CASSANDRA-15506) * Include updates to static column in mutation size calculations (CASSANDRA-15293) * Fix point-in-time recoevery ignoring timestamp of updates to static columns (CASSANDRA-15292) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 959d6daa99377f7b6973f168c6e2dfeacc399efd Merge: abeaa3e 1900510 Author: Mick Semb Wever AuthorDate: Tue Mar 3 22:49:10 2020 +0100 Merge branch 'cassandra-3.11' into trunk CHANGES.txt | 5 +++-- redhat/cassandra | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --cc CHANGES.txt index 0bc3317,967675f..072b7c3 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,69 -1,12 +1,70 @@@ -3.11.7 +4.0-alpha4 + * Improve the algorithmic token allocation in case racks = RF (CASSANDRA-15600) + * Fix ConnectionTest.testAcquireReleaseOutbound (CASSANDRA-15308) + * Include finalized pending sstables in preview repair (CASSANDRA-15553) + * Reverted to the original behavior of CLUSTERING ORDER on CREATE TABLE (CASSANDRA-15271) + * Correct inaccurate logging message (CASSANDRA-15549) + * Add documentation of dynamo (CASSANDRA-15486) + * Added documentation for Guarantees (CASSANDRA-15482) + * Added documentation for audit logging (CASSANDRA-15474) + * Unset GREP_OPTIONS (CASSANDRA-14487) + * Added streaming documentation (CASSANDRA-15477) + * Update to Python driver 3.21 for cqlsh (CASSANDRA-14872) + * Added bulk loading documentation (CASSANDRA-15480) + * Updated overview documentation (CASSANDRA-15483) + * Added CDC and speculative retry documentation to DDL section (CASSANDRA-15492) + * Fix missing Keyspaces in cqlsh describe output (CASSANDRA-15576) + * Fix multi DC nodetool status output (CASSANDRA-15305) + * Added documentation covering new Netty based internode messaging (CASSANDRA-15478) + * Add documentation of hints (CASSANDRA-15491) + * updateCoordinatorWriteLatencyTableMetric can produce misleading metrics (CASSANDRA-15569) + * Added documentation for read repair and an example of full repair (CASSANDRA-15485) + * Make cqlsh and cqlshlib Python 2 & 3 compatible (CASSANDRA-10190) + * Added documentation for Full Query Logging (CASSANDRA-15475) + * Added documentation for backups (CASSANDRA-15479) + * Documentation gives the wrong instruction to activate remote jmx (CASSANDRA-15535) + * Improve the description of nodetool listsnapshots command (CASSANDRA-14587) + * allow embedded cassandra launched from a one-jar or uno-jar (CASSANDRA-15494) + * Update hppc library to version 0.8.1 (CASSANDRA-12995) + * Limit the dependencies used by UDFs/UDAs (CASSANDRA-14737) + * Make native_transport_max_concurrent_requests_in_bytes updatable (CASSANDRA-15519) + * Cleanup and improvements to IndexInfo/ColumnIndex (CASSANDRA-15469) + * Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes (CASSANDRA-15470) Merged from 3.0: - * Run evictFromMembership in GossipStage (CASSANDRA-15592) + * Run evictFromMembership in GossipStage (CASSANDRA-15592) Merged from 2.2: - * Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567) + * Fix Red Hat init script on newer systemd versions (CASSANDRA-15273) + * Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567) - -3.11.6 +4.0-alpha3 + * Restore monotonic read consistency guarantees for blocking read repair (CASSANDRA-14740) + * Separate exceptions for CAS write timeout exceptions caused by contention and unkown result (CASSANDRA-15350) + * Fix in-jvm dtest java 11 compatibility (CASSANDRA-15463) + * Remove joda time dependency (CASSANDRA-15257) + * Exclude purgeable tombstones from repaired data tracking (CASSANDRA-15462) + * Exclude legacy counter shards from repaired data tracking (CASSANDRA-15461) + * Make it easier to add trace headers to messages (CASSANDRA-15499) + * Fix and optimise partial compressed sstable streaming (CASSANDRA-13938) + * Improve error when JVM 11 can't access required modules (CASSANDRA-15468) + * Better handling of file deletion failures by DiskFailurePolicy (CASSANDRA-15143) + * Prevent read repair mutations from increasing read timeout (CASSANDRA-15442) + * Document 4.0 system keyspace changes, bump generations (CASSANDRA-15454) + * Make it possible to disable STCS-in-L0 during runtime (CASSANDRA-15445) + * Removed obsolete OldNetworkTopologyStrategy (CASSANDRA-13990) + * Align record header of FQL and audit binary log (CASSANDRA-15076) + * Shuffle forwarding replica for messages to non-local DC (CASSANDRA-15318) + * Optimise native protocol ASCII string encoding (CASSANDRA-15410) + * Make sure all exceptions are propagated in DebuggableThreadPoolExecutor (CASSANDRA-15332) + * Make it possible to resize concurrent read / write thread pools at runtime (CASSANDRA-15277) + * Close channels on error (CASSANDRA-15407) + * Add documentation for Java 11 support in Cassandra (CASSANDRA-15428) + * Integrate SJK into nodetool (CASSANDRA-12197) + * Ensure that empty clusterings with kind==CLUSTERING are Clustering.EMPTY
[cassandra] branch trunk updated (abeaa3e -> 959d6da)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from abeaa3e Fix ConnectionTest.testAcquireReleaseOutbound new 9105dcd Fix Red Hat init script on newer systemd versions new d9b38a1 Merge branch 'cassandra-2.2' into cassandra-3.0 new 1900510 Merge branch 'cassandra-3.0' into cassandra-3.11 new 959d6da Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 5 +++-- redhat/cassandra | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (ef7e171 -> 1900510)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ef7e171 Fix CHANGES merged from notes new 9105dcd Fix Red Hat init script on newer systemd versions new d9b38a1 Merge branch 'cassandra-2.2' into cassandra-3.0 new 1900510 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + redhat/cassandra | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Fix Red Hat init script on newer systemd versions
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-2.2 by this push: new 9105dcd Fix Red Hat init script on newer systemd versions 9105dcd is described below commit 9105dcd99e61537e8d177b41b7d38c5569412230 Author: Mick Semb Wever AuthorDate: Tue Mar 3 11:37:04 2020 +0100 Fix Red Hat init script on newer systemd versions The fix for systemd CVE-2018-16888 required changes to init scripts, so that PID files end up owned by the "root" user. patch by Mike Kelly; reviewed by Mick Semb Wever for CASSANDRA-15273 --- CHANGES.txt | 1 + redhat/cassandra | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 9ecfcb4..44b4abe 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2.17 + * Fix Red Hat init script on newer systemd versions (CASSANDRA-15273) * Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567) 2.2.16 diff --git a/redhat/cassandra b/redhat/cassandra index 677ff8c..97a0447 100644 --- a/redhat/cassandra +++ b/redhat/cassandra @@ -69,15 +69,16 @@ case "$1" in echo -n "Starting Cassandra: " [ -d `dirname "$pid_file"` ] || \ install -m 755 -o $CASSANDRA_OWNR -g $CASSANDRA_OWNR -d `dirname $pid_file` -su $CASSANDRA_OWNR -c "$CASSANDRA_PROG -p $pid_file" > $log_file 2>&1 +runuser -u $CASSANDRA_OWNR -- $CASSANDRA_PROG -p $pid_file > $log_file 2>&1 retval=$? +chown root.root $pid_file [ $retval -eq 0 ] && touch $lock_file echo "OK" ;; stop) # Cassandra shutdown echo -n "Shutdown Cassandra: " -su $CASSANDRA_OWNR -c "kill `cat $pid_file`" +runuser -u $CASSANDRA_OWNR -- kill `cat $pid_file` retval=$? [ $retval -eq 0 ] && rm -f $lock_file for t in `seq 40`; do - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (e37f77d -> d9b38a1)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e37f77d Fix CHANGES merged from notes new 9105dcd Fix Red Hat init script on newer systemd versions new d9b38a1 Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + redhat/cassandra | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d9b38a1f0d04a36877e8e23f2ba8a6acef0c5691 Merge: e37f77d 9105dcd Author: Mick Semb Wever AuthorDate: Tue Mar 3 22:44:07 2020 +0100 Merge branch 'cassandra-2.2' into cassandra-3.0 CHANGES.txt | 1 + redhat/cassandra | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --cc CHANGES.txt index 9adc461,44b4abe..77b9fdf --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,67 -1,16 +1,68 @@@ -2.2.17 +3.0.21 + * Run evictFromMembership in GossipStage (CASSANDRA-15592) +Merged from 2.2: + * Fix Red Hat init script on newer systemd versions (CASSANDRA-15273) * Allow EXTRA_CLASSPATH to work on tar/source installations (CASSANDRA-15567) -2.2.16 +3.0.20 + * Run in-jvm upgrade dtests in circleci (CASSANDRA-15506) + * Include updates to static column in mutation size calculations (CASSANDRA-15293) + * Fix point-in-time recoevery ignoring timestamp of updates to static columns (CASSANDRA-15292) + * GC logs are also put under $CASSANDRA_LOG_DIR (CASSANDRA-14306) + * Fix sstabledump's position key value when partitions have multiple rows (CASSANDRA-14721) + * Avoid over-scanning data directories in LogFile.verify() (CASSANDRA-15364) + * Bump generations and document changes to system_distributed and system_traces in 3.0, 3.11 + (CASSANDRA-15441) + * Fix system_traces creation timestamp; optimise system keyspace upgrades (CASSANDRA-15398) + * Fix various data directory prefix matching issues (CASSANDRA-13974) + * Minimize clustering values in metadata collector (CASSANDRA-15400) + * Avoid over-trimming of results in mixed mode clusters (CASSANDRA-15405) + * validate value sizes in LegacyLayout (CASSANDRA-15373) + * Ensure that tracing doesn't break connections in 3.x/4.0 mixed mode by default (CASSANDRA-15385) + * Make sure index summary redistribution does not start when compactions are paused (CASSANDRA-15265) + * Ensure legacy rows have primary key livenessinfo when they contain illegal cells (CASSANDRA-15365) + * Fix race condition when setting bootstrap flags (CASSANDRA-14878) + * Fix NativeLibrary.tryOpenDirectory callers for Windows (CASSANDRA-15426) +Merged from 2.2: * Fix SELECT JSON output for empty blobs (CASSANDRA-15435) * In-JVM DTest: Set correct internode message version for upgrade test (CASSANDRA-15371) - * In-JVM DTest: Support NodeTool in dtest + * In-JVM DTest: Support NodeTool in dtest (CASSANDRA-15429) -2.2.15 +3.0.19 + * Add ability to cap max negotiable protocol version (CASSANDRA-15193) + * Gossip tokens on startup if available (CASSANDRA-15335) + * Fix resource leak in CompressedSequentialWriter (CASSANDRA-15340) + * Fix merge which reverted CASSANDRA-14993 (CASSANDRA-15289) + * Fix LegacyLayout RangeTombstoneList IndexOutOfBoundsException when upgrading and RangeTombstone bounds are asymmetric (CASSANDRA-15172) + * Fix NPE when using allocate_tokens_for_keyspace on new DC/rack (CASSANDRA-14952) + * Filter sstables earlier when running cleanup (CASSANDRA-15100) + * Use mean row count instead of mean column count for index selectivity calculation (CASSANDRA-15259) + * Avoid updating unchanged gossip states (CASSANDRA-15097) + * Prevent recreation of previously dropped columns with a different kind (CASSANDRA-14948) + * Prevent client requests from blocking on executor task queue (CASSANDRA-15013) + * Toughen up column drop/recreate type validations (CASSANDRA-15204) + * LegacyLayout should handle paging states that cross a collection column (CASSANDRA-15201) + * Prevent RuntimeException when username or password is empty/null (CASSANDRA-15198) + * Multiget thrift query returns null records after digest mismatch (CASSANDRA-14812) + * Skipping illegal legacy cells can break reverse iteration of indexed partitions (CASSANDRA-15178) + * Handle paging states serialized with a different version than the session's (CASSANDRA-15176) + * Throw IOE instead of asserting on unsupporter peer versions (CASSANDRA-15066) + * Update token metadata when handling MOVING/REMOVING_TOKEN events (CASSANDRA-15120) + * Add ability to customize cassandra log directory using $CASSANDRA_LOG_DIR (CASSANDRA-15090) + * Skip cells with illegal column names when reading legacy sstables (CASSANDRA-15086) + * Fix assorted gossip races and add related runtime checks (CASSANDRA-15059) + * Fix mixed mode partition range scans with limit (CASSANDRA-15072) + * cassandra-stress works with frozen collections: list and set (CASSANDRA-14907) + * For nodetool listsnapshots output, put spaces between columns, and increase snapshot padding (CASSANDRA-14876) + * Fix handling FS errors on writing and reading flat files - LogTransaction and hints (CASSANDRA-15053) + * Avoid double closing the iterator to avoid overcounting the number of requests
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050544#comment-17050544
]
Michael Semb Wever edited comment on CASSANDRA-15234 at 3/3/20 9:27 PM:
And there are a lot of accessing jvm args using the "cassandra." string literal
prefix, instead of {{Config.PROPERTY_PREFIX}}
And, this ticket would help simplify
{{SystemPropertiesTable.CASSANDRA_RELEVANT_PROPERTIES}} in CASSANDRA-15616
was (Author: michaelsembwever):
And there are a lot of accessing jvm args using the "cassandra." string literal
prefix, instead of {{Config.PROPERTY_PREFIX}}
And, this ticket would help simplify {{SystemPropertiesTable.
CASSANDRA_RELEVANT_PROPERTIES}} in CASSANDRA-15616
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15234:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: Local/Config
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15610) Upgrade Sidecar Gradle Dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-15610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050577#comment-17050577 ] Dinesh Joshi commented on CASSANDRA-15610: -- +1 LGTM. > Upgrade Sidecar Gradle Dependencies > --- > > Key: CASSANDRA-15610 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15610 > Project: Cassandra > Issue Type: Improvement > Components: Sidecar >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There's a few out of date dependencies in the Gradle config, some of which > are hindering us from fully supporting Java 11. > * Gradle can be upgraded to 6.2 > * Findbugs is abandoned and is Java 8 only, spotbugs is the supported > replacement > * Old guava transitive dependency from the Java Driver (out of scope for now, > will create follow up) > * Java driver is 3.6, 3.8 is more current (out of scope for now, will create > follow up) > There's probably more to do but this is a quick starting point. -- 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-15610) Upgrade Sidecar Gradle Dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-15610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15610: - Status: Ready to Commit (was: Review In Progress) > Upgrade Sidecar Gradle Dependencies > --- > > Key: CASSANDRA-15610 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15610 > Project: Cassandra > Issue Type: Improvement > Components: Sidecar >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There's a few out of date dependencies in the Gradle config, some of which > are hindering us from fully supporting Java 11. > * Gradle can be upgraded to 6.2 > * Findbugs is abandoned and is Java 8 only, spotbugs is the supported > replacement > * Old guava transitive dependency from the Java Driver (out of scope for now, > will create follow up) > * Java driver is 3.6, 3.8 is more current (out of scope for now, will create > follow up) > There's probably more to do but this is a quick starting point. -- 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-15610) Upgrade Sidecar Gradle Dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-15610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15610: - Reviewers: Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi) Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi) Status: Review In Progress (was: Patch Available) > Upgrade Sidecar Gradle Dependencies > --- > > Key: CASSANDRA-15610 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15610 > Project: Cassandra > Issue Type: Improvement > Components: Sidecar >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There's a few out of date dependencies in the Gradle config, some of which > are hindering us from fully supporting Java 11. > * Gradle can be upgraded to 6.2 > * Findbugs is abandoned and is Java 8 only, spotbugs is the supported > replacement > * Old guava transitive dependency from the Java Driver (out of scope for now, > will create follow up) > * Java driver is 3.6, 3.8 is more current (out of scope for now, will create > follow up) > There's probably more to do but this is a quick starting point. -- 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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050573#comment-17050573
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Great, then I am gonna start working on it tomorrow!
Probably will ask some questions at some point.
Thanks!
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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] [Assigned] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-15234:
---
Assignee: Ekaterina Dimitrova
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 9:13 PM:
||branch||circleci||
|[cassandra_2.2_15273|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/cassandra-2.2_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-2.2_15273]|
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
rm /etc/security/limits.d/cassandra.conf # this should be fixed
/etc/init.d/cassandra start
tail -F /var/log/cassandra/system.log
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
rm /etc/security/limits.d/cassandra.conf # this should be fixed
/etc/init.d/cassandra start
tail -F /var/log/cassandra/system.log
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>
[jira] [Commented] (CASSANDRA-15616) Expose Cassandra related system properties in a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050560#comment-17050560
]
Michael Semb Wever commented on CASSANDRA-15616:
Added two missing properties to
{{SystemPropertiesTable.CASSANDRA_RELEVANT_PROPERTIES}}
- {{"com.sun.management.jmxremote.ssl"}}
- {{"org.apache.cassandra.disable_mbean_registration"}}
> Expose Cassandra related system properties in a virtual table
> -
>
> Key: CASSANDRA-15616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15616
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: High
> Fix For: 4.x
>
>
> Allow viewing Cassandra related system properties.
> Viewing yaml config settings, as implemented by {{SettingsTable}} in
> CASSANDRA-14573, is not enough for certain third-party tool use-cases. There
> are a number of system properties that can be defined that contribute to the
> configuration set that Cassandra runs on.
> An example of such a use-case is described in CASSANDRA-15339. JMX ports need
> to be discovered, especially in 4.0 where multiple nodes can run on one
> ipaddress. Unlike the native port that is through gossip discoverable, the
> jmx port is not. The jmx port is also not available via the SettingsTable.
> With this patch and {{SystemPropertiesTable}} it becomes possible to first
> discover all the native ports in the cluster and against each then discover
> each node's jmx port.
--
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] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050544#comment-17050544
]
Michael Semb Wever edited comment on CASSANDRA-15234 at 3/3/20 8:50 PM:
And there are a lot of accessing jvm args using the "cassandra." string literal
prefix, instead of {{Config.PROPERTY_PREFIX}}
And, this ticket would help simplify {{SystemPropertiesTable.
CASSANDRA_RELEVANT_PROPERTIES}} in CASSANDRA-15616
was (Author: michaelsembwever):
And there are a lot of accessing jvm args using the "cassandra." string literal
prefix, instead of {{Config.PROPERTY_PREFIX}}
This ticket would help simplify {{SystemPropertiesTable.
CASSANDRA_RELEVANT_PROPERTIES}} in CASSANDRA-15616
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050544#comment-17050544
]
Michael Semb Wever commented on CASSANDRA-15234:
And there are a lot of accessing jvm args using the "cassandra." string literal
prefix, instead of {{Config.PROPERTY_PREFIX}}
This ticket would help simplify {{SystemPropertiesTable.
CASSANDRA_RELEVANT_PROPERTIES}} in CASSANDRA-15616
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050541#comment-17050541
]
David Capwell commented on CASSANDRA-15234:
---
Nope. All yours if you want
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050506#comment-17050506
]
Benedict Elliott Smith commented on CASSANDRA-15375:
bq. regardless of its actual quality or past merits
FWIW, I'd like to disclaim any desire to discredit the original work - it was
both a very different time, and nothing is ever perfect first time. With
maintenance it could no doubt have rapidly become a useful feature, but today
it does not make sense.
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15375:
---
Authors: Benedict Elliott Smith (was: Jon Haddad)
Test and Documentation Plan: n/a
Status: Patch Available (was: Open)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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] [Assigned] (CASSANDRA-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-15614:
---
Assignee: Ekaterina Dimitrova
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if we have a process to check, then check it.*
> *# Skip on Windows - stdout/stderr is cassandra.bat*
> *if not common.is_win() and not output_read:*
> *if process:*
> *process.poll()*
>
[jira] [Commented] (CASSANDRA-15582) 4.0 quality testing: metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050493#comment-17050493 ] Ekaterina Dimitrova commented on CASSANDRA-15582: - [~rha] [~djoshi] Any particular tickets or work that I can help with here? > 4.0 quality testing: metrics > > > Key: CASSANDRA-15582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15582 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Romain Hardouin >Priority: Normal > Fix For: 4.0-rc > > > In past releases we've unknowingly broken metrics integrations and introduced > performance regressions in metrics collection and reporting. We strive in 4.0 > to not do that. Metrics should work well! -- 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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050482#comment-17050482
]
Sergio Bossa commented on CASSANDRA-15375:
--
As the original author of that implementation, I regard it as experimental and
never proved to be widely used, so I agree with removing it. Dead code is bad
code (regardless of its actual quality or past merits).
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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] [Comment Edited] (CASSANDRA-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050482#comment-17050482
]
Sergio Bossa edited comment on CASSANDRA-15375 at 3/3/20 7:01 PM:
--
As the original author of that implementation, I regard it as experimental and
never proven to be widely used, so I agree with removing it. Dead code is bad
code (regardless of its actual quality or past merits).
was (Author: sbtourist):
As the original author of that implementation, I regard it as experimental and
never proved to be widely used, so I agree with removing it. Dead code is bad
code (regardless of its actual quality or past merits).
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050476#comment-17050476
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
[~dcapwell]. did you start this one?
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050473#comment-17050473
]
Jon Haddad commented on CASSANDRA-15375:
I've worked on a few hundred clusters (from maybe 75 teams / companies) and I
have never seen this feature used. I have no objections to removing it.
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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] [Assigned] (CASSANDRA-15613) Flakey test - TestBootstrap.test_local_quorum_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-15613:
Assignee: Brandon Williams
> Flakey test - TestBootstrap.test_local_quorum_bootstrap
> ---
>
> Key: CASSANDRA-15613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15613
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Flakey test on trunk, java 8.
> I did a couple of loops and it sometimes fail at the 5th run, sometimes at
> the 50th.
>
> {noformat}
> *_
> TestBootstrap.test_local_quorum_bootstrap
> __*
>
> self =
>
> *def test_local_quorum_bootstrap(self):*
> *"""*
> *Test that CL local_quorum works while a node is bootstrapping.*
> *@jira_ticket CASSANDRA-8058*
> *"""*
> *cluster = self.cluster*
> *cluster.populate([1, 1])*
> *cluster.start()*
> **
> *node1 = cluster.nodes['node1']*
> *yaml_config = """*
> *# Create the keyspace and table*
> *keyspace: keyspace1*
> *keyspace_definition: |*
> *CREATE KEYSPACE keyspace1 WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'dc1': 1, 'dc2': 1};*
> *table: users*
> *table_definition:*
> *CREATE TABLE users (*
> *username text,*
> *first_name text,*
> *last_name text,*
> *email text,*
> *PRIMARY KEY(username)*
> *) WITH compaction = \{'class':'SizeTieredCompactionStrategy'};*
> *insert:*
> *partitions: fixed(1)*
> *batchtype: UNLOGGED*
> *queries:*
> *read:*
> *cql: select * from users where username = ?*
> *fields: samerow*
> *"""*
> *with tempfile.NamedTemporaryFile(mode='w+') as stress_config:*
> *stress_config.write(yaml_config)*
> *stress_config.flush()*
> *node1.stress(['user', 'profile=' + stress_config.name, 'n=200K',
> 'no-warmup',*
> *'ops(insert=1)', '-rate', 'threads=10'])*
> **
> *node3 = new_node(cluster, data_center='dc2')*
> *node3.start(no_wait=True)*
> *time.sleep(3)*
> **
> *ntout = node1.nodetool('status').stdout*
> *> assert re.search(r'UJ\s+' + node3.ip_addr, ntout), ntout*
> *E AssertionError: Datacenter: dc1*
> *E ===*
> *E Status=Up/Down*
> *E |/ State=Normal/Leaving/Joining/Moving*
> *E -- Address Load Owns (effective) Host ID
> Token Rack*
> *E UN 127.0.0.1 76.82 KiB ?
> 3056e1d1-eac6-493a-b5bc-f8fe703d8d4b -9223372036854775808 r1 *
> *E*
> *E Datacenter: dc2*
> *E ===*
> *E Status=Up/Down*
> *E |/ State=Normal/Leaving/Joining/Moving*
> *E -- Address Load Owns (effective) Host ID
> Token Rack*
> *E UN 127.0.0.2 76.83 KiB ?
> ae607eb3-5601-4b6f-9d01-cf9401da5a4c -9223372036854775708 r1 *
> *E*
> *E*
> *E assert None*
> *E + where None = (('UJ\\s+' +
> '127.0.0.3'), 'Datacenter: dc1\n===\nStatus=Up/Down\n|/
> State=Normal/Leaving/Joining/Moving\n-- Address Load O...Rack\nUN
> 127.0.0.2 76.83 KiB ? ae607eb3-5601-4b6f-9d01-cf9401da5a4c
> -9223372036854775708 r1 \n\n')*
> *E + where = re.search*
> *E + and '127.0.0.3' = 0x106530b10>.ip_addr*
>
> *bootstrap_test.py*:488: AssertionError
> ---
> Captured stdout setup
>
> 11:42:12,744 ccm DEBUG Log-watching thread starting.
> -
> Captured log setup
> -
> 11:42:12,608
[jira] [Updated] (CASSANDRA-15610) Upgrade Sidecar Gradle Dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-15610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15610: --- Description: There's a few out of date dependencies in the Gradle config, some of which are hindering us from fully supporting Java 11. * Gradle can be upgraded to 6.2 * Findbugs is abandoned and is Java 8 only, spotbugs is the supported replacement * Old guava transitive dependency from the Java Driver (out of scope for now, will create follow up) * Java driver is 3.6, 3.8 is more current (out of scope for now, will create follow up) There's probably more to do but this is a quick starting point. was: There's a few out of date dependencies in the Gradle config, some of which are hindering us from fully supporting Java 11. * Gradle can be upgraded to 6.2 * Findbugs is abandoned and is Java 8 only, spotbugs is the supported replacement * Old guava transitive dependency from the Java Driver * Java driver is 3.6, 3.8 is more current There's probably more to do but this is a quick starting point. > Upgrade Sidecar Gradle Dependencies > --- > > Key: CASSANDRA-15610 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15610 > Project: Cassandra > Issue Type: Improvement > Components: Sidecar >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There's a few out of date dependencies in the Gradle config, some of which > are hindering us from fully supporting Java 11. > * Gradle can be upgraded to 6.2 > * Findbugs is abandoned and is Java 8 only, spotbugs is the supported > replacement > * Old guava transitive dependency from the Java Driver (out of scope for now, > will create follow up) > * Java driver is 3.6, 3.8 is more current (out of scope for now, will create > follow up) > There's probably more to do but this is a quick starting point. -- 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-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050430#comment-17050430
]
Brandon Williams commented on CASSANDRA-15543:
--
Any guidance or suggestions [~ifesdjeen] since this is your test?
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
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-15614) Flakey test - TestBootstrap.test_resumable_bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15614:
Fix Version/s: 4.0-alpha
> Flakey test - TestBootstrap.test_resumable_bootstrap
> -
>
> Key: CASSANDRA-15614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Fails 2 out of 10 times on Mac/Java 8
> {noformat}
> ==
> FAILURES
> ==
> *___
> TestBootstrap.test_resumable_bootstrap
> ___*
>
> self =
>
> *@since('2.2')*
> *def test_resumable_bootstrap(self):*
> *"""*
> *Test resuming bootstrap after data streaming failure*
> *"""*
> *cluster = self.cluster*
> *cluster.populate(2)*
> **
> *node1 = cluster.nodes['node1']*
> *# set up byteman*
> *node1.byteman_port = '8100'*
> *node1.import_config_files()*
> **
> *cluster.start(wait_other_notice=True)*
> *# kill stream to node3 in the middle of streaming to let it fail*
> *if cluster.version() < '4.0':*
> *node1.byteman_submit([self.byteman_submit_path_pre_4_0])*
> *else:*
> *node1.byteman_submit([self.byteman_submit_path_4_0])*
> *node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
> 'replication(factor=2)', '-rate', 'threads=50'])*
> *cluster.flush()*
> **
> *# start bootstrapping node3 and wait for streaming*
> *node3 = new_node(cluster)*
> *node3.start(wait_other_notice=False)*
> **
> *# let streaming fail as we expect*
> *> node3.watch_log_for('Some data streaming failed')*
>
> *bootstrap_test.py*:365:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _
>
> self = , exprs = 'Some data streaming
> failed', from_mark = None, timeout = 600, process = None, verbose = False,
> filename = 'system.log'
>
> *def watch_log_for(self, exprs, from_mark=None, timeout=600,
> process=None, verbose=False, filename='system.log'):*
> *"""*
> *Watch the log until one or more (regular) expression are found.*
> *This methods when all the expressions have been found or the
> method*
> *timeouts (a TimeoutError is then raised). On successful
> completion,*
> *a list of pair (line matched, match object) is returned.*
> *"""*
> *start = time.time()*
> *tofind = [exprs] if isinstance(exprs, string_types) else exprs*
> *tofind = [re.compile(e) for e in tofind]*
> *matchings = []*
> *reads = ""*
> *if len(tofind) == 0:*
> *return None*
> **
> *log_file = os.path.join(self.get_path(), 'logs', filename)*
> *output_read = False*
> *while not os.path.exists(log_file):*
> *time.sleep(.5)*
> *if start + timeout < time.time():*
> *raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))*
> *if process and not output_read:*
> *process.poll()*
> *if process.returncode is not None:*
> *self.print_process_output(self.name, process, verbose)*
> *output_read = True*
> *if process.returncode != 0:*
> *raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy*
> **
> *with open(log_file) as f:*
> *if from_mark:*
> *f.seek(from_mark)*
> **
> *while True:*
> *# First, if we have a process to check, then check it.*
> *# Skip on Windows - stdout/stderr is cassandra.bat*
> *if not common.is_win() and not output_read:*
> *if process:*
> *process.poll()*
> *if process.returncode is not None:*
>
[jira] [Commented] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050426#comment-17050426
]
David Capwell commented on CASSANDRA-15543:
---
I don't know of anyone working on it.
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
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-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15273: --- Fix Version/s: 4.x 3.11.x 3.0.x 2.2.x > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Aleksandr Yatskin >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > Attachments: > 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch > > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- 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-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15273: --- Status: Ready to Commit (was: Review In Progress) > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Aleksandr Yatskin >Assignee: Michael Semb Wever >Priority: Urgent > Attachments: > 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch > > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- 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] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 5:38 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
rm /etc/security/limits.d/cassandra.conf # this should be fixed
/etc/init.d/cassandra start
tail -F /var/log/cassandra/system.log
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1,
[jira] [Commented] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050411#comment-17050411
]
Ekaterina Dimitrova commented on CASSANDRA-15543:
-
Anyone working on this one?
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
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-15611) Build and Test with both Java 8 & 11 in Circle CI
[ https://issues.apache.org/jira/browse/CASSANDRA-15611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15611: Change Category: Quality Assurance Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Build and Test with both Java 8 & 11 in Circle CI > - > > Key: CASSANDRA-15611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15611 > Project: Cassandra > Issue Type: Improvement > Components: Sidecar >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > We currently only build and test with Java 8. We should ensure Java 11 is > fully supported for both builds and testing in CircleCI. -- 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-15617) Sidecar gradle run should not run integration tests
[
https://issues.apache.org/jira/browse/CASSANDRA-15617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRA-15617:
---
Change Category: Semantic
Status: Open (was: Triage Needed)
> Sidecar gradle run should not run integration tests
> ---
>
> Key: CASSANDRA-15617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15617
> Project: Cassandra
> Issue Type: Improvement
> Components: Sidecar
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Normal
>
> Currently the integration tests are tied to the build process. This is a
> nice idea from a “let’s always test” perspective, but unfortunately bites us
> when we want to run a local test server via {{./gradlew run}}.
> We should explicitly call the integrationTest task to run integration tests,
> and have the run task only force a build.
--
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-15617) Sidecar gradle run should not run integration tests
[
https://issues.apache.org/jira/browse/CASSANDRA-15617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRA-15617:
---
Complexity: Low Hanging Fruit
> Sidecar gradle run should not run integration tests
> ---
>
> Key: CASSANDRA-15617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15617
> Project: Cassandra
> Issue Type: Improvement
> Components: Sidecar
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Normal
>
> Currently the integration tests are tied to the build process. This is a
> nice idea from a “let’s always test” perspective, but unfortunately bites us
> when we want to run a local test server via {{./gradlew run}}.
> We should explicitly call the integrationTest task to run integration tests,
> and have the run task only force a build.
--
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-15618) add docs for production recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15618: --- Status: Open (was: Triage Needed) > add docs for production recommendations > --- > > Key: CASSANDRA-15618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15618 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > We have some inline comments in our yaml, but I think it would be helpful if > we had a more lengthy section in the docs detailing the settings people > should be using in production. Some of these are unrelated to the yaml > itself (like reducing read ahead), and putting them in the YAML doesn’t make > much sense. There are also other settings (like compression chunk length) > that don’t fit there. Let’s add a page under getting started called > Production Recommendations. -- 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-15618) add docs for production recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15618: --- Change Category: Quality Assurance Complexity: Low Hanging Fruit > add docs for production recommendations > --- > > Key: CASSANDRA-15618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15618 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > We have some inline comments in our yaml, but I think it would be helpful if > we had a more lengthy section in the docs detailing the settings people > should be using in production. Some of these are unrelated to the yaml > itself (like reducing read ahead), and putting them in the YAML doesn’t make > much sense. There are also other settings (like compression chunk length) > that don’t fit there. Let’s add a page under getting started called > Production Recommendations. -- 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] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:34 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded:
[jira] [Updated] (CASSANDRA-15308) Fix flakey testAcquireReleaseOutbound - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15308:
---
Status: Ready to Commit (was: Review In Progress)
> Fix flakey testAcquireReleaseOutbound -
> org.apache.cassandra.net.ConnectionTest
> ---
>
> Key: CASSANDRA-15308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15308
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Joey Lynch
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Example failure:
> https://circleci.com/gh/jolynch/cassandra/554#tests/containers/61
> {noformat}
> Your job ran 4428 tests with 1 failure
> - testAcquireReleaseOutbound - org.apache.cassandra.net.ConnectionTest
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testAcquireReleaseOutbound$53(ConnectionTest.java:770)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:238)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:258)
> at
> org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:236)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:225)
> at
> org.apache.cassandra.net.ConnectionTest.testAcquireReleaseOutbound(ConnectionTest.java:767)
> {noformat}
--
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-15308) Fix flakey testAcquireReleaseOutbound - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15308:
---
Since Version: 4.0-alpha
Source Control Link:
[abeaa3ea5ef99691cc1b29787cfcd573a90e34fb|https://github.com/apache/cassandra/commit/abeaa3ea5ef99691cc1b29787cfcd573a90e34fb]
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix flakey testAcquireReleaseOutbound -
> org.apache.cassandra.net.ConnectionTest
> ---
>
> Key: CASSANDRA-15308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15308
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Joey Lynch
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Example failure:
> https://circleci.com/gh/jolynch/cassandra/554#tests/containers/61
> {noformat}
> Your job ran 4428 tests with 1 failure
> - testAcquireReleaseOutbound - org.apache.cassandra.net.ConnectionTest
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testAcquireReleaseOutbound$53(ConnectionTest.java:770)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:238)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:258)
> at
> org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:236)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:225)
> at
> org.apache.cassandra.net.ConnectionTest.testAcquireReleaseOutbound(ConnectionTest.java:767)
> {noformat}
--
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
[cassandra] branch trunk updated: Fix ConnectionTest.testAcquireReleaseOutbound
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new abeaa3e Fix ConnectionTest.testAcquireReleaseOutbound
abeaa3e is described below
commit abeaa3ea5ef99691cc1b29787cfcd573a90e34fb
Author: yifan-c
AuthorDate: Tue Jan 28 11:12:30 2020 -0800
Fix ConnectionTest.testAcquireReleaseOutbound
patch by Yifan Cai; reviewed by Benedict for CASSANDRA-15308
---
CHANGES.txt| 1 +
.../apache/cassandra/net/OutboundConnection.java | 10 +-
.../org/apache/cassandra/net/ConnectionTest.java | 101 -
3 files changed, 86 insertions(+), 26 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 5858c19..0bc3317 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
4.0-alpha4
* Improve the algorithmic token allocation in case racks = RF
(CASSANDRA-15600)
+ * Fix ConnectionTest.testAcquireReleaseOutbound (CASSANDRA-15308)
* Include finalized pending sstables in preview repair (CASSANDRA-15553)
* Reverted to the original behavior of CLUSTERING ORDER on CREATE TABLE
(CASSANDRA-15271)
* Correct inaccurate logging message (CASSANDRA-15549)
diff --git a/src/java/org/apache/cassandra/net/OutboundConnection.java
b/src/java/org/apache/cassandra/net/OutboundConnection.java
index 63b909c..9661e8e 100644
--- a/src/java/org/apache/cassandra/net/OutboundConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundConnection.java
@@ -30,6 +30,7 @@ import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLongFieldUpdater;
import java.util.concurrent.atomic.AtomicReference;
import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
+import java.util.stream.Stream;
import javax.annotation.Nullable;
@@ -1722,8 +1723,15 @@ public class OutboundConnection
releaseCapacity(1, amount);
}
+@VisibleForTesting
+void unsafeReleaseCapacity(long count, long amount)
+{
+releaseCapacity(count, amount);
+}
+
+@VisibleForTesting
Limit unsafeGetEndpointReserveLimits()
{
return reserveCapacityInBytes.endpoint;
}
-}
\ No newline at end of file
+}
diff --git a/test/unit/org/apache/cassandra/net/ConnectionTest.java
b/test/unit/org/apache/cassandra/net/ConnectionTest.java
index 7b69cb9..d4ec84c 100644
--- a/test/unit/org/apache/cassandra/net/ConnectionTest.java
+++ b/test/unit/org/apache/cassandra/net/ConnectionTest.java
@@ -25,11 +25,13 @@ import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
+import java.util.Random;
import java.util.Set;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
+import java.util.concurrent.ThreadLocalRandom;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;
@@ -766,40 +768,89 @@ public class ConnectionTest
@Test
public void testAcquireReleaseOutbound() throws Throwable
{
+// In each test round, K capacity is reserved upfront.
+// Two groups of threads each release/acquire for K capacity in total
accordingly,
+// i.e. if only the release threads run, at the end, the reserved
capacity is 0 (K - K).
+// During the test, we expect N (N <= maxFailures) acquire attempts
(for M capacity) to fail.
+// The reserved capacity (pendingBytes) at the end of the round should
equal to K - N * M,
+// which you can find in the assertion.
test((inbound, outbound, endpoint) -> {
-ExecutorService executor = Executors.newFixedThreadPool(100);
-int acquireStep = 123;
-Assert.assertTrue(outbound.unsafeAcquireCapacity(100 * 1, 100
* 1 * acquireStep));
+// max capacity equals to permit-free sendQueueCapcity + the
minimun of endpoint and global reserve
+double maxSendQueueCapacity =
outbound.settings().applicationSendQueueCapacityInBytes +
+
Double.min(outbound.settings().applicationSendQueueReserveEndpointCapacityInBytes,
+
outbound.settings().applicationSendQueueReserveGlobalCapacityInBytes.limit());
+int concurrency = 100;
+int attempts = 1;
+int acquireCount = concurrency * attempts;
+long acquireStep = Math.round(maxSendQueueCapacity * 1.2 /
acquireCount / 2); // It is guranteed to acquire (~20%) more
+// The total overly acquired amount divides the amount acquired in
each step. Get the ceil value so not to miss the acquire that just exceeds.
+long maxFailures =
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:27 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:12 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited,
> status=0/SUCCESS)
>
[jira] [Commented] (CASSANDRA-15600) Algorithmic token allocation does not handle the racks = RF case well
[ https://issues.apache.org/jira/browse/CASSANDRA-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050341#comment-17050341 ] Brandon Williams commented on CASSANDRA-15600: -- Committed, thanks! > Algorithmic token allocation does not handle the racks = RF case well > - > > Key: CASSANDRA-15600 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15600 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Branimir Lambov >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > Attachments: CASSANDRA-15600 unit.txt, CASSANDRA-15600-jvm.txt.zip, > Screen Shot 2020-03-02 at 6.55.41 PM.png > > > When the number of racks in a data centre is equal to the replication factor, > the node allocation algorithm may calculate the target ownership incorrectly > and allocate unsuitable tokens. This causes some inefficiency when the number > of nodes in the DC is small, and significant problems if the number of nodes > in each rack is different. > In this case (racks count equal to replication factor) the load within each > rack is effectively distributed independently. The allocation algorithm > should reflect that, restricting the allocation space to the rack (instead of > the DC) and using the RF=1 solution. -- 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] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:05 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
Note, we are short of packaging experience in the community and really need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited,
> status=0/SUCCESS)
> Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited,
> status=0/SUCCESS)
> Main PID: 1884 (code=exited, status=143)
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service
[jira] [Updated] (CASSANDRA-15600) Algorithmic token allocation does not handle the racks = RF case well
[ https://issues.apache.org/jira/browse/CASSANDRA-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15600: - Fix Version/s: 4.0-alpha Since Version: 4.0-alpha Source Control Link: https://github.com/apache/cassandra/commit/c9c022e07fd4fc6afc59cd1149fd18bc84d3fb39 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Algorithmic token allocation does not handle the racks = RF case well > - > > Key: CASSANDRA-15600 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15600 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Branimir Lambov >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > Attachments: CASSANDRA-15600 unit.txt, CASSANDRA-15600-jvm.txt.zip, > Screen Shot 2020-03-02 at 6.55.41 PM.png > > > When the number of racks in a data centre is equal to the replication factor, > the node allocation algorithm may calculate the target ownership incorrectly > and allocate unsuitable tokens. This causes some inefficiency when the number > of nodes in the DC is small, and significant problems if the number of nodes > in each rack is different. > In this case (racks count equal to replication factor) the load within each > rack is effectively distributed independently. The allocation algorithm > should reflect that, restricting the allocation space to the rack (instead of > the DC) and using the RF=1 solution. -- 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] [Assigned] (CASSANDRA-15528) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testInvalidate
[
https://issues.apache.org/jira/browse/CASSANDRA-15528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianluca Righetto reassigned CASSANDRA-15528:
-
Assignee: Gianluca Righetto
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testInvalidate
> --
>
> Key: CASSANDRA-15528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15528
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: [key0, key2918, key2919, key2920,
> key2921, key2922, key2924, key2926, key2927, key2928]
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testInvalidate(SASIIndexTest.java:874)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testInvalidate(SASIIndexTest.java:852)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
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-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050339#comment-17050339
]
Michael Semb Wever commented on CASSANDRA-15273:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
Note, we are short of packaging experience in the community and really need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited,
> status=0/SUCCESS)
> Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited,
> status=0/SUCCESS)
> Main PID: 1884 (code=exited, status=143)
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service
> entered failed state.
> Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed.
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed
> storage system for structured data...
> Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none
> Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK
> Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not
> belong to service, and PID file is not owned by root. Refusing.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not
> belong to service, and PID file is not owned by root. Refusing.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB:
> distributed storage system for structured data.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service
> entered failed state.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed.
--
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
[cassandra] branch trunk updated: Improve the algorithmic token allocation in case racks = RF
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new c9c022e Improve the algorithmic token allocation in case racks = RF
c9c022e is described below
commit c9c022e07fd4fc6afc59cd1149fd18bc84d3fb39
Author: Ekaterina Dimitrova
AuthorDate: Thu Feb 27 18:47:33 2020 -0500
Improve the algorithmic token allocation in case racks = RF
Patch by Ekaterina Dimitrova, reviewed by brandonwilliams for
CASSANDRA-15600
---
CHANGES.txt| 1 +
.../NoReplicationTokenAllocator.java | 44
.../ReplicationAwareTokenAllocator.java| 12 -
.../dht/tokenallocator/TokenAllocation.java| 28 +-
.../dht/tokenallocator/TokenAllocatorBase.java | 60 ++
.../org/apache/cassandra/dht/BootStrapperTest.java | 57 +++-
6 files changed, 176 insertions(+), 26 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 9cd6040..5858c19 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-alpha4
+ * Improve the algorithmic token allocation in case racks = RF
(CASSANDRA-15600)
* Include finalized pending sstables in preview repair (CASSANDRA-15553)
* Reverted to the original behavior of CLUSTERING ORDER on CREATE TABLE
(CASSANDRA-15271)
* Correct inaccurate logging message (CASSANDRA-15549)
diff --git
a/src/java/org/apache/cassandra/dht/tokenallocator/NoReplicationTokenAllocator.java
b/src/java/org/apache/cassandra/dht/tokenallocator/NoReplicationTokenAllocator.java
index f6a1592..0ac8951 100644
---
a/src/java/org/apache/cassandra/dht/tokenallocator/NoReplicationTokenAllocator.java
+++
b/src/java/org/apache/cassandra/dht/tokenallocator/NoReplicationTokenAllocator.java
@@ -114,24 +114,6 @@ public class NoReplicationTokenAllocator extends
TokenAllocatorBase
unitTokens.add(new Weighted(token.replicatedOwnership,
token));
}
-private Collection generateRandomTokens(UnitInfo newUnit, int
numTokens, Map> unitInfos)
-{
-Set tokens = new HashSet<>(numTokens);
-while (tokens.size() < numTokens)
-{
-Token token = partitioner.getRandomToken();
-if (!sortedTokens.containsKey(token))
-{
-tokens.add(token);
-sortedTokens.put(token, newUnit.unit);
-}
-}
-unitInfos.put(newUnit.unit, newUnit);
-createTokenInfos(unitInfos);
-TokenAllocatorDiagnostics.randomTokensGenerated(this, numTokens,
sortedUnits, sortedTokens, newUnit.unit, tokens);
-return tokens;
-}
-
public Collection addUnit(Unit newUnit, int numTokens)
{
assert !tokensInUnits.containsKey(newUnit);
@@ -141,10 +123,10 @@ public class NoReplicationTokenAllocator extends
TokenAllocatorBase
Map> unitInfos = createUnitInfos(groups);
if (unitInfos.isEmpty())
-return generateRandomTokens(newUnitInfo, numTokens, unitInfos);
+return generateSplits(newUnit, numTokens);
if (numTokens > sortedTokens.size())
-return generateRandomTokens(newUnitInfo, numTokens, unitInfos);
+return generateSplits(newUnit, numTokens);
TokenInfo head = createTokenInfos(unitInfos);
@@ -172,7 +154,19 @@ public class NoReplicationTokenAllocator extends
TokenAllocatorBase
}
List newTokens = Lists.newArrayListWithCapacity(numTokens);
-
+// Generate different size nodes, at most at 2/(numTokens*2+1)
difference,
+// but tighten the spread as the number of nodes grows (since it
increases the time until we need to use nodes
+// we have just split).
+double sizeCorrection = Math.min(1.0, (numTokens + 1.0) /
(unitInfos.size() + 1.0));
+double spread = targetAverage * sizeCorrection * 2.0 / (2 * numTokens
+ 1);
+
+// The biggest target is assigned to the biggest existing node. This
should result in better balance in
+// the amount of data that needs to be streamed from the different
sources to the new node.
+double target = targetAverage + spread / 2;
+
+// This step intentionally divides by the count (rather than count -
1) because we also need to count the new
+// node. This leaves the last position in the spread (i.e. the
smallest size, least data to stream) for it.
+double step = spread / unitsToChange.size();
int nr = 0;
// calculate the tokens
for (Weighted unit : unitsToChange)
@@ -193,7 +187,7 @@ public class NoReplicationTokenAllocator extends
TokenAllocatorBase
unit.value.ownership -= wt.weight;
}
-double toTakeOver = unit.weight - targetAverage;
+double toTakeOver = unit.weight -
[jira] [Updated] (CASSANDRA-15600) Algorithmic token allocation does not handle the racks = RF case well
[ https://issues.apache.org/jira/browse/CASSANDRA-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15600: - Status: Ready to Commit (was: Review In Progress) > Algorithmic token allocation does not handle the racks = RF case well > - > > Key: CASSANDRA-15600 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15600 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Branimir Lambov >Assignee: Ekaterina Dimitrova >Priority: Normal > Attachments: CASSANDRA-15600 unit.txt, CASSANDRA-15600-jvm.txt.zip, > Screen Shot 2020-03-02 at 6.55.41 PM.png > > > When the number of racks in a data centre is equal to the replication factor, > the node allocation algorithm may calculate the target ownership incorrectly > and allocate unsuitable tokens. This causes some inefficiency when the number > of nodes in the DC is small, and significant problems if the number of nodes > in each rack is different. > In this case (racks count equal to replication factor) the load within each > rack is effectively distributed independently. The allocation algorithm > should reflect that, restricting the allocation space to the rack (instead of > the DC) and using the RF=1 solution. -- 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] [Assigned] (CASSANDRA-15557) Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
[
https://issues.apache.org/jira/browse/CASSANDRA-15557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Svihla reassigned CASSANDRA-15557:
---
Assignee: Ryan Svihla
> Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest
> testDropListAndAddListWithSameName
> ---
>
> Key: CASSANDRA-15557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15557
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ryan Svihla
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests
> {code}
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2
> (mycollection of type list), expected but got <[first element]>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
> at
> org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
> {code}
--
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-15607) Incorrect Outcome returned when acquiring capacity for incoming message
[
https://issues.apache.org/jira/browse/CASSANDRA-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15607:
--
Bug Category: Parent values: Code(13163)
Complexity: Low Hanging Fruit
Discovered By: Code Inspection
Severity: Low
Status: Open (was: Triage Needed)
> Incorrect Outcome returned when acquiring capacity for incoming message
> ---
>
> Key: CASSANDRA-15607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15607
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Sam Tunnicliffe
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> When acquiring capacity to process an inbound internode message, a failure to
> allocate from the endpoint-specific reserve returns the wrong {{Outcome}}.
> This means we only ever register with {{globalWaitQueue}}, although this
> probably doesn't actually ever get detected as the global and endpoint queues
> are always signalled together.
--
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] [Assigned] (CASSANDRA-15607) Incorrect Outcome returned when acquiring capacity for incoming message
[
https://issues.apache.org/jira/browse/CASSANDRA-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko reassigned CASSANDRA-15607:
-
Assignee: Aleksey Yeschenko
> Incorrect Outcome returned when acquiring capacity for incoming message
> ---
>
> Key: CASSANDRA-15607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15607
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Sam Tunnicliffe
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> When acquiring capacity to process an inbound internode message, a failure to
> allocate from the endpoint-specific reserve returns the wrong {{Outcome}}.
> This means we only ever register with {{globalWaitQueue}}, although this
> probably doesn't actually ever get detected as the global and endpoint queues
> are always signalled together.
--
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] [Assigned] (CASSANDRA-15565) Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
[
https://issues.apache.org/jira/browse/CASSANDRA-15565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay reassigned CASSANDRA-15565:
-
Assignee: Jorge Bay
> Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest
> indexCorrectlyMarkedAsBuildAndRemoved
> ---
>
> Key: CASSANDRA-15565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15565
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Jorge Bay
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 1
> but got 4.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> The failure was seen 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] [Commented] (CASSANDRA-15565) Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
[
https://issues.apache.org/jira/browse/CASSANDRA-15565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050184#comment-17050184
]
Jorge Bay commented on CASSANDRA-15565:
---
I've been trying to reproduce with no luck. I've run the test and the suite in
loop in CircleCI:
- https://circleci.com/gh/jorgebay/cassandra/7
- https://circleci.com/gh/jorgebay/cassandra/12
I've also run it in loop in my local machine.
>From the error message in the ticket, it's related to the initial condition of
>the test, it expects no other index present. The failure is mostly due to an
>issue with the cleanup of a prior test.
I'll submit a patch using {{KEYSPACE_PER_TEST}}, that way it will less likely
to fail in cascade after another test.
> Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest
> indexCorrectlyMarkedAsBuildAndRemoved
> ---
>
> Key: CASSANDRA-15565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15565
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 1
> but got 4.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> The failure was seen 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-15612) Mutating sstable metadata during anticompaction fails silently on legacy sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-15612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15612: Test and Documentation Plan: new legacy sstable test and cci runs Status: Patch Available (was: Open) [patch|https://github.com/krummas/cassandra/commits/marcuse/15612], [cci|https://circleci.com/workflow-run/900abd8c-78ad-4c09-befd-f9ce7b4501be] > Mutating sstable metadata during anticompaction fails silently on legacy > sstables > - > > Key: CASSANDRA-15612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15612 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > If there is an sstable with a version without pending repair information > included in an incremental repair we silently don't set the pending repair > correctly. We should fail the IR instead. -- 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-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15273: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever Status: Review In Progress (was: Patch Available) > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Aleksandr Yatskin >Assignee: Michael Semb Wever >Priority: Urgent > Attachments: > 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch > > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- 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-15552) Fix flaky test org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-15552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15552:
Since Version: 4.0-alpha
Source Control Link:
https://github.com/apache/cassandra/commit/1ce58ac2ea945baaaeece233f3d3735686a2ecb8
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
committed, thanks
I think it is ok to assume that the anticompactions will both fail within 1
minute, otherwise we should probably at least look in to why it took so long.
> Fix flaky test
> org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction
> --
>
> Key: CASSANDRA-15552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15552
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction(PendingAntiCompactionBytemanTest.java:80)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:364)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {code}
> Failure was 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
